Micros.log file too big! It freeze my POS system

[AnhDinh3107]

Hi,

I'm running on Micros Res 3700 system, the problem I have is the micros.log file in database folder is too big >4Gb - it freezes my Micros panel. I tried everything including deleting log file,setting log file info...things running good for only 1-2 days. My database is about 500Mb - 550Mb. Is there any way I could resize the log file manually or create any autosequence for that to delete the log automatically?

Any suggestion could help! Thanks in advance

 

[hosehead78]

Check your verbosity settings for the logging (In the Configurator). Change them then reload/restart.

 

[Moregelen]

Pretty sure that Verbosity is controlled in Control Panel. In Control Panel, at the top, click View, then click Show Verbosity. You can change the verbosity for a lot of stuff, for each individual workstation and the server itself. The higher you set it, the more useless (typically) information it dumps into the log file, meaning it fills up fast.

 

[hosehead78]

@Moregelen, you are correct. It is not in the Configurator, I was off when I replied to this so I am gonna blame it on that. Thanks.

 

[AnhDinh3107]

I checked all the verbosity set = 0. Anw, here the new story:
- Now, my SQL service won't start. The event viewer shows
"The description for Event ID ( 1 ) in Source ( ASA 9.0 ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: SQLANYs_sqlMESA-4DE9D128D9, Cannot open transaction log file -- Can't use log file "MICROS.log" since it is shorter than expected."

Is there any way I could generate a new micros.log file in order to start the sql service since my system won't allow me to open DM, POS config or anything else relating Micros? Plz its really urgent so any suggestion would be really helpful.

Thanks

 

[hosehead78]

Not sure if using command functions work in 3700 environment. Open CMD prompt and to into the Micros folder (installation and where the files are located). Once there, type: Micros ? [press enter]. If it gives you a list of commands then you are good to go. However, I am not 100% these will work.

 

[pmegan]

Having a large log file like that will slow you down, but shouldn't keep the SQL service from starting. Is there any free space on the drive? If the hard drive is full you won't be able to start the database.

Do you know when your last database backup was performed? When a backup runs it writes all the uncommited transactions in the log to the database and then the log is purged and truncated, keeping the size in check. It sounds like your database may not be backing up, which has the potential to make this ugly. If you have a recent backup and the log is still huge it's probably corrupted.

 

[AnhDinh3107]

@ hosehead78: I'll try ur way. Hopefully it'll work.
@ pmegan: you are right.the IT guy before me ran backup only once, it was from last year. Right now I just need to start the sql service in order to get information such as daily report up to day.

 

[AnhDinh3107]

Things turn out ugly. Is there any way I could generate a new Micros.log file manually? the sql service does not start, so I could not do anything.

 

[AnhDinh3107]

well, i ran through some previous post and found out one post regarding DM issue of pmegan. Anw, I restored a new db. Things seem fine now

btw, how could i access history data from file micros.db? I don't have a backup file so micros.db is the only thing I have in order to get history data

 

[pmegan]

You may not be able to recover the historicals. A database log is actually part of the database, not just an informational file like the logs you see for applications. Database transactions are held in the log until they're commited to the DB itself. Backing up the database commits everything and then makes a copy. That huge log is what made me think you weren't backing up.

My advice is to schedule a full backup to run daily, either through an Autosequence or a windows scheduled task. I'm pretty sure "DM -b -v" is the command line to run and validate a backup, but you can verify that by openin a command prompt and running DM /?

If you have a test server I'd try to restore the old db there. You'll have to restore the old backup that you have, then copy in the .db and .log files. If that doesn't work you can try moving the .log file out of \data folder and using DM -F to force it up and generate a new log. This may cause data loss, and if there's an issue with the encryption keys it may render the whole system unusable, so I never do this on a live server. [pre][/pre]

 

[AnhDinh3107]

First, thanks for your support pmegan. I've read all your posts regarding Micros issues and got such massive info about Micros system which I could not find anywhere else except Tek-tips.

2nd of all, I thought the same thing as your suggestion. Hopefully it'll work since this data is quite important for us. We did run daily report and menu mix everyday but having a raw data would be better.