Sybase ASE logging during boot/db server startup

[Former Member]

Hi database guru's,

I am not sure if I am posting in the correct area so please in that case forgive me and be so kind to "show me the way"

In the Sybase ASE 15 mydbserver.errorlog I found the following records after server reboot:
(the system has been rebooted via the standard os process, no crash or anything)

00:02:00000:00014:2013/11/10 1:12:40.35 server Recovering database 'spongebobdb'.
00:02:00000:00014:2013/11/10 1:12:40.35 server Started estimating recovery log boundaries for database 'spongebobdb'.
00:02:00000:00014:2013/11/10 1:12:22.12 server Database 'spongebobdb', checkpoint=(049112, 3), first=(93221, 3), last=(104321, 3).
00:02:00000:00014:2013/11/10 1:12:22.12 server Completed estimating recovery log boundaries for database 'spongebobdb'.
00:02:00000:00014:2013/11/10 1:12:22.12 server Started ANALYSIS pass for database 'spongebobdb'.
00:02:00000:00014:2013/11/10 1:12:22.12 server Completed ANALYSIS pass for database 'spongebobdb'.
00:02:00000:00014:2013/11/10 1:12:22.12 server Log contains all committed transactions until 2013/11/10 1:01:10.23 for database spongebobdb.
00:02:00000:00014:2013/11/10 1:12:22.12 server Started REDO pass for database 'spongebobdb'. The total number of log records to process is 1.
00:02:00000:00014:2013/11/10 1:12:22.12 server Completed REDO pass for database 'spongebobdb'.
00:02:00000:00014:2013/11/10 1:12:22.12 server Timestamp for database 'spongebobdb' is (0x0000, 0x009c46a2).
00:02:00000:00014:2013/11/10 1:12:22.12 server Recovery of database 'spongebobdb' will undo incomplete nested top actions.
00:02:00000:00014:2013/11/02 1:12:22.12 server Started recovery checkpoint for database 'spongebobdb'.
00:02:00000:00014:2013/11/02 1:12:22.13 server Completed recovery checkpoint for database 'spongebobdb'.
00:02:00000:00014:2013/11/02 1:12:22.13 server Started filling free space info for database 'spongebobdb'.
00:02:00000:00014:2013/11/02 1:12:22.13 server Completed filling free space info for database 'spongebobdb'.
00:02:00000:00014:2013/11/02 1:12:22.13 server Started cleaning up the default data cache for database 'spongebobdb'.
00:00:00000:00014:2013/11/02 1:12:22.58 server Completed cleaning up the default data cache for database 'spongebobdb'.
00:02:00000:00014:2013/11/02 1:12:22.58 server The transaction log in the database 'spongebobdb' will use I/O size of 2 Kb.
00:02:00000:00014:2013/11/02 1:12:22.58 server Database 'spongebobdb' is now online

Can somebody explain this info, is it a normal and common boot sequence which was executed?
I think the "recovery" records are normal but can someone please confirm?

Do the "REDO" messages show that transaction log was checked for any open, to-be-executed (committed) entries?

Does anyone have more info about "recovery checkpoint"?

Should I worry, could DB be corrupted? (I ran a dbcc checkdb on this db which went fine)
 
Thank you very much
CaptainDB

  

[Former Member]

Thank you very much for your time and reply. Actually I don't use any Sybase -- SAP combo, we just use Sybase for other business related software.

[Former Member]

Thanks a LOT for your time and explanation, really very helpful.

The "recovery" process as such is always executed, right? This is just Sybase' way to online the DB?
If I am correct Sybase will never start a corrupted (or suspected) DB, right?

Thanks!

[former_member188958]

Yes, recovery is ASE's way to online the database.  (though "online" has it's own connotation, it is the command used to invoke the final stage of recovery once you are done loading a sequence of transaction log dumps).

In general, whenever you reboot ASE, recovery will be run on all the databases on the server that aren't marked 'suspect', 'read-only', 'for load', or 'bypass recovery'.  An exception is if the server is booted with traceflag 3608, in which case only the master database is recovered, or 3607, in which case no recovery is done at all.

If I am correct Sybase will never start a corrupted (or suspected) DB, right?

Depends on the corruption.

If recovery encounters corruption that it can't resolve, it marks the database suspect.  On future reboots, ASE will skip trying to recover databases that are marked suspect.

Recovery is able to resolve (or at least bypas) some forms of corruption using the Recovery Fault Isolation features.  This isn't commonly done.  Details are in the ASE SA Guide, Vol 2:  Fault isolation during recovery

It is also possible for a database to contain corruption on rows or pages that aren't involved in the recovery process.  (For example, hard drive faults can cause corruption on pages that haven't been modified recently and so have no log records involved in recovery).

-bret

[Former Member]

Thanks Bret for your time and reply, very useful info.