Grass Valley Aurora Transfer v.6.0b - Manual (Page 65)

September 11, 2006 Aurora Transfer Instruction Manual 65
Chapter
5
Recovery Planning
Establish a recovery plan in the event a Aurora Transfer machine fails, so that Aurora
Transfer services can be re-configured rapidly to minimize impact.
Server failure considerations
The SQL database should be backed up on a regular basis and stored in a safe location.
In the case of server failure the database can then be restored to minimize data loss. If
an off-line backup server is purchased it should be pre-configured to operate in the
system so in case of primary server failure, minimal time will be spent bringing up the
backup system. The backed up database could be restored to this backup server on a
regular basis.
Database maintenance and administration
Aurora Transfer utilizes the SQL full recovery model and a maintenance plan is
essential to keeping the database in working order. Not only does the database need
to be backed up but the accompanying transaction log needs to be backed up as well.
Failure to back up the transaction log can cause the database to become inoperable due
to the transaction log file growing too large.
The transaction log is responsible for keeping track of all the edits to data until it
reaches what is known as a checkpoint. Once the checkpoint is reached, the data
should be permanently committed to the database. Problems arise when this
checkpoint is reached, data is not committed to the database, and the transaction log
continues to grow. If the transaction log reaches the capacity of growth it can render
the database inoperable. In the event that the database has been rendered inoperable,
a manual truncation of the transaction log will need to be performed, as explained in
“Repairing a database that is unusable due to transaction log size” on page 65 .
Adopt the following practices to keep the database healthy:
• Daily monitor the growth of the transaction log daily, as explained in “How to
determine the size of the transaction log” on page 66 .
• When necessary, manually back up the database and the transaction log, then
shrink the transaction log file to release disk resources to the operating system, as
explained in
“Manually controlling transaction log growth” on page 66 .
• Set up a database maintenance plan. This automatically backs up the transaction
log and the database. Refer to “Setting up a database maintenance plan” on
page 67 .
Repairing a database that is unusable due to transaction log size
If the database is rendered inoperable due to the transaction log becoming too large,
it is highly likely that the transaction log has never been backed up, a database
maintenance plan has not been enabled on the system, or the SQL Server agent is not
running to implement your maintenance plan. The following steps should resolve the
problem: