The following code example demonstrates the steps for making a hot standby database using an operating system copy command, but in this example, updates to the database occur at an earlier point in the process. These updates require that the sequence of the target database be corrected prior to rolling forward an AI extent:

# Update your source database by adding after-imaging extents
#
prostrct add production_db add.st

# truncate the database BI file and mark as backed up
#
proutil production_db -C truncate bi 
rfutil production_db -C mark backedup

# Activate after-imaging
#
rfutil production_db -C aimage begin 

# At this point allow updates to the source database. This activity will 
# fill the first AI extent, production_db.a1, and causing a switch to the
# second AI extent, production_db.a2.

# Make a copy of the database using operating system commands
#
cp production_db* /db_standby

# Mark the source database as backed up
#
rfutil production_db -C mark backedup

# Fix the target database file specifications and make new database st file.
#
prostrct repair /db_standby/production_db /db_standby/standby.st
prostrct list /db_standby/production_db /db_standby/production_db.st

# Correct the sequence number of target database.
#
rfutil /db_standby/production_db -C sequence

# Roll forward the second AI extent from production_db to standby copy.
# This is the extent which was BUSY at the time the copy of the database
# was made.
#
rfutil /db_standby/production_db -C roll forward -a production_db.a2

# Continue allowing updates and regularly roll forward the subsequent AI
# extents from the production_db to the standby copy.

The target database must have its sequence corrected prior to attempting to apply an AI extent with roll forward. Roll forward disables after imaging, and it is impossible to correct the sequence once after imaging has been disabled. If the roll forward on the target database fails, you must recopy from the source, use RFUTIL SEQUENCE to correct the sequence number, and then roll forward.