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'; 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, IXDBA.NET社区论坛 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.