• Effective System Resource Use. A logical standby database can function as an independent production database that still accepts updated data and transactions from the primary database. However, unlike a physical standby database, a logical standby’s physical structure may be different (e.g. different tablespaces or datafiles). In addition, change data may beselectively applied to particular tables and indexes. It’s therefore possible for a logical standby database to offer data from a combination of sources: tables that are perfectly synchronized with the primary database, plus tables whose changed data has been excluded from application to the logical standby database, and even tables which exist only in the logical standby database.
• Primary Database Workload Reduction. Since a logical standby database will capture change data for all supported datatypes – more on this later! – this also means that it’s possible to build materialized views, materialized view logs, and even additional indexes on existing production tables that would be prohibitively expensive to maintain against the same tables on the primary database. Logical standby databases are therefore excellent targets for data warehouse, data mart, or decision support applications that only need to read production data, but that could also utilize additional constructs (e.g. bitmap indexes) for speedier query processing. Logical standby databases are also excellent alternatives to databases created using basic replication because they’re much easier to maintain.
• Increased Data Protection. Because a logical standby database’s datafiles aren’t an exact physical copy of the primary database’s datafiles, it offers protection against physical block corruption on the primary database because redo is applied using SQL Apply methods. And just as with a physical standby database, it’s also possible to delay DML that’s been generated on the primary database from being applied against the logical standby database by implementing delay features.
• Patching. Because it can assume the role of the primary database during a switchover operation, a logical standby database can facilitate extremely quick Oracle Database patching and upgrade operations. The patches are first applied to the original logical standby database, which then assumes the primary database role after switchover is complete. Once the original primary database is converted to a logical standby database, it can be upgraded as well.

Unsupported Objects. A logical standby database cannot accept updates for the following objects:

Unsupported Data Types. In addition, any tables that are comprised of or whose columns contain the following unsupported data types cannot be updated in a logical standby:

BFILE
ROWID, UROWID
User-defined types
Collections (including VARRAYS and nested tables)
XML type
Encrypted columns
Multimedia data types (including Spatial, Image, and Context)

To find which tables cannot be duplicated on the logical database run the following select on Primary:

SELECT DISTINCT OWNER,TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED 
ORDER BY OWNER,TABLE_NAME;

As an example, to view the column names and data types which are not supported for one of the tables listed in the previous query, run the following select:

col DATA_TYPE format a20

col COLUMN_NAME format a20

SELECT COLUMN_NAME,DATA_TYPE

FROM DBA_LOGSTDBY_UNSUPPORTED
WHERE OWNER='OE' AND TABLE_NAME = 'CUSTOMERS';

2- Ensure Table Rows in the Primary Database Can Be Uniquely Identified
The physical organization in a logical standby database is different from that of the primary database, even though the logical standby database is created from a backup copy of the primary database. Thus, ROWIDs contained in the redo records generated by the primary database cannot be used to identify the corresponding row in the logical standby database.

Oracle uses primary-key or unique-key supplemental logging to logically identify a modified row in the logical standby database. When database-wide primary-key and unique-key supplemental logging is enabled, each UPDATE statement also writes the column values necessary in the redo log to uniquely identify the modified row in the logical standby database.

- If a table has a primary key defined, then the primary key is logged as part of the UPDATE statement to identify the modified row.

- In the absence of a primary key, the shortest non-null unique key is logged as part of the UPDATE statement to identify the modified row.

- In the absence of both a primary key and a non-null unique key, all columns of bounded size are logged as part of the UPDATE statement to identify the modified row. In other words, all columns except those with the following types are logged: LONG, LOB, LONG ROW, object type, and collections.

Oracle recommends that you add a primary key or a non-null unique index to tables in the primary database, whenever possible, to ensure that SQL Apply can efficiently apply redo data updates to the logical standby database.

Find tables without unique logical identifier in the primary database:

SELECT  OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE
WHERE (OWNER, TABLE_NAME) NOT IN (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) 
AND BAD_COLUMN = 'Y';

If your application ensures the rows in a table are unique, you can create a disabled primary key RELY constraint on the table.
This avoids the overhead of maintaining a primary key on the primary database.
SQL> ALTER TABLE  TableA  ADD PRIMARY KEY (id, name)  RELY DISABLE;

When you specify the RELY constraint, the system will assume that rows are unique. Because you are telling the system to rely on the information, but are not validating it on every modification done to the table, you must be careful to select columns for the disabled RELY constraint that will uniquely identify each row in the table. If such uniqueness is not present, then SQL Apply will not correctly maintain the table.

To improve the performance of SQL Apply, add an index to the columns that uniquely identify the row on the logical standby database. Failure to do so results in full table scans during UPDATE or DELETE statements carried out on the table by SQL Apply.