Creating Logical Standby Databases
Logical standby databases follow many of the same steps used to create physical standby
databases. Because they rely on the re-execution of SQL commands, logical standby databases
have greater restrictions on their use. If any of your tables in the primary database use the
following datatypes, they will be skipped during the redo application process:
BFILE
ROWID
UROWID
User-defined datatype
Object types
REFs
Varying arrays
Nested tables
XMLtype
Additionally, tables that use table compression and the schemas that are installed with the
Oracle software are skipped during redo application. The DBA_LOGSTDBY_UNSUPPORTED
view lists the objects that are not supported for logical standby databases. The DBA_LOGSTDBY_
SKIP view lists the schemas that will be skipped.
A logical standby database is not identical to the primary database. Each transaction that is
executed in the logical standby database must be the logical equivalent of the transaction that
was executed in the primary database. Therefore, you should make sure your tables have the
proper constraints on them??”primary keys, unique constraints, check constraints, and foreign
keys??”so the proper rows can be targeted for update in the logical standby database. You can
query DBA_LOGSTDBY_NOT_UNIQUE to list tables that lack primary key or unique constraints
in the primary database.
To create a logical standby database, follow the steps outlined in the remainder of this section.
Pages:
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735