When you activate a config using "live" option, it errors out as follows indicating that this option is not meant for tables with LOB columns:
11/21/03 11:04 Process launched: sp_tconf (for o.efxbdss) [pid = 139292]
11/21/03 11:04 Notice: Oracle env -efxbdss:/oracle/app/oracle/product/8.1.7 [sp_tconf(pdb)/139292]
11/21/03 11:04 Compiling a configuration file: datasrc - o.efxbdss; file -sp2202_efxbdss.config_201
11/21/03 11:04 Notice: Oracle version 81 [sp_tconf(osp)/139292]
11/21/03 11:04 Notice: New activation id 4 [sp_tconf/139292]
11/21/03 11:04 Error: 13001 - Live Activation on tables with LOB not allowed. (EZIOWNER.LETTER_TEXT) [sp_tconf(osp)/139292]
11/21/03 11:04 Config compilation completed: datasrc - o.efxbdss; file -sp2202_efxbdss.config_201
11/21/03 11:04 Bad config file: file - sp2202_efxbdss.config_201; Live activation is not allowed for tables with LOBS
11/21/03 11:04 Process exited sp_tconf (for o.efxbdss) [pid = 139292] -exit(1)
The "live" option for activation does not support LOB tables.
The "live" option of activation is meant to be used with activation when downtime on source database is not feasible. However, it has the limitation that it does not support tables with LOB columns. So you may want to create a config file with non-LOB tables and activate it with "live" option. Then use the following steps to deal with LOB tables depending on whether you can afford to have downtime on the source LOB tables:
If downtime on source database is not at all possible you can try the following workaround:
1. Activate all non LOB tables with the "live" option.
2. Make a copy of the currently active config file, add some or all of the LOB tables to the copy and activate the copy using default (non-live) activation. Since users keep accessing source tables and default activation requires exclusive locks on the source tables that are to be activated, it may or may not succeed. If it fails, the previously active config still prevails and you can keep retrying until it succeeds. Progressively activating LOB tables this way may be helpful as acquiring locks can be an issue. By progressive activation, I mean adding few LOB tables to copy of the previously active config file, activate the copy, then make another copy of the freshly activated config file, add more LOB tables to it and repeat the process of activation until all LOB tables have been covered.
3. Once all LOB tables have been activated, you may want to run compare with repair option on them since they may potentially be out of sync as users kept changing the source LOB tables while some or all of them were yet to be activated. The thing to note is that starting with Shareplex 5.3, compare works on LOB tables as well.
If downtime on source database is possible, or if the procedure listed in A above failed persistently due to locking issues, you can try the following:
1. Get downtime on source database or LOB tables. Then make a copy of the currently active config file, add all of the LOB tables to the copy and activate the copy using default (non-live) activation.
2. Once the activation completes, run compare with repair option on LOB tables since they may potentially be out of sync as users kept changing the source LOB tables while they were yet to be activated.
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center