Grass Valley Aurora Browse v.6.0b Installation - Manual (Page 111)

September 22, 2006 Aurora Browse Installation and Configuration Guide 111
Chapter
4
Recovery Planning
Establish a recovery plan in the event a Aurora Browse machine fails, so that Aurora
Browse services can be re-configured rapidly to minimize impact.
Encoder failure considerations
Encoders provide redundancy through numbers. A plan should identify the critical
encoders in the system and alternate encoders that can be reconfigured to substitute in
the case of failure. There are no automated fail-over capabilities with Aurora Browse
components. It is important to identify which machine(s) host Managed Device
Interface services. These services can be pre-installed on secondary devices, although
the server should not be configured to monitor them unless a failure of the primary
service occurs. Managed Device Interface services can exist on any encoder and the
server need only to be reconfigured to point to the new machine in case of failure.
Encoding jobs can be assigned to any available Advanced Encoder. N+1 redundancy
is achieved by adding an extra Advanced Encoder.
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.
Newer systems have redundant power supplies and mirrored disks to further protect
the integrity of the system.
Database maintenance and administration
Aurora Browse 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 112 .
Adopt the following practices to keep the database healthy:
• Daily monitor the growth of the transaction log daily, as explained in “How to