|
In a multi tyer Installation (level 1 at top, level 2, level 3 on the bottom), we download data from level 1 to level 2 and later down to level 3, and we upload other data from level 3 to level 2. On level 1 runs mobilink server, on level 2 mobilink server & client, on level 3 mobilink client. On level 3 are several databases, so the database on level 2 receives big amount of data, and consequently it has enorm transaction log file, as a result takes the dbmlsync on level 2 too long time, despite we theoritically dont need to scan this big transaction log file (as mentioned before the database on level 1 acts only as download). Is there a solution for such a scenario? I mean to enforce dbmlsync not to scan the transaction log files, or to download into tables which not exist in sysarticles. |
|
Is the sync between 1st and 2nd tier using a download-only publication, or do you run it as a download-only sync, or currently none of those? I'm relating to these different concepts. And does the sync between 1st and 2nd tier also affect data that is synced between 2nd and 3rd tier (and possibly modified at 3rd tier), or are these disjunct data? I'm asking as a download-only sync might run into issues (or fail) when it affect rows that have been modified at the lower tier itself... Currently none of those, is it generally possible to define a download-only publication? With download-only I ment that there are no upload mobilink scripts defined on level 1.
(27 Jul '22, 07:47)
Baron
Replies hidden
1
It is, see the link in my first response.
(27 Jul '22, 09:17)
Volker Barth
Thank you very much, Download-only publications is my survivor! Can you convert your comment to an answer?
(27 Jul '22, 10:16)
Baron
|
You will want to look at the delete_old_logs and the log management MirrorLogDirectory (may not be required), dbmlsync -x, and/or dbbackup transaction log rename option (DO NOT TRUNCATION transaction logs in a sync environment). The delete_old_logs will delete tlogs involved in synchronization that are no longer needed.
The delete_old_logs Option is active, and dbmlsync starts with -x, and it is working (rename and truncate), only the problem was that there are too many transactions on the database.
Here another question:
During uploading data from databases from level 3 into database level 2, there was continously Primary Key violation (error 23000/-193). Could this be a reason that causes the Tlog on level 2 to grow enormly?
According to my understanding, only transactions would be written in TLog and not errors and other logs (in the case of PK violation for example). Am I correct?
COMMIT and ROLLBACK transactions are logged to the transaction log.
Make sure that all tables in the schema have primary keys. Tables without primary keys will result in larger transaction log entries for UPDATE and DELETE operations. For example, a delete without a PK
but with a primary key would be
Tables with large number of columns and/or blob types can substantially grow the log.
You could translate the log to analyze what is being written to the log and ensure that it is reasonable for your workload.
Failing DML statements are necessarily parts of transactions, so they are logged in the transaction log. too, but will usually lead to a rollback of the transaction they belong to. Dbtran -a will include transactions that were rolled back.