When running the "copy" command to sync or migrate the source table to target table you come across the following error:
sp_ctrl> copy <owner>.<tablename>
Cannot open object cache for active config
See the event_log for details
The object cache for Capture did not get created yet.
The copy command needs to refer to the Capture object cache file for gathering information about the structure of the object. An object cache file contains structural information of the tables in replication, something similar to what Oracle stores in its data dictionary. When a config file is activated, it will create object cache file for various processes like activation process (sp_tconf or sp_conf), Capture (sp_ocap), Read (sp_ordr), etc. In our case the probable cause is that the Capture object cache did not get created for some reasons. (Please see Additional Information section for details on identifying the Capture object cache for current activation).
A number of reasons can cause delay in creation of Capture object cache and the resolution is as follows:
1. When a config is activated, it does not create the Capture object cache instantaneously and barring any other abnormal conditions, one can hasten the creation process by bouncing Shareplex. This is documented in the Admin Guide. This is the easiest workaround to try first.
2. If there is any Capture error during activation, say log wrap, then this will hamper the creation of Catpure object cache. The underlying Capture error will need to be resolved before the Capture object cache is spawned.
3. Starting with Shareplex 6.0, there may be a need to tune the following parameters, in case Capture is running slow. The slow Capture can delay the creation of the Capture object cache file. The parameters can be tuned as:
sp_ctrl> set param SP_OCT_OPS_QUEUE_SIZE 50000
sp_ctrl> set param SP_OCT_OLOG_QUEUE_SIZE 10000
sp_ctrl>stop capture
sp_ctrl>start capture
This should result in the creation of Capture object cache. Please see solution #SOL38580 for further details.
4. If you do not see any errors about Capture in event log, and you are running Shareplex 6.0 or up, you can force a log switch to have Capture resume normal operation and consequently have the object cache file for Capture generated.
5. If Capture is behind Oracle, then it will delay the creation of Capture object cache. The conditions that can cause Capture to fall behind Oracle can be Capture error, a large batch job, log wrap, etc. The "show capture detail" can be issued from source sp_ctrl to determine if this is the case by comparing the value in the field named "Redo Log" (which is the log processed by Capture) to the value in the field "Oracle Log" (which happens to be the log that is being processed by Oracle). The fields mentioned are for Shareplex for RAC. For a non-RAC environment, the corresponding fields to monitor are "Capture current redo log" and "Oracle current redo log" respectively. When values in these two fields are equal, then one would see that the Capture object cache is finally created and the copy command should be able to function normally.
Additional Information:
Identifying Capture object cache for current activation:
You can issue "list config" to get details on the active configuration as follows:
sp_ctrl > list config
File Name State Datasource
-------------------------------------------------- ----------
test.config Active o.SID
Last Modified At: 12-Sep-08 01:19 Size: nnnn Internal Name: .conf.22
The above output tells us that the current activation ID is 22 as shown by the Internal Name. During activation the sp_conf object cache file gets created first and subsequently the sp_ocap or sp_ordr object cache are created and these files are located in $SP_SYS_VARDIR/state subdirectory. Normally this process does not take long and one should be able to see the Capture object cache for this activation ID by issuing "ls -l *22*", but in our case we do not see the Capture object cache and this is the reason copy command is failing:
$ ls -ltr *22*
-rw-rw-r-- 1 oracle oinstall 8 Sep 12 14:22 o.SID-scache_sp_conf.22
-rw-rw-r-- 1 oracle oinstall 1332 Sep 12 14:22 o.SID-objcache_sp_conf.22
-rw-rw-r-- 1 oracle oinstall 14 Sep 12 14:22 o.SID_lmt_objects.22
The above output shows that the activation object cache named o.SID-objcache_sp_conf.22 is created (where SID denotes the source Oracle SID) but not the Capture object cache. Once the Shareplex is bounced and barring no other error conditions, you should see the Capture object cache as seen below
$ ls -ltr *22*
-rw-rw-r-- 1 oracle oinstall 8 Sep 12 14:22 o.SID-scache_sp_conf.22
-rw-rw-r-- 1 oracle oinstall 1332 Sep 12 14:22 o.SID-objcache_sp_conf.22
-rw-rw-r-- 1 oracle oinstall 14 Sep 12 14:22 o.SID_lmt_objects.22
-rw-rw-r-- 1 oracle oinstall 1332 Sep 12 14:32 o.SID-objcache_sp_ocap.22
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center