|
We've noticed that when a remote synchronizes with our consolidated, a new log is not cut every time despite having -x 0M. We synchronize every 30 minutes. The log cutting is irregular and the remote can go for hours without cutting and then starting cutting. We tried pinpointing processes running at the same time that might be holding the live log file but couldn't find anything. Wondering if any else has had this experience or if anyone can suggest something to look at? Thank you. |
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 24 Aug '18, 13:18
question was seen: 751 times
last updated: 08 Apr '19, 11:29
AFAIK log files always have a non-zero file size even when there's no real data in them... I have no idea what "-x 0M" really means, since there is no point renaming an empty log.
Are you starting dbmlsync.exe every 30 minutes, or having dbmlsync run continuously with a schedule via dbmlsync -e "sch=whatever"?
Is it possible there is nothing being written to the log file during the periods of non-renaming-deleting?
> processes running at the same time that might be holding the live log file
It is unlikely that any such process can possibly exist. I just checked with notepad and it is locked out... don't laugh! Notepad can open files most other programs cannot.
SQL Anywhere live backup via dbbackup opens a client server connection to the SQL Anywhere server, rather than (AFAIK) directly reading the log file. I presume HA mirroring uses a similar path.
We're running dbmlsync from a powershell script via a scheduled task that runs every 30 minutes. We've noticed that during working hours when clients are connecting to the remote is when the log cutting is most erratic and usually we won't see a log cut during those hours.
I believe we use "0M" only because it's recommended to have something after -x and would otherwise just have -x, with the log cutting to whatever size the live log was, which is what happens with 0M.
As for something holding the log file, that was just about the only thing we could think of.
What does the following query return?
SELECT * FROM SYS.SYSOPTIONS WHERE "option" = 'delete_old_logs';
delete_old_logs = OFF
Consider changing that, so the old renamed logs get automatically deleted after dbmlsync no longer needs them. In spite of the Help saying otherwise, this is NOT just a SQL Remote option, it applies to MobiLink as well, and it is how many folks manage old logs. Personally, I like DELAY.
What version and build are you using?
version 17.0.9.4793
Try reporting this symptom to tech support.
...or perhaps, if it's not causing any errors, ignore it.
So, after long, long deliberation. We decided to have an event that runs "backup database transaction log only". This event runs on a schedule and cuts the log file predictably. Eventually, we will stop using dbmlsync -x at all of our remotes. Thank you Breck for your help.