|
|
|
|
|
|
| Search the Reference Library pages: |
|
|
|
|
| Oracle System |
| Version 11.1 |
| |
| Alter System |
| Flush Buffer Cache |
ALTER SYSTEM FLUSH BUFFER_CACHE; |
| ALTER SYSTEM FLUSH
BUFFER_CACHE; |
| Flush Shared Pool |
ALTER SYSTEM FLUSH SHARED_POOL; |
| ALTER SYSTEM FLUSH
SHARED_POOL; |
Disconnect Session |
ALTER SYSTEM DISCONNECT SESSION
'<SID>,<SERIAL#>' POST TRANSACTION; |
set linesize 121
SELECT sid, serial#, osuser, username, schemaname
FROM v_$session
WHERE sid = (
SELECT DISTINCT sid
FROM v_$mystat);
ALTER SYSTEM DISCONNECT SESSION '8,694' POST
TRANSACTION; |
Kill Session |
ALTER SYSTEM KILL SESSION
'<SID>,<SERIAL#>'; |
set linesize 121
SELECT sid, serial#, osuser, username, schemaname
FROM v_$session
WHERE sid = (
SELECT DISTINCT sid
FROM v_$mystat);
ALTER SYSTEM KILL SESSION '8,694'; |
| Register with the
listener |
ALTER SYSTEM REGISTER; |
| ALTER SYSTEM
REGISTER; |
| Determine If Killed Session Is Rolling Back Transactions |
This shows the user who's transaction is being rolled back If this number, xidusn,
is decreasing then the transaction is rolling back. If it is increasing then the transaction is moving forward. |
SELECT a.sid, a.username, b.xidusn rollback_seg_no,
b.used_urec undo_records, b.used_ublk undo_blocks
FROM gv$session a, gv$transaction b
WHERE a.saddr = b.ses_addr; |
| |
Is SGA sizing dynamic |
SQL> show sga
Total System Global Area 289406976 bytes
Fixed Size 788808 bytes
Variable Size 99612344 bytes
Database Buffers 188743680 bytes
Redo Buffers 262144 bytes
SQL> ALTER SYSTEM SET sga_max_size=250mM SCOPE=spfile;
System altered.
SQL> startup force
ORACLE instance started.
Total System Global Area 264241152 bytes
Fixed Size 788448 bytes
Variable Size 238024736 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
Database mounted.
Database opened.
SQL> ALTER SYSTEM SET sga_max_size=180m;
alter system set sga_max_size=180m
*
ERROR at line 1:
ORA-02095: specified initialization parameter cannot be modified
Which proves two things. First, if you set SGA_MAX_SIZE to 250M then the next time you start your instance, a full 250MB of RAM
is used by the SGA (give or take a bit of rounding up to the next actual granule border). Yet I changed nothing to do with my
shared pool, my buffer cache or my large pool ... so clearly, the *used* bit of my SGA can only be the same as it was before
... as is evidenced by the before and after values displayed for the "Database Buffers" and "Redo Buffers" components, for example.
Secondly, how "dynamic" is the SGA when the parameter which sizes it, SGA_MAX_SIZE, can't actually be dynamically altered, as
I demonstrate at the end with an attempt to dynamically set it back to 180M, but can only be modified with the 'scope=spfile'
clause tacked on (or by editing an
init.ora) - thus requiring an instance re-start before the new value is read.
Ergo: SGA_MAX_SIZE is not actually dynamic. And SGA_MAX_SIZE steals all of its memory from the operating system regardless of
what your caches and pools are actually set to.
Different operating systems, for example Solaris, may behave differently. |
|
| |
|
| |
|
-----
|