Database Reference
In-Depth Information
The first four of these will be covered in more detail in the subsections that follow. Far Sync Standby is a new
feature in Oracle database 12c and will be covered in a little later in the section “New Data Guard Features in 12.1.”
The physical standby database
The physical standby database was the first standby database option available. In all aspects, a physical standby
database is an identical bit-for-bit copy of the primary database. All schema structures, database users, and segments
are identical down to the block level.
A physical standby database is kept in sync with production through the application of redo (referred to as
“redo apply”). The process employed is the same one that a database administrator would use to recover a live
database after a media failure. Apart from disaster recovery scenarios, a standby database can be used for reporting
and backup. With a little bit of manual effort, a physical standby database can also be used for testing hot fixes on
production systems. You do this by activating it for read-write access after having taken it out of the Data Guard
configuration. Once the testing of the hot fix on like-for-like production data is complete, the Flashback Database
feature can be used to flash the database back to the point in time prior to its activation, followed by its conversion
back to a physical standby. The downside to this procedure is that, while the database is open for read-write access,
it won't receive any archived logs from the (real) primary database. This can cause a lot of network traffic once the
database has been converted back to a physical standby. Since Oracle 11.1 this manual process is no longer necessary,
and Oracle gave the database administrator a better option: the snapshot standby database discussed next.
The snapshot standby database
The snapshot standby database achieves the exact same result as the physical standby opened in read-write mode for
testing as just described in the paragraph 'The physical standby database, but without requiring that the administrator
worry about the details. The snapshot standby will continue to receive redo information from production, significantly
reducing the overhead during gap resolution. However, the redo received from production is not applied until after
the snapshot standby database has been converted back to a physical standby database, so the time it takes for the
standby database to get back in sync with production is proportional to the amount of redo to be applied.
When upgrading a database with a standby database(s) in place, the redo transport mechanism will ensure that
the dictionary changes are propagated to all destinations for as long as the catalog upgrade script is executing on the
primary site. This is true for both physical and snapshot standby database configurations. All you need to do is ensure
that the Oracle binaries on the standby servers exactly match the binaries on the primary database.
You can have both single-instance standby databases and multi-node RAC systems for your disaster recovery
solution. However, bear in mind that your standby database must to be able to cope with the workload in a disaster
recovery situation. You are well advised to use identical hardware for both production and standby environments. If
you use identical hardware, and your standby database is a RAC database as well, then all instances can receive redo
from the primary database, thereby spreading the load.
The logical standby database
A logical standby database differs from a physical standby database in that it is not an exact 1:1 copy of the live
database. Every logical standby database starts its existence exactly like a physical standby database, but it is then
converted for permanent read-write access. At this stage, the primary database and logical standby can deviate.
Physical (and snapshot) standby databases stay synchronized through the application of redo information. However,
a logical standby database stays synchronized by having it execute all the same SQL statements as the primary
database. This mechanism is referred to as SQL Apply as opposed to Redo Apply .
Internally, SQL Apply uses the log miner functionality to extract SQL statements from the redo stream. It then
applies SQL statements rather than redo to the standby database. Therefore, a logical standby database has the same
data structure as the primary database, but the physical representation of the data in the database is likely to be
different. There are also some restrictions as to which data types are supported on the primary database, and this list
keeps growing from release to release.
 
Search WWH ::




Custom Search