Start DB in read-only mode and how stop a database server in mirroring system

[Former Member]

Hello everyone, I need two clarifications. Premise that I work in a mirroring system

1) When, on the mirror server, launch dbsrv12 and use the -r option to start the database in read only mode I get the following output:

04/19 09:44:23. Database cannot be started -- /data/sa12/Ergon.db cannot be started read-only because it requires recovery 04/19 09:44:23. Database cannot be started -- /data/sa12/ErgonParts.db cannot be started read-only because it requires recovery 04/19 09:44:23. Database cannot be started -- /data/sa12/ErgonRes.db cannot be started read-only because it requires recovery 04/19 09:44:23. Database cannot be started -- /data/sa12/Europarts.db cannot be started read-only because it requires recovery

Can anyone tell me why?

2) To stop a server in the system mirror, I tried using the command:

dbstop -c "UID = DBA, PWD = *; dbn = utility_db; LINKS = tcpip" ErgonPrimary

Unable to stop database server - The DBN / DBF parameters do not match for this alternate server name.

How should I stop the service?

[MCMartin]

1) Have you taken your DB from a backup? If so you will first need to bring it into a correctly shutdowned state.

[Former Member]

Yes. I have run this dbbackup -c "eng=Sa1; dbn=$1; uid=ergon; pwd=sptnkx; " /data/backup/

Then I have copied the resulting database on the second server and I start it with -r parameter but it don't start and tell me:

"cannot be started read-only because it requires recovery".

I want to know how cai I do a recovery? There are an utility?

[jeff_albion]

Which version of SQL Anywhere are you using?

When you take a backup and start the database for the first time, it is (almost always) required that the database undergoes automatic recovery. This is achieved by starting the database on a regular database server/engine: "dbsrv12 database.db" or "dbeng12 database.db"

Database recovery is (almost always) required for backups because at the start of a backup, we first issue a checkpoint and then suspend any further checkpoints from happening in the database server while we start the database copy step. However, note that we do not suspend database transactions from occurring while we copy out the database file - instead, the database transactions are logged to the transaction log (which is copied in the second backup step) to be applied to the database when the backup database first starts up. After the backup, the normal checkpoint operations are then re-enabled. When you start your backup database, we need to apply the transactions in the transaction log that have not yet been applied to the database. You cannot recover a database in "read-only" mode.

For the list of the internal server behaviour during a back up, see this article in the documentation: http://dcx.sybase.com/index.html#1201/en/dbadmin/recovery-internals-backup.html

If you're looking for more information about how we perform checkpoints internally in the database server, see this question.

---

If you're setting up mirroring for the first time, have you first followed the tutorial in the documentation to see if this procedure generally works for you?

See: http://dcx.sybase.com/index.html#1201/en/dbadmin/da-highavailability-s-4980336.html

[Former Member]

I'm using SA12.

I start my DB server with dbsrv12.

When I finish backup operation, I start database server without -r option, but after that I stop database server and re-start it with -r option, however I have error.

Is this normal?

I read the tutorial and I understand it but I use mirror system differently, that is without arbiter server.

[jeff_albion]

When I finish backup operation, I start database server without -r option

Do you mean you start the backup database without "-r", or...?

but I use mirror system differently, that is without arbiter server.

Are you using any of the built-in high availability product features or have you tried to devise your own architecture...? If you're not using the built-in product features for mirroring, you're going to have to provide us more information about what commands you're explicitly trying so that we can make suggestions on your situation.

Please provide us the exact step-by-step of what you're trying in your solution.

e.g.

1. Start database server with: "dbsrv12 -n test test.db"
2. Log in to database and execute "BACKUP DATABASE ..."

etc.

---

If this is an urgent issue for you or the request to post to the forum the reproducible steps isn't possible, it may be helpful for you to open a technical support case so that we can work on your problem with you one-on-one. (See: http://www.sybase.com/contactus/support/ ).

[VolkerBarth]

Based on your other question: Don't get me wrong, but it seems you are going to take much afford to build a HA system on your own instead of using the builtin HA feature, and seem to be running into problems.

Would you be so free to tell why you cannot (or do not want to) use the builtin feature? As Mark has pointed out, a HA setup without a third system (the arbiter) won't probably work as expected...

[Former Member]

Hello everyone and thanks for the answers and advice,

Let me explain the situation to make you understand better. Start a DB in read only mode I just need to force the mirror server.

Using the builtin feature, I want create:

1. Without arbiter server: my servers may be geographically remote and do not know if the arbiter put to one side or the other;
2. If the original primary server is available, even after a failover, the primary server must remain the same.

Here below the steps you take to create the structure:

$HOMEDIR/bin64/dbspawn $HOMEDIR/bin64/$DAEMON $OPTIONS -xp on $DBFILES >/dev/null OPTIONS = "-c 500m -cl 500m -dt /dev/shm -gk ALL -gp 4096 -n Sa1 -o $LOG -oe $ERRORLOG -su xxx -ud -x $PROTOCOL"

This command start four DB.

For each DB, by Interactive SQL run:

CREATE MIRROR SERVER sa1 AS PARTNER connection_string='SERVER=sa1;host=192.168.13.1:2638' state_file='/data/logs/server1.state' preferred='YES'; -- I specify this parameter so that, when the primary recovering from failover, automatically resumes the state of primary

CREATE MIRROR SERVER <dbname>Primary AS PRIMARY connection_string='SERVER=<dbname>Primary;HOST=192.168.13.1:2638,192.168.13.2:2638';

CREATE MIRROR SERVER sa2 AS PARTNER connection_string='SERVER=sa2;host=192.168.13.2:2638' state_file='/data/logs/server2.state';

CREATE MIRROR SERVER <dbname>Mirror AS MIRROR connection_string='SERVER=<dbname>Mirror;HOST=192.168.13.1:2638,192.168.13.2:2638';

SET MIRROR OPTION authentication_string='sptnkx';

Where <dbname> can be: Ergon, ErgonRes, ErgonParts, Europarts.

Then I backup DB:

dbbackup -c "eng=Sa1; dbn=$1; uid=ergon; pwd=sptnkx; " /data/backup/

$1= DBname, one at a time;

I copy DB on second server and run

$HOMEDIR/bin64/dbspawn $HOMEDIR/bin64/$DAEMON $OPTIONS -xp on $DBFILES >/dev/null OPTIONS = "-c 500m -cl 500m -dt /dev/shm -gk ALL -gp 4096 -n Sa2 -o $LOG -oe $ERRORLOG -su xxx -ud -x $PROTOCOL"

At this point, the mirror works, everything that I run on the primary DB DB is copied to the mirror. My problem comes when I create a failover, and I have to do a restore. In returning to the initial situation I always have some problem and frankly I do not copy every time the DB from one server to other as this may be geographically distant.