Preparation for the configuration

Now it's time to get our hands dirty in the process of creating a logical standby database. First we'll start preparing the primary database for the configuration. Then we'll convert a physical standby database into a logical standby database. This is the method of creating logical standby Data Guard configuration.

There are some prerequisites that we need to complete before starting the configuration. One of them is checking the primary database for specifying any tables that will be skipped by SQL Apply because of the unsupported data types. It doesn't make sense to build a configuration where you're not sure which objects will and will not be replicated.

The other important control is ensuring the objects that will be replicated and maintained by SQL Apply are uniquely identified. As the logical standby is actually a standalone database, synchronizing it with SQL statements might result in ROWIDs being different on primary and standby databases. Thus, primary ROWID cannot be used to identify the corresponding row in the logical standby database. SQL Apply needs another unique identifier to apply changes, which are the primary keys, non-null unique-constraint/index, or all columns of bounded size, respectively depending on their existence.