What are the implications of renaming the services file during troubleshooting? (89430)

The services file (located in /vardir/data subdirectory) keeps track of which processes need to remain stopped when sp_cop is launched and if the file is removed, then a new one will be created upon restart of sp_cop and the default behavior of all child processes will be that they will launch once sp_cop comes up. This can have serious implications if a process was intended to be kept in a stopped state but by renaming the services file, the process is started upon restart of Shareplex. For example, typically in a high availability replication the Export process is kept in a stopped state on secondary and if renaming the services file and then starting sp_cop on secondary, the Export process will be started once sp_cop comes up. If there are any messages in Export queue, they will be inadvertently sent to the primary.

Renaming the services file can cause Shareplex to lose track of which processes need to be kept stopped upon restart of sp_cop.

The way to prevent such behavior is to start sp_cop with –s option and then start the child processes individually so that no child process is inadvertently started, or put another way, upon restart of Shareplex, manually control which child process is started.

To start sp_cop with –s option:

$ /productdir/bin/sp_cop -s &

Or...

$ cd /productdir/bin

$ ./sp_cop -s &

Then start the child processes individually.

Please refer to Shareplex Administrator Guide Chapter titled "Alternative Operation of SharePlex" section titled "Starting SharePlex without starting replication processes".