|
I have difficulty in applying transaction log files from a foreign database using -a option of dbeng17. I am doing the following:
My question is, is the reported error only related to mismatching offsets? or db17.db can really figure out, that the db1.log¹ is written by a froeign datatabase (i.e. by db10.db) (maybe through metadata or DbIdentifier...etc.). My second question is, do SQL-Anywhere 10 & SQL-Anywhere 17 use the same format in writing transaction log files? and is it generally possible to apply transaction log files created by SQL-Anywhere 10 in a database of SQL-Anywhere 17? |
|
Just to answer your question "[...] can really figure out, that the db1.log¹ is written by a froeign datatabase (i.e. by db10.db) (maybe through metadata or DbIdentifier...etc.)" See that older answer by Mark - to quote:
So I would assume that both databases have a different signature... OK, so it is impossible to apply translogfiles from DBa on DBb. The question is: Can/May I manipulate this signature (this property)? select db_property('IdentitySignature'); Some properties are usually manipulable (for example SET OPTION PUBLIC.global_database_id = '100'; this works fine)!
(14 Feb '20, 08:11)
Baron
Replies hidden
1
Well, I don't know if you can do so - but I would strongly advise against trying to: The "allowed" combination of database file(s) and transaction log(s) is required for recovery and the like and protects your data, why would you try to mess around with that?
(14 Feb '20, 09:21)
Volker Barth
No, I dont want to try what is not allowed! For me was more important to know that it is not only related to the offsets, but other factors too(signature...). When I try to adjust the offsets using translog files from the same DB (or even copies of the same DB) then everything was OK (so that I can make sure that I can do at least this part successfully) I got the answer and also accepted it. Thank you
(14 Feb '20, 09:52)
Baron
Well, note, that advice was just my opinion as another customer, certainly a SQL Anywhere guru like @John Smirnios can clarify whether it is allowed or not.
(14 Feb '20, 10:06)
Volker Barth
Finally it is my DB, and when I try an 'unallowed' process, then I am risking my own data!! With allowed I wanted to mean whether it is documented/guaranteed from SQL-Anywhere or not!
(14 Feb '20, 10:14)
Baron
|
I don't think the translog format is compatible between versions. I guess translating the v10 log to SQL and then applying that SQL script at the new database could help here.
Are you trying to reduce downtime during a v10 to v17 upgrade?
no, I am trying to simulate the real upgrade, and simulate the replication of 10 against 17.
BTW, I have repeated the same test but keeping both databases SQL-Anywhere-10, and got the same error message (db10.log belongs to a different database).
Despite db10.log & the new db10.db have the same starting offset!
This would mean for me that it is neither related to offset mismatching, nor related to version difference.
The new created database can recognize somehow that the translogfile is not written from himself (he figures out that this is from a database with same version, same name but not the same one).