Hello Kana, your assumption is right.
The tasks are doing now this (in your showed snapshot): T4 (utility) has started the restart and waits for the servertasks it has started. T31 (redo log reader) has read all log and is waiting for the redo excution tasks. T51 (redo execution) is the redo task which executes the rollback The other redo execution server tasks have nothing to do. The "reduce" message is harmless. Best regards Uwe >Hi Hahn Uwe, > >The undo of the long deletion is still going on. Just need >confirmation on the show suspend information below on >Vsuspend(228). Does this shows that everything is waiting for >end of all RedoTask.? > >PRDMTS> show suspend >OK > >SERVERDB: PRDMTS > >List of suspend reasons: >======================== > >total suspends: 329127 > >Vsuspend (054) : 25 ( 0.01% ) >Pager_Controller::WaitForDwReply >Vsuspend (212) : 1 ( 0.00% ) kb90parent_wait > >Vsuspend (228) : 1 ( 0.00% ) RedoReader waits for end >of all RedoTask >Prep-End (230) : 4 ( 0.00% ) bd13GetNode > >NoRedoJob(231) : 46 ( 0.01% ) >Rst_RedoTrafficControl::ExecuteJobs() >No-Work (255) : 329050 ( 99.98% ) Task is waiting for work > > >Show io shows the read and write counts increasing. > >Show active is below. > >D UKT Win TASK APPL Current Timeout Region Wait > tid type pid state priority cnt >try item >T4 3 0x7E4 Utility 2124 Vsuspend (212) 0 0 > 25(s) >T31 4 0x76C Server Vsuspend (228) 0 0 > 7463358(s) >T36 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T37 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T38 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T39 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T40 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T41 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T42 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T43 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T44 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T45 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T46 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T47 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T48 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T49 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T50 4 0x76C Server NoRedoJob(231) 0 0 > 7463358(s) >T51 4 0x76C Server IO Wait (R) 0 0 >1 7463358(s) > >The following begins to appear now in the KNLDIAG > >2005-01-14 10:06:04 0x76C 53000 DATACACH Reduce Data >Cache (LRU): 1157 > >Should i be concerned about it. > > >Thank you > >Best Regards, > >Kana > > >-----Original Message----- >From: Hahn, Uwe [mailto:[EMAIL PROTECTED] >Sent: Thursday, January 13, 2005 5:03 PM >To: Kana; [email protected] >Cc: Chong June Seng >Subject: RE: Monitoring the progress of Restart recovering log from >log_volume from IOSeq: '3273458' > > >The exclamation makr means that this task has a cancel flag set. >This could relate in another abort after the undo is finished. >The next restart will the undo begin at the last savepoint >during the redo. >So the time of the restart (undo of long delete trans) will >take less time then before. >Kind regards >Uwe >>-----Original Message----- >>From: Kana [mailto:[EMAIL PROTECTED] >>Sent: Thursday, January 13, 2005 10:00 AM >>To: Hahn, Uwe; [email protected] >>Cc: Chong June Seng >>Subject: RE: Monitoring the progress of Restart recovering log >>from log_volume from IOSeq: '3273458' >> >> >> >>Hahn,Uwe & D�hr, Markus thanks for your quick support. >> >>I now see the following; Should i be concern on the T4 >>activity has a cancel flag (exclamation mark) >> >>PRDMTS> show active >>OK >>SERVERDB: PRDMTS >> >>ID UKT Win TASK APPL Current Timeout Region >> Wait >> tid type pid state priority cnt >>try item >>T4 3 0x864 Utility 2252 Vsuspend (212) ! 0 0 >> 713(s) >> >>KNLDIAG now shows >>--------------------------------------------------------------- >>----------------- >>Date Time TID(hex) Typ MsgID Label Message-Text >>--------------------------------------------------------------- >>----------------- >>. >>2005-01-13 16:44:09 0x3D8 19648 CONNECT Unreleased >>connection found, T4 >> >> >>Thank you. >> >>Kana >> >>-----Original Message----- >>From: Hahn, Uwe [mailto:[EMAIL PROTECTED] >>Sent: Thursday, January 13, 2005 3:49 PM >>To: Kana; [email protected] >>Cc: Chong June Seng >>Subject: RE: Monitoring the progress of Restart recovering log from >>log_volume from IOSeq: '3273458' >> >> >>Hello Kana, >> >>first of all switching off the redo log means that only a >>savepoint (not a commit!!!) >>makes your transaction persistent. So even if your delete >>command would be committed, >>if the redo log was disabled by you and the database crashes >>for any reason and there was no savepoint >>after your delete transaction this transaction is rollbacked. >>So I think switching off the redo log is not really a solution >>for performance issues. >>... >> >>>-----Original Message----- >>>From: Kana [mailto:[EMAIL PROTECTED] >>>Sent: Thursday, January 13, 2005 3:15 AM >>>To: "D�hr, Markus ICC-H"; [email protected] >>>Cc: Chong June Seng >>>Subject: RE: Monitoring the progress of Restart recovering log >>>from log_volume from IOSeq: '3273458' >>> >>> >>>Grateful if you could help interpret these data. >>>Is it recovering from 3273458 -> 3273461 ? >> >>Yes the redo log is processed from iosequence ...58 to ...61 >>and Markus is right that your aborted open delete transaction >>will be rollbacked for a long time. >>The knldiag will only show the progress of the redo read task >>but not of the redo execute tasks. >>So the only chance to see something from the rollback is to >>use the console output ("dbmcli ... show active" "dbmcli ... >>show io") or the knltrace (trace_on, trace_flush, trace_prot). >>... >> >>> >>>2005-01-12 20:33:42 0x864 7 Log Oldest not >>>saved is ioseq 3254654 @ off 5219 >>>2005-01-12 20:33:42 0x864 8 Log First known >>>on LogVolume is ioseq 3206963 @ off 23641 >>>2005-01-12 20:33:42 0x864 5 Log Restart from >>>ioseq 3273458 @ off 23639 to ioseq 3273461 @ off 23640 >>>2005-01-12 20:33:42 0x864 10 Log Result after >>>checking the log device: 'Ok' >>>2005-01-12 20:33:42 0x8D8 3 Restart recovering >>>log from log_volume from IOSeq: '3273458' >>>2005-01-12 20:33:42 0x8D8 42 Log normal end >>>of log found at off 23640 lastseq 3273461. >>>2005-01-12 20:33:42 0x8D8 12 Log >>>last-redo-read#52:TR1515814(1)[EMAIL PROTECTED]'Commit':2005 >>>0112:201706 >>> >>> >>>Now i am begining to get these information. Am I close to >>>going online or is it still a long way. What message should I >>>see further ? >>> >>This only means that the converter needs pages and therfore >>savepoints are triggered. >>These messages tell you that there is a progress but not >where you are. >>The estimation of Markus that the undo of your delete will >>take the same time as the delete is correct. >>As written above there are no default progress messages. >> >>Kind regards >>Uwe >> >>>2005-01-13 03:23:02 0x19C 56 Log Savepoint >>>requested by T10 reason 'FreeBlockManagement' (started). >>>2005-01-13 03:23:02 0x8D8 4 Pager SVP(1) Start >>>Write Data >>>2005-01-13 03:23:10 0x8D8 5 Pager SVP(1) Stop >>>Data IO, Pages: 4275 IO: 2850 >>>2005-01-13 03:23:10 0x8D8 6 Pager SVP(2) Wait >>>for last split, TaskId: 35 >>>2005-01-13 03:23:10 0x8D8 7 Pager SVP(2) Stop >>>Wait for last split, Pages: 0 IO: 0 >>>2005-01-13 03:23:10 0x8D8 53070 SAVPOINT B20PREPARE_SVP: 864 >>>2005-01-13 03:23:10 0x8D8 8 Pager SVP(3) Start >>>Write Data >>>2005-01-13 03:23:11 0x8D8 9 Pager SVP(3) Stop >>>Data IO, Pages: 11 IO: 9 >>>2005-01-13 03:23:11 0x8D8 10 Pager SVP(3) Start >>>Write Converter >>>2005-01-13 03:23:11 0x8D8 11 Pager SVP(3) Stop >>>Converter IO, Pages: 700 IO: 700 >>>2005-01-13 03:23:11 0x8D8 53071 SAVPOINT >>B20SVP_COMPLETED: 864 >>>. >>>. >>>. >>>. >>>. >>>. >>>2005-01-13 07:51:04 0x19C 56 Log Savepoint >>>requested by T10 reason 'FreeBlockManagement' (started). >>>2005-01-13 07:51:04 0x8D8 4 Pager SVP(1) Start >>>Write Data >>>2005-01-13 07:51:14 0x8D8 5 Pager SVP(1) Stop >>>Data IO, Pages: 4575 IO: 3425 >>>2005-01-13 07:51:14 0x8D8 6 Pager SVP(2) Wait >>>for last split, TaskId: 35 >>>2005-01-13 07:51:15 0x8D8 7 Pager SVP(2) Stop >>>Wait for last split, Pages: 12 IO: 12 >>>2005-01-13 07:51:15 0x8D8 53070 SAVPOINT B20PREPARE_SVP: 865 >>>2005-01-13 07:51:15 0x8D8 8 Pager SVP(3) Start >>>Write Data >>>2005-01-13 07:51:15 0x8D8 9 Pager SVP(3) Stop >>>Data IO, Pages: 4 IO: 4 >>>2005-01-13 07:51:15 0x8D8 10 Pager SVP(3) Start >>>Write Converter >>>2005-01-13 07:51:16 0x8D8 11 Pager SVP(3) Stop >>>Converter IO, Pages: 699 IO: 699 >>>2005-01-13 07:51:16 0x8D8 53071 SAVPOINT >>B20SVP_COMPLETED: 865 >>> >>> >>>Thank you >>> >>>kana >>> >>> >>> >>> >>>-----Original Message----- >>>From: "D�hr, Markus ICC-H" [mailto:[EMAIL PROTECTED] >>>Sent: Thursday, January 13, 2005 12:36 AM >>>To: Kana; '[email protected]' >>>Subject: RE: Monitoring the progress of Restart recovering log from >>>log_volume from IOSeq: '3273458' >>> >>> >>>> 0x418 19631 CONNECT Connect req., but UTILITY is busy >>> >>>I think due to shutting down the instance during the long run it will >>>rollback everything, this may take as long as the deletion >>>took (depending >>>on the last commit/savepoint). >>> >>> >>>Greetz, >>> >>> >>>SIEGENIA-AUBI KG >>>Informationswesen >>> >>>i.A. >>> >>>Markus D�hr >>>SAP-CC/BC, SAPDB-DBA >>> >>>Tel.: +49 6503 917-152 >>>Fax: +49 6503 917-7152 >>>E-Mail: [EMAIL PROTECTED] >>>Internet: http://www.siegenia-aubi.com >>> >>> >>>-- >>>MaxDB Discussion Mailing List >>>For list archives: http://lists.mysql.com/maxdb >>>To unsubscribe: >http://lists.mysql.com/[EMAIL PROTECTED] >>> >>> >> > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
