Hello, The server can be started with a request for a "console log" with a max size. Once that size is met a new file is created for more recent entries and this would allow us to periodically delete older log files. Is there a similar method so that a max size can be set for the error log? If not, how do we ever clean it up so that it doesn't keep growing? Of course, one would hope that there wouldn't be too many entries placed in here, but "you never know!" If the error log is always "open for writes" then we probably can't just delete it. How can we know when we can delete an error log in an HA system that is "always running"? Thank you. |
Are you relating to the dbsrvX -oe <errorlog.txt> option?
FWIW, I don't know a method to rename that on a running database engine. (Although I would argue that its contents should not grow endlessly, and even in a HA system, you usually would restart the engine now and then - hopefully allowing the application to continue to work on the partner...)
For ordinary console logs, note that you can rename these (besides via -on/-os) with the help of the sa_server_option system procedure and its options "ConsoleLogFile" resp. "ConsoleLogMaxSize".
AFAIK dbsrv -oe is for startup errors only, when the server can't reach the point of opening the dbsrv -o file, so it is [cough] unlikely to grow very large.
FWIW -oe is very handy when dbspawn fails because (for example) there's a problem with licensing that prevents startup.
If you post your dbsrv command line, you may receive useful comments and suggestions.
If you are running dbsrv as a service, the dbsvc.exe utility is HIGHLY RECOMMENDED since you can refer to environment %variables% and have the values substituted before the service is created.
Yes, I'm using -oe. Thanks for the hint about sa_server_option!
Thanks Breck. I guess the solution is to just clean it up when the servers are being restarted.
Hi Breck. Thanks for the hint about dbsvc.exe but is that related somehow to the Error Log or is this just a good practice you wanted to tell me about?
I guess the idea is to use an environment variable to specify the name of the -oe error log. That way you could specify a different file name each time the service is started.
Thanks to Breck & Volker for the various hints. It sounds like we have to wait until a server reset to be able to delete this file. We can "close" this submission.