Copy fails with "ORA-01034: ORACLE not available", "EXP-00056" and / or "ORA-27101: shared memory (4331041)

When running copy to sync the target table, the copy status command shows the following errors:

sp_ctrl >copy status

Job ID : 245
Host : host_name
Started : 07-JUL-09 17:38:19
Job Type : Copy
Status : Failed
ORA-01034: ORACLE not available
See sync_svr_245 log file for details

ID Tablename Total Rows %Comp Status Status Time Total Time
------ ------------------------------------ ---------- ----- ---------- ----------- ----------
1 OWNER.TABLENAME 46328065 Failed N/A 0:03

The following errors are observed in the sync server or sync client log (source and target copy log respectively):

Wed Jun 03/13:43:57.025:: ERROR: ORA-1034: ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist

Or

Wed Jul 01/13:39:01.797:: 003: Error/Warning Detected: EXP-00056: ORACLE error 1034 encountered
Wed Jul 01/13:39:01.798:: 003: Error/Warning Detected: ORA-01034: ORACLE not available
Wed Jul 01/13:39:01.798:: 003: Error/Warning Detected: ORA-27101: shared memory realm does not exist
Wed Jul 01/13:39:01.798:: 003: Error/Warning Detected: EXP-00005: all allowable logon attempts failed
Wed Jul 01/13:39:01.798:: 003: ERROR: Stopping export thread - ORA-01034: ORACLE not available at sync/svr/sync_export_thread.cpp:630

Either the Oracle is not running on source/target or there are discrepancies in the case specification (lowercase or uppercase) of the Oracle SID in config file or in oratab file.

First check to see if Oracle is running on source / target where the copy log is showing error, and if not, then start the database prior to running copy once again.

If the database on source and target are running, then check to see if the oratab on the affected machine has wrong case specification in it and if so, correct it before running the copy. For example, if the SID name is in uppercase and if the oratab has it in lowercase or has both uppercase and lowercase entries in it, then remove the SID entry with incorrect case. Then run the copy.

If none of the above applies, then check to see if the config file has improper case in it for target SID. Though Shareplex replication does not get impacted if the case is improper, the copy command currently does. If the case is not proper, then make a copy of the currently active config file, amend the case as appropriate and activate the copy. This activation only involves routing change and will lock the affected table very briefly. If the activation fails because Shareplex is not able to lock the table, then the original config file will still be active. Once the new activation succeeds, then run the copy again.