Hi, I currently have a database of a completed application. This database has been made over a course of a year and now it's time to put this database in production. This database will be used as a consolidated database. The problem I have now is the fact that I don't want to use the transaction log that is made during development because a lot of insert and deletes of fake data happend during development. I want to start with a clean slate, I don't want all transactions that were made during development to be replicated to the remotes. I just want my consolidated database to start from zero, replicate the data that is present and only changes after this moment should be replicated. I have searched the web, but I didn't find anything that could do that. I have used dblog -x 0 -z 0 <database> which gave the following output: SQL Anywhere Transaction Log Utility Version 11.0.1.2960
but when I tried to start my database it gave the following error:
I kinda underestimated this. I thought it would be simple to reset the transaction log to just say "replicate current data and from this point forward publish only the changes". Is there someone that can help me with my problem asked 10 Oct '16, 07:24 puppetspace |
Caveat Emptor (this is from memory): If all your remotes are in a state of grace (they have all the data they need, and the consolidated has all the data it needs), consider running STOP SUBSCRIPTION on the consolidated for all the remotes, then stop the consolidated, delete the transaction log, start to consolidated to create a new empty log, then run START SUBSCRIPTION or REMOTE RESET for everything.
Just to understand: When have you set up your remotes - during development or just recently?
The "test" transactions will only be a load for the remotes when those have been created (i.e. the subscriptions have been started) before the "fake" transactions were run - then the transactions need to be applied at the remotes.
When going into a production environment, I would usually re-create the remotes that were used during tests, and so could start with a fresh log before the remotes are re-extracted...
As this sounds like "new development": Is there a particular reason you could not use a current version like v16/v17 (even v12 will be EOL'ed at the end of the year)?
Since it appears you are using SQL Remote replication, you never truncate the log yourself but let incremental log backups and the DELETE_OLD _LOGS option manage this for you automatically.