Change Log File Settings from DBISQL

[Baron]

Is it possible to activate/deactivate the mirror logs of an SQL Anywhere Database from within DBISQL?

It doesn't matter if the change will take effect after next starting of the Database, the question is whether there is an Statement alternative for the DBLOG.EXE

I know that reading the settings is possible in dbisql via select db_property ('LogMirrorName') so will be great if writing is also possible.

[VolkerBarth · Accepted solution]

See the ALTER DATABASE ... ALTER LOG clause.

[Baron · Accepted solution]

Thank you very much!!

Noticable was also the UPGRADE SCRIPT FILE CLAUSE, What would exactly be done here? Just execute the specified sql script file? What would this then differ from the usual READ statement?

[chris_keating · Accepted solution]

The ALTER DATABASE ... UPGRADE SCRIPT ensures that in the event of a problem running the script that the database is put back to before the ALTER DATABASE even if the script contains statements that has commit side effects i.e. most DDL statements. With a READ, all statements committed (even as a side effect) would remain if the script encountered an error. If the script must complete successfully and not leave the database in a partial completed upgrade, using UPGRADE SCRIPT is a better mechanism than READ.

[Baron · Accepted solution]

This is great to know, this could be helpful.

The question is, is it necessary that the script is a one single file? Or this file could be a script with several READs which in turn reads another scripts?

[Baron · Accepted solution]

Does this

...the database is put back to before the ALTER DATABASE...

also apply if the script contains an explicit commit statement?

[VolkerBarth · Accepted solution]

@Chris: BTW, is this a v17 enhancement? I have never read that before, and it's documented for v17, but not v16 but I don't see an "What's New" entry there... - whereas the v17 enhancement to ALTER DATABASE SAVE CACHE do get mentioned...

[VolkerBarth · Accepted solution]

Yes, according both to Chris's statement and the mentioned doc page:

If the script execution is not successful, and RESTART ON is specified (the default), the database is rolled back to the checkpoint that was automatically performed before the upgrade...

I assume it does use the new v17 point-in-time-recovery feature to do so, but that's just a guess...

[chris_keating · Accepted solution]

It is listed under Changes to database administration in the "What's New" topic. See https://help.sap.com/viewer/a3e900ad39b94d689987e838835f39fe/17.0/en-US/7807d1fe7a8847e4bab7591613c0...

[VolkerBarth · Accepted solution]

Ah, I got it. FWIW, that link does not work for me but DCX does...