PARTITIONED DATABASE BACKUP AND RECOVERY FOR SQLBASE 5

Information given by: Kwang-Chi Liang
Written by:           Jeannie Stienstra
-------------------------------------------------------------------------------

      THIS DOCUMENT SHOWS:

      *  An overview on backup and recovery for a non-partitioned database.
      *  The backup and recovery methods for a partitioned database.
      *  How to restore if 1 user database is defined.
      *  How to restore if more than 1 user database is defined and examples
         of how to restore MAIN.DBS and/or DBAREAs.
      *  How to restore from an Off-line backup.
      *  Problems with backup and recovery for a partitioned database.
      *  Recommended recovery method.


      OVERVIEW

          BACKUP AND RECOVERY FOR A NON-PARTITIONED DATABASE

          For a non-partitioned database the size of the database is
          not an issue because the database cannot grow out of control.
          The maximum size is about 4 gigabytes.  Administration  for
          a non-partitioned database is less difficult because most
          on-line backup files will fit onto 1 physical disk.

          A partitioned database can grow to be about a maximum size
          of 512 gigabytes.  Practically speaking, there's not the
          size restriction as with a non-partitioned database.


      BACKUP AND RECOVERY METHODS FOR PARTITIONED DATABASES

          FOR AN ON-LINE BACKUP

          A partitioned database uses the BACKUP SNAPSHOT command.
          The BACKUP DATABASE and BACKUP LOGS commands cannot be used
          for backing up MAIN database because the SYSADM password is
          unknown.  Even though it is possible to BACKUP DATABASE,
          BACKUP LOGS for user databases, it is more consistent to use
          the BACKUP SNAPSHOT COMMAND for both MAIN database and any
          user databases.

          When backing up a partitioned database, consider the following
          commands:
            1.  CREATE DBAREA    - database area.
            2.  CREATE STROGROUP - storage group.
            3.  CREATE DATABASE  - user database.

          The above commands create MAIN database.  When doing an on-line
          backup, backup MAIN database last because the information about
          DBAREA, STORGROUP and user database(s) are recorded in the
          MAIN database.

          To Create a Partitioned Database:

            1.  CREATE DATABASE AREA.
            2.  CREATE STORAGE GROUP.
            3.  CREATE DATABASE.

          To Do the On-Line Backup for a Partitioned Database:

            4.  Use the BACKUP SNAPSHOT command for the user database(s)
                and for MAIN database.

                Connected to the database BASE, issue the following
                commands:

                SQL> BACKUP SNAPSHOT TO C:\BACKUP\BASE ON CLIENT;
                SNAPSHOT BACKED UP

                Enter a SQL command

                SQL> CONNECT MAIN 2 GUEST/GUEST;

                SQL> USE 2;

                Enter a SQL command

                SQL> BACKUP SNAPSHOT TO C:\BACKUP\MAIN ON CLIENT;
                SNAPSHOT BACKED UP



      OFF-LINE BACKUP FOR A PARTITIONED DATABASE

          To do an off-line backup, shutdown the database server and
          backup from the disk to another disk or tape media.
          Backup all dbarea files, log files and MAIN database.


      WHEN RECOVERY IS POSSIBLE FOR PARTITONED DATABASES

      EXAMPLE 1:  MAIN database  and 1 user database are created
         and there is a media failure or the user's database is
         irrecoverable by a warm boot.  The recovery method for an
         on-line backup is:

         If the following has been done:

         1. Created DBAREA.
         2. Created STORGROUP.
         3. Created a user database.

         and if

         4. A BACKUP SNAPSHOT user's database and a
              BACKUP SNAPSHOT MAIN database
            was done prior to the crash, the database can be recovered
            by:

         5. Turn off partitions (partitioned databases must be disabled
            before restoring MAIN database from the backup).
         7. Proceed with recovery as described below.









         Given the following scenarios:

           MAIN database        DBAREA
           -------------        ------
         1.  Corrupted           Usable
         2.  Usable              Corrupted
         3.  Corrupted           Corrupted

         1. MAIN database is not available but the user's database is
            backed up and recoverable. MAIN database was not backed up or
            MAIN database is corrupted.  This has been verified by doing
            a CHECK DATABASE of MAIN database.

            To recover from this situation, follow these steps:

            (1) Delete MAIN database and DBAREA(s) at the system prompt.
            (2) Re-create all dbareas and stogroups.
            (3) Create the user's database.  The CREATE DATABASE command
                will cause the database to be partitioned.
            (4) Restore the user's database from the BACKUP SNAPSHOT of
                the user's database.

         2. MAIN database and the user's database have been backed up but
            the user's database is corrupted. There are two options for
            restoring in this situation

            (1) First, verify the user's database is corrupted by executing
                the CHECK DATABASE command.  If the database is corrupted,
                and it is possible, drop the user's database and re-create
                it, followed by a restore from the BACKUP SNAPSHOT.

                EXAMPLE TO RECOVER WITH A DROP DATABASE:

                C:\SQLBASE> sqlxdemo noconnect

                SQL> DROP DATABASE BASE;
                     Database dropped

                SQL> CREATE DATABASE BASE IN BASEFILES LOG TO BASEFILE2;
                     Database created

                SQL> RESTORE SNAPSHOT FROM C:\BACKUP\BASE TO BASE;
                     Snapshot restored.

            (2) If dropping the database is unsuccessful, you will have
                to start over by following the above steps for a
                corrupted MAIN database.

         3.  The recovery method is the same as situation 1 (MAIN - corrupted,
             dbarea - usable).  Follow the same steps to recover MAIN and
             user databases.

      B. Other Examples Of Crashed Database Situations - when more than
         one database is created, recovering using on-line backup method:

         The most important thing to remember when backing up a partitioned
         database with more than one user database is:
         BACKUP ***ALL*** USER DBAREAS AND MAIN database. MAIN database is
         backed up last.

         Given the following scenarios:

           MAIN database         DBAREAS
           -------------         -------
         1.  Usable              Usable
         2.  Corrupted           Usable
         3.  Usable              Corrupted
         4.  Corrupted           Corrupted

         1.  Situation #1 does not need recovery. MAIN database and the user's
             databases are not corrupted.

         Situations 2, 3 and 4 need recovery.

         2.  Situation #2 is recoverable only for the databases which
             have been backed up.  Even though MAIN database is corrupted,
             recovery of all databases is possible by restoring from
             MAIN database. Always restore MAIN database first because it
             contains all information about the user databases.

         3.  Situation #3 is recoverable.  Do a restore from the latest
             on-line backup of the user databases.

             NOTE:  You must backup all user-defined databases in order to
             recover all user databases. For example, if only 1 of 3 user
             databases were backed up, only the 1 backed up database is
             recoverable. The other 2 user databases are lost.

         4.  Situation #4 is recoverable.  To recover to current status,
             delete MAIN database and dbareas at the system prompt.
             Re-create all dbareas and stogroups. Then proceed as in the
             example below:

             Example to restore MAIN database and a user database:

             SQL> SET PARTITIONS OFF;

             Enter a SQL command

             SQL> RESTORE SNAPSHOT FROM C:\BACKUP\MAIN TO MAIN;
                  Snapshot restored

             SQL> CREATE DATABASE BASE IN BASEFILES LOG TO BASEFILE2;
                  Database created

             SQL> RESTORE SNAPSHOT FROM C:\BACKUP\BASE TO BASE;
                  Snapshot restored


      HOW TO RECOVER USING AN OFF-LINE BACKUP

          Situations 1 - 4 are recoverable with an off-line backup.
          To restore, do an off-line backup by first shutting down
          the database server.  Then restore all files from disk or
          tape to the disk where the database will reside.


      PROBLEMS WITH BACKUP AND RECOVERY FOR PARTITIONED DATABASES

      SIZE OF THE DATABASE

          A partitioned database can physically grow to be very large.
          If an on-line backup the database(s) is done, the databases
          might not fit on one physical disk.

          MAIN database has to be in sync with the user database(s). Any
          databases not backed up are lost.

      RECOMMENDED METHOD OF RECOVERY

      Because a partitioned database can become very large and it's possible
      MAIN database is not in sync with the user database(s), the preferred
      method of backup is to do an off-line backup.  The disadvantage of an
      off-line backup is that when the physical file is copied from one media
      to another, all the 'junk' (e.g., white space, non-useful information)
      is copied as well. These files may be very large in comparison with an
      on-line backup which contains only useful information.

      It is recommended that a weekly off-line or on-line backup be done. In
      conjunction with this do a daily BACKUP LOGS for user databases.
      In order to do the daily BACKUP LOGS for user databases, LOGBACKUP
      must be ON.  Doing a backup with this method will allow a ROLLFORWARD
      LOGS for user databases and to bring the database(s) back to a current
      state.




