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.
Note
You can use the physical standby database that we created together in Chapter 2, Configuring Oracle Data Guard Physical Standby Database for this purpose. However, we'll need a physical standby in the following chapters to study on. So, it would be better to create a separate physical standby database with one of the mentioned methods to use in the logical standby 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.