Home » RDBMS Server » Server Administration » Private strand flush not complete - alertSID.ora's message (Solaris 10, Oracle Database 10.2.0.1)
Private strand flush not complete - alertSID.ora's message [message #335419] Tue, 22 July 2008 02:38 Go to next message
trantuananh24hg
Messages: 744
Registered: January 2007
Location: Ha Noi, Viet Nam
Senior Member
Hi all!

From metalink, Note:372557.1, I know that, the message was not a bug, but this made me worry.

Please clarify more about that!

Thank you very much!
Re: Private strand flush not complete - alertSID.ora's message [message #335423 is a reply to message #335419] Tue, 22 July 2008 02:51 Go to previous messageGo to next message
tahpush
Messages: 961
Registered: August 2006
Location: Stockholm/Sweden
Senior Member

Quote:
this made me worry

Why ? If it's the expected behavior

Quote:
Please clarify more about that!

Clarify what ?

Try rephrase your question ?
Re: Private strand flush not complete - alertSID.ora's message [message #335435 is a reply to message #335423] Tue, 22 July 2008 03:27 Go to previous message
trantuananh24hg
Messages: 744
Registered: January 2007
Location: Ha Noi, Viet Nam
Senior Member
Quote:

Why ? If it's the expected behavior


Exactly, what make me expected behavior? What will make you expected behavior?

Let a view:
- I have 5 groups, 2 in them has 2 member with large size - 2G, 3 first default groups was in one disk, others was not.
logvnp@VNP> set pagesize 6000
logvnp@VNP> set linesize 600
logvnp@VNP> col MEMBER format a30
logvnp@VNP> select l.group#, lf.member, l.bytes/1024/1024 mb, l.status, l.archived
  2  from v$logfile lf, v$log l
  3  where l.group# = lf.group#
  4  order by 1, 2;

    GROUP# MEMBER                                 MB STATUS           ARC
---------- ------------------------------ ---------- ---------------- ---
         1 /vnporadataSYSTEM/VNP/redo01.l         50 INACTIVE         YES
           og

         1 /vnporadataSYSTEM/VNP/redo_add         50 INACTIVE         YES
           01.log

         2 /vnporadataSYSTEM/VNP/redo02.l         50 INACTIVE         YES
           og

         2 /vnporadataSYSTEM/VNP/redo_add         50 INACTIVE         YES
           02.log

         3 /vnporadataSYSTEM/VNP/redo03.l         50 INACTIVE         YES
           og

         3 /vnporadataSYSTEM/VNP/redo_add         50 INACTIVE         YES
           03.log

         4 /vnprctl/redoVNP_multiplex/red       2000 INACTIVE         YES
           o04.log

         4 /vnprctl/redoVNP_multiplex/red       2000 INACTIVE         YES
           o05.log

         5 /vnprctl/redoVNP_multiplex/red       2000 CURRENT          NO
           o06.log

         5 /vnprctl/redoVNP_multiplex/red       2000 CURRENT          NO
           o07.log


10 rows selected.

5 groups in 2 separate disks, and I think, the LGWr can write down to the current log files with the I/O disk in the different way. But I think that, the parameter log_checkpoint_interval if was set to non zero can help me avoid this message
logvnp@VNP> show parameter log_checkpoint_interval

NAME                                 TYPE        VALUE
------------------------------------ ----------- --------
log_checkpoint_interval              integer     0


The note 372557.1 wrote
Quote:

These messages are not a cause for concern unless there is a significant gap in seq# between the "cannot allocate new log" message and the "advanced to log sequence" message.



Now, I see:
Thread 1 cannot allocate new log, sequence 415
Private strand flush not complete
  Current log# 4 seq# 414 mem# 0: /vnprctl/redoVNP_multiplex/redo04.log
  Current log# 4 seq# 414 mem# 1: /vnprctl/redoVNP_multiplex/redo05.log
Thread 1 advanced to log sequence 415
  Current log# 5 seq# 415 mem# 0: /vnprctl/redoVNP_multiplex/redo06.log
  Current log# 5 seq# 415 mem# 1: /vnprctl/redoVNP_multiplex/redo07.log


Quote:

Clarify what ?



Yeap! I am sorry about my careless post, I've not just understood about

Quote:

User sessions trying to generate redo, wait on this event when LGWR waits for DBWR to complete flushing redo from IMU buffers into the log buffer; when DBWR is complete LGWR can then finish writing the current log, and then switch log files.


http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3117

User session trying to generate redo, is it that like 'User A tried to commit, but really, LGWr does not write to the current log?'

Thank you!

[Updated on: Tue, 22 July 2008 03:29]

Report message to a moderator

Previous Topic: Help (Sybase)
Next Topic: Failure to extend rollback segment because of 30036 condition
Goto Forum:
  


Current Time: Sat Apr 27 09:03:03 CDT 2024