Monday, August 23, 2010

Oracle Block Remastering

Here's good arcticle on dynamic remastering.

Remastering granularity
  • Oracle 10g-11g.  Block range (128 blocks in a range)

Queries:


select kj.*, le.le_Addr from (
select kjblname, kjblname2, kjblowner, kjblmaster, kjbllockp,
substr ( kjblname2,  instr(kjblname2,',')+1,   instr(kjblname2,',',1,2)-instr(kjblname2,',',1,1)-1)/65536 fl,
substr ( kjblname2, 1, instr(kjblname2,',')-1) blk
 from x$kjbl
) kj, x$le le
where le.le_kjbl = kj.kjbllockp
 order by le.le_addr
/


select * from x$object_affinity_statistics
/

select * from v$gcspfmaster_info
/

Remasting Technique

  • With object remastering feature, if an object is accessed by an instance aggressively, then that instance will become the master of the object reducing gc remote grants improving performance of the application. In the prior sentence, I used the word “accessed”, but it is a loose term, and the correct term is if the instance is requesting much BL locks on an object, then that object can be remastered. 
  • Instance GRD is frozen during reconfiguration and in a very busy instances, this can take many seconds leading to instance freeze for several seconds.
Internal Parameters
  • _gc_affinity_limit - the number of "opens" before an object is considered for remastering (defaults to 50)
  • _gc_affinity_time - how often the queue is checked for remastering (defaults to 10 minutes)
  • _gc_affinity_minimum - minimum amount of dynamic affinity activity per minute to be a candidate for remastering (defaults to 600/minute/cpu)
  • _gc_undo_affinity - controls whether dynamic undo remastering is enabled
Evidence of remastering performance problems
  • Wait events: "gcs drm freeze", "gc remaster", "gcs freeze"
  • Log entries at the same time "DRM start"

Wednesday, July 14, 2010

Facebook Defaults

I thought when I first joined facebook that the default privacy rules were quite good. Look again now (2010-07-14) I see that they are not very private at all.  So what "should" they be, especially for kids?  Here's a great article.  Basically, almost everything should be "Friends Only".






Tuesday, June 1, 2010

Oracle Clusterware Failures: Useful Logs

To determine why a node failed, try the following clusterware logs (in order of usefulness):

  • alert log
  • ocssd log
  • evm log

Oracle Clusterware Parameters: misscount, disktimeout, reboottime

Clusterware timeout parameters:
  • misscount - It represents maximum time in seconds that, a heartbeat can be missed before entering into a cluster reconfiguration to evict the node. 
  • disktimeout - It is the maximum amount of time allowed for a voting file I/O to complete; if this time is exceeded the voting disk will be marked as offline. 
  • reboottime - It is the amount of time allowed for a node to complete a reboot after the CSS daemon has been evicted. 
 Default values for these parameters are as follows:
  • misscount = 60 seconds
  • disktimeout = 200 seconds
  • reboottime = 3 seconds 
Commands to check / modify CSS parameters:
  • crsctl get css misscount ---------- to check misscount value 
  • crsctl get css disktimeout --------- to check disktimeout value 
  • crsctl get css reboottime ---------- to check reboottime value 
  • crsctl set css misscount 120 --------- to set misscount to 120 seconds 
  • crsctl set css disktimeout 200 ------- to set disktimeout to 200 seconds
  • crsctl set css reboottime 3 ----------- to set reboottime to 3 seconds 
Only non-default values are only returned from get calls above. To confirm the default values, look in ocssd.log for the following:
lssnmNMInitialize: misscount set to (30)

clssnmNMInitialize: Network heartbeat thresholds are: impending reconfig 15000 ms, reconfig start (misscount) 30000 ms

clssgmInitCMInfo: Wait for remote node termination set to 13 seconds
clssnmNMInitialize: misscount set to (60), impending reconfig threshold set to (56000)
clssnmNMInitialize: diskShortTimeout set to (57000)ms
clssnmNMInitialize: diskLongTimeout set to (200000)ms

clssnmHandleUpdate: diskTimeout set to (200000)ms