Kbase P103761: Using After Image Explained
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
9/18/2009 |
|
Status: Verified
GOAL:
Using After Image Explained
GOAL:
Using After Imaging Explained
GOAL:
What is After Imaging?
GOAL:
How can I use After Imaging?
GOAL:
How to manage After Image?
GOAL:
How to manage After Imaging?
GOAL:
How to perform roll-forward recovery?
GOAL:
How to enable after-image?
GOAL:
Enabling after-imaging
GOAL:
Creating new AI extents
GOAL:
Characteristics of AI extents
GOAL:
RFUTIL AIMAGE BEGIN
GOAL:
-AISTALL startup parameter
GOAL:
Effects of -AISTALL
GOAL:
Managing AI extents
GOAL:
RFUTIL AIMAGE EXTENT LIST
GOAL:
RFUTIL AIMAGE END
FACT(s) (Environment):
All Supported Operating Systems
Products / Versions
FIX:
Enabling after-imaging Overview
In order to perform a roll-forward recovery in the event of a media failure, you need first to enable after-imaging.
Enabling after-imaging is a four-step process:
1. Create new AI extents.
2. Back up your database.
3. Enable after-imaging.
4. Start up your database with the -AISTALL parameter.
Let?s learn how to perform these tasks.
Create new AI extents Introduction
The first task of enabling after-imaging is to create new AI extents for your database.
You can do this in one of two ways:
Before-the-fact when you create a new database or After-the-fact when you decide to implement roll-forward recovery after you have created the database.
Characteristics of AI extents
AI extents have the following characteristics:
Each AI storage area contains only one AI extent (that is, one AI file).
The initial size of a variable AI extent is 128K.
In general, you can create up to 994 application data and AI storage areas. The AI areas in turn can have a number of fixed and variable AI extents.
Guidelines on creating new AI extents
When creating new AI extents, follow these guidelines:
Place the AI files on a different disk from the database (.DB, .Bn, .Dn) files.
Reason: If the disk containing the database files crashed, you would still be able to perform roll-forward recovery with the disk containing the AI files, assuming that you have a full backup of the database.
Allocate enough space for the AI extents by taking into account the elapsed time between your database backups.
Guidelines on allocating space to new AI extents
Before creating AI extents, you need to estimate the amount of disk space your database may require to store all the AI data. By doing so, you improve your database performance.
Reason: With pre-allocated AI extents, all OpenEdge RDBMS needs to do is to write AI data to them, whereas with variable AI extents OpenEdge RDBMS needs to format and write data as it goes along. Performance is better in the former and poorer
in the latter.
Follow these guidelines:
Determining the BI cluster size
1. Start up the database.
2. Invoke PROMON on the database. Use this syntax:
promon db-name
Important note: For best result, invoke PROMON just before you do a backup. This will show how much data is actually written to the BI file between backups.
3. Enter R&D for advanced options.
4. Enter 1 for Status Displays.
5. Enter 9 for BI log.
6. Make a note of the BI cluster size.
7. Enter X to exit PROMON.
Determining the number of checkpoints during a typical day
1. Invoke PROMON on the database again.
2. Enter 5 for Activity.
3. Make a note of the number of checkpoints.
Determining the number of days between backups
Using your backup schedule, determine the number of days between backups.
Calculating space for new AI extents.
1. Multiply the BI cluster size by the number of checkpoints.
2. Multiply the result by the number of days between backups.
3. Use the result to allocate space to your AI extents.
Procedure to create new AI extents
If your database already contains AI extents, then you will just need to enable afterimaging.
We will show you how to do this shortly.
If you want to create new AI extents for your database, follow these steps:
1. Create a new .ST file describing the new AI extents.
2. Truncate the BI file of the database using the PROUT.IL utility.
3. Add the new extents to the storage area using the PROSTRCT ADD utility.
4. Verify that the new extents have been added using PROSTRCT LIST.
Demonstration Creating new AI extents for the MYDB database
Currently, MYDB doesn?t have any AI extents. Let?s create three new AI extents, two fixed and one variable, for it. Follow these steps:
Create a new .ST file describing the new AI extents
1. Choose Start Programs Accessories Notepad.
2. Enter the following:
a .\mydb.a1 f 384
a .\mydb.a2 f 384
a .\mydb.a3
3. Save the file as MYDB_AI.ST, and store it in C:\OpenEdge\WRK\DBA\Demos.
4. Choose File Exit.
Truncate the BI file of MYDB using PROUTIL
1. Choose Start Programs OpenEdge Proenv.
2. Change your working directory to C:\OpenEdge\WRK\DBA\Demos:
cd dba\demos
3. Truncate the BI file of MYDB:
proutil mydb -C truncate bi
Adding the new AI extents to MYDB
prostrct add mydb mydb_ai.st
Verifying that the new AI extents have been added to MYDB
prostrct list mydb
Back up the database Introduction
The second task of enabling after-imaging is to perform a full offline backup of your database (we will discuss online backups in the context of roll-forward recovery later).
You can use either of the two methods shown in Lesson 5, Backing Up and Restoring a Database:
Back up the required files of a database using PROBKUP, and back up the optional files using a non-OpenEdge RDBMS backup utility, or Back up all your database files using a non-OpenEdge RDBMS backup utility.
Note Roll-forward recovery works with incremental database backups as well. So, you can perform incremental backups of your databases if your backup strategies call for it. Make sure to:
Label and archive the incremental backups properly.
Perform a full backup of the database.
Using PROBKUP
Follow these steps:
1. Shut down the database.
2. Back up the required files of your database using PROBKUP. Use this syntax:
probkup db-name [incremental] backup-filename
3. Using your O/S tools, back up the optional files of your database.
Using a non-OpenEdge RDBMS backup utility
Follow these steps:
1. Shut down the database.
2. Back up all your database files using a non-OpenEdge RDBMS backup utility.
3. Mark your database as backed up using RFUTIL. Use this syntax:
rfutil db-name -C mark backedup
Demonstration Backing up the MYDB database
Let?s perform a full offline backup of the MYDB database. Follow these steps:
1. Shut down MYDB, if it isn?t already down:
proshut mydb -by
2. Back up the required files of MYDB using PROBKUP:
probkup mydb mydb.bck
Enable after-imaging
Introduction
The third task of enabling after-imaging is to enable after-imaging immediately after you have completed backing up your database.
As a result, OpenEdge RDBMS begins to record notes about committed transactions to the AI files on disk.
RFUTIL AIMAGE BEGIN
To enable after-imaging, use the RFUTIL utility with the AIMAGE BEGIN qualifier.
Its syntax is as follows:
rfutil db-name -C aimage begin
# Demonstration Enabling after-imaging for the MYDB database
Let?s enable after-imaging for MYDB. Enter:
rfutil mydb -C aimage begin
Start up the database with -AISTALL
Introduction
If all the AI extents are filled up while OpenEdge RDBMS is still writing AI notes to disk, then OpenEdge RDBMS would write an error message to the database log file, indicating that the. AI extent is full, and shut down the database.
To prevent this occurrence, the fourth task of enabling after-imaging is to start up your database using PROSERVE with the -AISTALL parameter.
-AISTALL parameter
The syntax of PROSERVE with -AISTALL is as follows:
proserve db-name -aistall
Effects of -AISTALL
When all your AI files are filled, OpenEdge RDBMS doesn?t abruptly shut down the database. Instead, it suspends all writes and logins (reads are permitted), giving you the opportunity to back up and empty existing full extents. (We will show you how to back up and empty full extents shortly.)
Once new empty AI extents are available, OpenEdge RDBMS resumes writing AI notes to them, and database operations continue.
# Demonstration Start up the MYDB database with -AISTALL
Let?s start up MYDB with -AISTALL. Enter:
proserve mydb -H localhost -S 2000 -aistall
Managing AI extents
Introduction
Once you have enabled after-imaging for a database and started it up with -AISTALL, users can access the database. As they make data changes, OpenEdge RDBMS continuously writes AI notes about committed transactions to the AI files on disk.
In the meantime, it is very important for you to manage your AI extents so that:
They always have room for OpenEdge RDBMS to write to.
They are properly backed up whenever you back up your database.
How AI extents are used
To manage AI extents properly, you need to know how OpenEdge RDBMS uses them:
OpenEdge RDBMS fills the AI extents in the order defined in the .ST file.
OpenEdge RDBMS fills a fixed extent until it becomes full, then automatically switches to the next empty extent.
OpenEdge RDBMS fills a variable extent until any of the following happens:
The extent uses up the entire disk, The disk is full, You manually switch to a new AI extent or You disable after-imaging.
After using the last available empty extent in the sequence of AI extents, OpenEdge RDBMS would loop back and use the first available empty extent, a round robin mode of operation.
Extent management tasks
Managing AI extents includes the following tasks:
Monitor AI extents.
Back up a full AI extent.
Back up the database and all its AI extents.
Let?s learn how to perform these tasks.
Monitor AI extents
Introduction
You need to monitor the status of the AI extents regularly to ensure that they don?t ever get filled up but always have room for new AI notes.
RFUTIL AIMAGE EXTENT LIST
To monitor the AI extents, use RFUTIL with the AIMAGE EXTENT LIST qualifier.
Its syntax is as follows:
rfutil db-name -C aimage extent list
Extent report
RFUTIL AIMAGE EXTENT LIST generates an extent report, of which the following properties are the most important:
Property Description Status The three possible values are:
Empty means the extent is available for use.
Busy means the extent is currently in use.
Full means the extent has filled up.
Type Shows whether the extent is fixed-length or variable-length.
Size Shows the AI file size in 1K blocks.
Used Shows the number of blocks used in each file.
Seqno Shows the sequence number of the extent.
When performing roll-forward recovery, you must apply the AI extents in the sequence they were written by OpenEdge RDBMS.
Guidelines on monitoring AI extents
When monitoring AI extents, follow these guidelines:
As your transactions grow, increase the amount of space for AI extents.
Back up and empty an existing full extent if the last available extent is about to be filled or if the disk is getting full. You will learn how to do this next.BR>Add a new extent.
Demonstration Monitoring the AI extents of the MYDB database
Enter:
rfutil mydb -C aimage extent list
Back up a full AI extent
Introduction
AI extents do get filled over time. While monitoring AI extents, you may notice that one or more AI extents are full. In that event, you should back them up. If the backup is successful, then empty them out, making them available for OpenEdge
RDBMS to write future AI notes.
For example, let?s say you have three AI extents: the first two are full and the last one is currently being written to. You need to back up and empty the first two full AI extents.
Procedure to back up a full AI extent
To back up a full AI extent and make it reusable, follow these steps:
Step Action
1. Determine the oldest filled AI file using RFUTIL AIMAGE EXTENT FULL.
2. Back up the extent to a different disk using an O/S utility.
3. Rename the backup extent to something else using an O/S utility.
4. Copy the backup extent to a different machine. This provides an additional and much needed layer of protection to your backup extents, just in case your database machine suffered an irrecoverable crash.
5. Empty the filled AI file using RFUTIL AIMAGE EXTENT EMPTY.
RFUTIL AIMAGE EXTENT FULL
To determine the oldest filled AI file to back up, use RFUTIL with the AIMAGE EXTENT FULL qualifier. Its syntax is as follows:
rfutil db-name -C aimage extent full
RFUTIL AIMAGE EXTENT EMPTY
To empty an AI extent, use RFUTIL with the AIMAGE EXTENT EMPTY qualifier.
Its syntax is as follows:
rfutil db-name -C aimage extent empty [extent-number | extent-path]
Bear in mind the following:
If you do not specify either an extent number or an extent path, RFUTIL marks the oldest full extent as empty.
Variable extents are automatically truncated when they are marked as empty.
Demonstration Backing up a full AI extent of the MYDB database
First, let?s add a lot of customers so we can fill an extent. Then we?ll backup that full extent. Follow these steps:
1. Add a lot of customer records to the Customer table of MYDB. Enter:
mpro mydb -p addlotcust.p
2. Now, let?s determine the oldest filled extent of MYDB. Enter:
rfutil mydb -C aimage extent full
Result: Your result should show:
C:\OpenEdge\WRK\DBA\Demos\mydb.a1
3. Copy and paste mydb.a1 to C:\OpenEdge\WRK\DBA\Archives.
4. In C:\OpenEdge\WRK\DBA\Archives, rename mydb.a1 to mydb.a1.01.
5. As a best practice, here you would copy mydb.a1.01 to another machine to provide it an additional layer of protection in case your database machine suffered an irrecoverable crash.
6. Let?s empty the mydb.a1 extent, making it reusable. Enter:
rfutil mydb -C aimage extent empty 1
7. Now, let?s take a look at the latest extent list of MYDB. Enter:
rfutil mydb -C aimage extent list
Result: The status of Extent 1 (mydb.a1) should show Empty.
Back up the database and all its AI extents
Introduction
Based on your backup schedule, you will need to periodically back up the database and all its AI extents, and begin anew the roll-forward recovery process.
In order to perform these backups, you need first to disable after-imaging. This will cause OpenEdge RDBMS to stop writing AI notes to the AI extents, mark all the AI extents as empty, and reset its pointer to the beginning of the AI files.
RFUTIL AIMAGE END
To disable after-imaging, use RFUTIL with the AIMAGE END qualifier. Its syntax is as follows:
rfutil db-name -C aimage end
Procedur.e to back up a database and all its AI extents
To back up a database and all its AI extents, follow these steps:
1. Shut down the database.
2. Back up all its AI extents using an O/S utility.Make sure to do this before proceeding to Step 3, because when you disable after-imaging, OpenEdge RDBMS marks all of the AI extents as empty. This means you cannot access the AI extents you did not back up to do roll-forward recovery.
3. Disable after-imaging.
4. Back up the database.
Naming AI extents
Keep in mind that during the course of managing and backing up AI extents, you might end up with two sets of AI extents:
Filled AI extents you have backed up, and AI extents you must back up as part of the database backup process.
Both sets of AI extents are necessary since they enable you to recover committed data since the last full backup if your disk got lost or damaged. As a result, it is extremely important for you to come up with a naming convention that shows both sets of AI extents as a cohesive whole.
Suggested naming convention for AI extent backups
We recommend this naming convention for your AI extent backups:
Start with the AI extent name. For example, mydb.a1.
Add to it a six-digit suffix that represents the date and time of the backup.
For example, mydb.a1.1203030805 means the file was backed up on December 3, 2003 at 8:05 AM.
Add to the result a two-digit suffix that represents the order the AI extents were written to. For example, mydb.a1.1203030805.01.
Benefit: With this naming convention, you achieve the following two benefits in the event you need to recover your data:
Choose the right AI extents with the right database backup, thanks to the date and time stamp.
Apply the AI extents in the right sequence, thanks to the order number.
Example
To illustrate the importance of naming AI extents properly, let?s use this scenario.
Assume that every night, you perform a full backup of your MYDB database and all its AI extents. MYDB has three AI extents.
Here is what might happen during the course of one day:
At 10:20 AM, you monitor the AI extents of a database and notice that two of them (mydb.a1 and mydb.a2) are full.
You back up these two filled AI extents to a different disk.
At 5:30 PM, you perform a full backup of your database, and back up the three AI extents (mydb.a1, mydb.a2, and mydb.a3).
Question: How do you name all the AI extents?
If you follow our naming convention, you would name the AI extents as follows:
mydb.a1.1203031020.01 The oldest filled AI extent at 10:20 AM.
mydb.a2.1203031020.02 The second filled AI extent at 10:20 AM.
mydb.a3.1203031730.03 The AI extent with the lowest sequence number at 5:30 PM.
mydb.a1.1203031730.04 The AI extent with the intermediate sequence number at 5:30 PM.
mydb.a2.1203031730.05 The AI extent with the highest sequence number at 5:30 PM.
Demonstration Backing up the MYDB database and all its AI extents
Let?s back up the MYDB database and all its AI extents. Follow these steps:
1. Shut down MYDB:
proshut mydb -by
2. Copy and paste the three AI files to C:\OpenEdge\WRK\DBA\Archives.
3. In C:\OpenEdge\WRK\DBA\Archives, rename the AI files as follows:
mydb.a2 mydb.a2.02
mydb.a3 mydb.a3.03
mydb.a1 mydb.a1.04
Recall that earlier you had backed up a filled extent, mydb.a1, and renamed it mydb.a1.01.
4. Disable after-imaging for MYDB:
rfutil mydb -C aimage end
5. Back up MYDB to another backup version, MYDB2.BCK:
probkup mydb mydb2.bck
Pairing AI files with database backups
Introduction
It is very important for you to pair the right AI files with t.he right database backups.
With the right pairing, you will be able to recover all your committed transactions regardless of when a media failure occurred.
How to pair
Pair the latest set of AI files with the immediate previous database backup.
Example:
Let?s say you do a full offline backup of your database and archive your AI files every night of the week.
Here is how you should pair the database backups and their archived AI files:
Pair Sunday night database backup with Monday night AI files.
Pair Monday night database backup with Tuesday night AI files.
Pair Tuesday night database backup with Wednesday night AI files, and so on.
Scanning AI files for information
A good tool to use in pairing AI files is the RFUTIL utility with the AIMAGE SCAN qualifier, which scans an AI file for information. Its syntax is as follows:
rfutil db-name -C aimage scan -a ai-file [verbose]
Where: verbose Shows information about the AI area such as transaction number, date and time of the transaction, and the ID of the user who initiated the transaction.
Demonstration Scanning an AI file for information
Let?s scan an archived AI file, mydb.a1.01, of the MYDB database for information.
Enter:
rfutil mydb -C aimage scan -a ..\archives\mydb.a1.01
Result: Your result may look like this:
OpenEdge Release 10.0A as of Sat Dec 13 02:37:30 EST 2003
After-image dates for this after-image file: (1633)
Last AIMAGE BEGIN Mon Feb 02 12:59:19 2004 (1640)
This file was last opened for output on Mon Feb 02 13:22:44 2004. (1643)
5102 notes were processed. (1634)
0 in-flight transactions. (3785)
554 transactions were started. (1635)
553 transactions were completed. (11138)
At the end of the .ai file, 1 transactions were still active. (1636)
The important piece of information in this report is Last opened for output date and time stamp. Use it to match the AI file with the right database backup file.
Managing AI files with online database backups
Introduction
So far, we have implicitly advocated that you perform full offline backups of your databases in the roll-forward recovery process. This is simpler to do and manage than doing online backups. The reason is that you can easily pair your offline
database backups with their archived AI files.
However, if you need to support databases for which the only backups you can do are online, then you need to know how to pair which database backups with which AI files in this in-flux environment.
Guidelines
When managing AI files with online database backups, follow these guidelines:
Examine your database log (.LG) file to determine which AI files go with which database backups.
Create a script that monitors AI extents and periodically backs up the filled AI extents. See the script below.
Script for backing up AI files
The following script in pseudo code monitors the AI extents of an online database every 15 minutes and backs up any filled AI extents:
Begin outer loop
Define var1 and var2.
Test for full AI extent.
Assign the result to var1.
Begin inner loop
While var1 is not Database has no full extents. Then
Assign current date-and-time to var2.
Do
Copy full AI extents to a different disk/machine.
Rename copied extents to (db-name + var2).
Done.
Check if copy was successful.
If copy was successful then
rfutil aimage empty.
[optional] proquiet db-name disable.
Else notify DBA about failure.
Test for full AI extent.
Assign the result to var1.
Goto inner loop.
Else
Break.
End inner loop
Sleep 900. # 15 minutes
End outer loop
Performing roll-forward recovery using after-imaging
Introduction
By now, you have implemented all the necessary steps of enabling after-imagi.ng and backing up the database and its AI files. The end results are correct pairs of database backups and AI files. You are now ready for any disaster that might befall your database.
If suddenly your database was lost because of disk damage, you could perform rollforward recovery using after-imaging. Essentially, you will create a brand-new database based on the most recent database backup, and roll it forward by applying the AI extents that have been accumulated up to the moment of disk failure. The end result would be a new database containing all the committed transactions up to the moment of disk failure.
Note If your database machine crashed, you need to have the following components on the hot spare backup machine in order to do roll-forward recovery:
The last full backup of the database,
All incremental backups,
All the filled AI extents you have periodically archived (that is, copied to a different disk or a separate machine),
If possible, the filled AI extents that you had not yet archived at the moment of the crash, and If possible, the busy AI extent to which OpenEdge RDBMS was still writing at the moment of the crash.
If the last two are not recoverable, you?d lose committed transactions in those files.
How to perform roll-forward recovery
To perform roll-forward recovery, follow these steps:
1. Make sure you have enough disk space for the new database.
2. Restore the last full backup to a new database.
3. Restore all the incremental backups, if used, to the database.
4. Apply all AI extents to the database in the sequence they were written.
5. Back up the database.
6. Enable after-imaging for the database.
RFUTIL ROLL FORWARD
To apply AI extents to a database, use RFUTIL with the ROLL FORWARD qualifier. Its syntax is as follows:
rfutil db-name -C roll forward [endtime yyyy:mm:dd:hh:mm:ss | endtrans transaction-number verbose] -a ai-file
Where: Parameter Description endtime Rolls forward to a certain time.
For example, to roll forward to 10:10 AM on February 3, 2004, use 2004:02:03:10:10:00. This partial roll forward includes all transactions that have ended on or before 10:10 AM on February 3, 2004. endtrans Rolls forward up to but excluding the transaction with the specified transaction number.
For example, if you use endtrans 1000, RFUTIL rolls forward the AI extents to include transaction 999. If you use endtrans 1001, RFUTIL rolls forward the AI extents to include transaction 1000. verbose Logs roll-forward information for every note in the AI extents.
Demonstration Performing roll-forward recovery for the MYDB database
Assume that your database machine crashed, but you have all the necessary pieces to do roll-forward recovery on a hot spare backup machine:
The last full backup of MYDB, mydb.bck, (this is the backup version before after-imaging was enabled) and
Its associated archived AI extents (mydb.a1.01, mydb.a2.02, mydb.a3.03, and mydb.a1.04).
To perform roll-forward recovery, follow these steps:
1. Since we don?t have a hot spare machine, let?s simulate it by deleting our current irrecoverable MYDB database:
prodel mydb
2. First, let?s restore the MYDB.BCK backup to a new MYDB:
prorest mydb mydb2.bck
3. Apply the first AI extent to MYDB:
rfutil mydb -C roll forward -a ..\archives\mydb.a1.01
4. Apply the second AI extent to MYDB:
rfutil mydb -C roll forward -a ..\archives\mydb.a2.02
5. Apply the third AI extent to MYDB:
rfutil mydb -C roll forward -a ..\archives\mydb.a3.03
Result: You should see the following message:
Can't roll forward an empty after-image extent file. (3780)
This is OK since .this extent contains no committed transactions. You don?t need to roll forward the fourth AI extent.
6. Back up MYDB to a new backup version:
probkup mydb mydb3.bck
7. Since a database backup doesn?t include AI extents, the new MYDB database doesn?t include AI extents either. So, let?s add the new AI extents to MYDB:
prostrct add mydb mydb_ai.st
8. Enable after-imaging for MYDB:
rfutil mydb -C aimage begin
Resuming interrupted roll-forward recovery
If your system crashed or a power outage occurred while you were doing roll-forward recovery, you wouldn?t have to restart the process from scratch. Instead, use RFUTIL with the RETRY qualifier to resume recovering the database from the point
of failure. Its syntax is as follows:
rfutil db-name -C roll forward retry -a ai-file
Example:
Suppose that while you were applying the second extent, mydb.a2.02, to the MYDB database, the power went out. To resume the recovery operation, enter:
rfutil mydb -C roll forward retry -a mydb.a2.02
When Rolling Forward AI files to databases which were not made with the Progress Backup utility:
1. Make sure the structure of the database is correct for the current location of the database. If necessary modify the current .st file and update the correct location then use the prostrct repair function to update the structure information of the database.
Example:
prostrct repair my-os-restored-database my-updated.st
2. Issue the rfutil -C sequence command against the database.
Example:
rfutil my-os-restored-database -C sequence
3. Roll forward as is listed in the above sections..