Oracle Scratchpad

September 17, 2012

Private Redo

Filed under: Infrastructure,Oracle,redo — Jonathan Lewis @ 8:28 pm BST Sep 17,2012

Following a question on the Oracle Core Addenda pages, here’s a little script to tell you about the sizes of the public and private redo threads currently active in the instance. It’s a minor variation of a script I published in Appendix D (Dumping and Debugging), page 237 to show the addresses of current activity in the various log buffers:


---------- ---------------- ----------------- --------------------- ---------------------
         0             6821           3492352                     0                     0
         1             6821           3492352                     0                     0
         2              125             66560                     2                 62976
         3              125             66560            3735928559                 62976
         4              125             66560            3735928559                 62976
         5              125             66560            3735928559                 62976
         6              125             66560            3735928559                 62976
         7              125             66560                     0                     0
         8              125             66560                     0                     0
         9              125             66560                     0                     0
        10              125             66560                     0                     0
        48              125             66560                     0                     0
        49              125             66560                     0                     0

50 rows selected.

As you can see, I have 50 log buffers – and by examination of sizes (if nothing else) we can assume that the first two are the public redo threads at a little under 3.5MB each, and the remaining 48 threads are private redo threads at roughly 64KB each. Comparing the total_bufs with the strand_size you can infer that the block size for the buffers (hence log file) are 512 bytes each. Finally, the non-zero examples of space_kcrf_pvt_strand (for the private threads) give you a strong indication of the maximum number of private threads that have actually been brought into play – in this case five.

Notice that the private threads that have been used also have a non-zero value for index_kcrf_pct_strand – when the thread is actually in use this matches the indx column, and when the thread is not in use it gets set to 3735928559. If you’re wondering about the significance of that number, I think it’s a programmer in Oracle with a (strange) sense of humour – convert to hex and the value reads: “DEAD BEEF”. (There are other places in the code where the value “DEAD FACE” appears in, for example, memory locations that mark the boundaries between critical objects.)



  1. I couldn’t believe it! I checked and it’s true:

    $ perl -e ‘printf(“%X\n”,3735928559);’

    mgogala@CVPS007153 ~

    Jonathan, you’ve just made my day, not in the dirty Harry sense.

    Comment by Mladen Gogala — September 18, 2012 @ 1:15 am BST Sep 18,2012 | Reply

  2. Hi Jonathan.
    What about flashback log buffer ? does oracle use private log buffers as well ?

    Comment by sagizvi — September 18, 2012 @ 6:42 am BST Sep 18,2012 | Reply

    • Sagizvi,

      No, not the last time I looked.

      It’s worth noting that the default size of the flashback log buffer is (was) twice the size of the redo log buffer – so if you see waits for the flashback log buffer then the remedy is to increase the size of the redo log buffer.

      Comment by Jonathan Lewis — September 18, 2012 @ 11:43 am BST Sep 18,2012 | Reply

  3. I must say I admire your curiosity. It’s always interesting to read your articles, even if it’s just for a laugh.

    Comment by Lasse Jenssen — September 24, 2012 @ 6:19 pm BST Sep 24,2012 | Reply

  4. I’ve seen DEADBEEF on Solaris. According to it has a history and is conventionally used to “mark newly allocated areas of memory that had not yet been initialized”.
    I think we can also say the private threads that have been used are those with non-zero pvt_strand_state_kcrfa_cln.

    Comment by Yong Huang — September 25, 2012 @ 8:29 pm BST Sep 25,2012 | Reply

  5. I’ve seen BABEFACE somewhere too :-)

    Comment by Tanel Poder — September 28, 2012 @ 1:49 am BST Sep 28,2012 | Reply

  6. Hi,

    How would you check which ones are private or public? I can’t guess a column based on the names in that table :x
    Would x$kcrfstrand show information from all instances on a RAC or only the one it is run on?

    Interesting stuff :o I thought only 1 buffer per instance until I started reading your book (now on page 15 >_<)


    Comment by Dird — October 23, 2012 @ 9:00 am BST Oct 23,2012 | Reply

  7. […] 10g and up. Info about redo strands. Non-zero pvt_strand_state_kcrfa_cln (and strand_num_ordinal_kcrfa_cln=3735928559 or DEADBEEF in hex) means a transaction is using this private strand. (Private strands may be disabled in RAC or if supplemental logging is on, but multistrand redo is still used.) Strand_size_kcrfa is the strand size (meaningful only if last_buf_kcrfa’00’; Ref). Also see 18164614, Ref. […]

    Pingback by Oracle X$ Tables — — January 2, 2016 @ 6:13 pm GMT Jan 2,2016 | Reply

  8. Adding to these joyful comments on a friday afternoon, I’ve seen ‘CAFEBABE’ in the Exadata storage server.

    Comment by Frits Hoogland — September 30, 2016 @ 2:07 pm BST Sep 30,2016 | Reply

RSS feed for comments on this post. TrackBack URI

Comments and related questions are welcome.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Website Powered by