|
We are in the process of preparing an upgrade for our customers from ASA9 to SA12. The typical setup is a Consolidated Database and one or several Remote Databases. From reading the documentation I see that we need an extra bit of log-file tweaking, in a test setup I've rebuild the consolidated using these steps. The databases are rebuilt successfully, but in order to send messages from the database again I have to tweak the log offsets as SQL Remote now tries to find a log offset that exists only in the old transaction log. Proceeding to this part of the documentation some questions came to my mind:
|
|
You should only need to use the dblog command if you manually rebuild the database. Why haven't you used the dbunload -ar to rebuild the database in place? This is much easier IMHO, as it eliminates the need to get rid of the transaction log created during the rebuild, and executes the equivalent of the dblog command against the newly created database for you. The -ml parameter is only needed if you want dbremote to delete old mirror transaction logs in addition to old logs when it deletes transaction logs that are no longer needed. If you look at the usage for dbremote, the last parameter specified is the location of offline transaction logs. If you do not specify a value, then SQL Remote will look in the same directory where the active transaction log resides for offline logs. You should specify a location for offline transaction logs all the time when running SQL Remote, regardless of whether or not an upgrade as recently been performed. I suspect that up until now, your offline logs have always been located in the same directory where the active transaction log resides, and you haven't had to worry about it. Thanks, seems to work like a charm. Just to be sure, this is the correct syntax ? dbunload -ar -c "DBF=database-file.db;uid=dba;pwd=sql" I also noticed a new .olg file. I presume this is the old transaction log which may be deleted when all subscribers offsets have passed into the new transaction log?
(12 Dec '11, 03:11)
OskarEmil
Your command line looks fine to me. You are correct about the .olg file. I would never suggest manually deleting old logs file though. Have a look at the delete_old_logs database option for a solution that involves having SQL Remote delete the old transaction logs for you automatically when it determines that they are no longer needed.
(12 Dec '11, 16:41)
Reg Domaratzki
|
|
I'll try to answer your questions:
AFAIK, you should erase the log after the database has shutdown cleanly. Then on netxt start, the database will simply start a new transaction log. Option -f should not be necessary at all.
No, it simply will change the log starting offset information in the database file. (And as you have erased the current log in the step before, there is no current one. But it will be created automatically on next start - see above. |
|
As to the offline log directory:
No, -ml is for offline transaction mirror log files. You will only need this if you are using a transaction mirror log at all. You simply add the offline directory (i.e. the directory containing old logs - made be backups and the last v9 database log) as last parameter on DBREMOTE's command line.
This should depent on the question whether you usually have offline logs - as long as SQL Remote might need any one of them (i.e. as long as not all remotes - or the consolidated - have committed all operations from these old logfiles) it will require to access them. So I would recommend to add that directory (which might be the directory also containing the current database and log file) anyway. |