I frequently see recommendations to regularly run sp_cycle_errorlog, so that the errorlog doesn't become huge. My main concern with that is that the errorlog contains valuable information.
When I do a health check on a SQL Server machine, I want a few months worth of errorloginformation available. I typically use my own scripts for this, available here. Almost every timeI go through the errorlog, I find valuable information. Some things you address, like find whatever it is that is attempting to login every minute. Other things you might not have control over, but the information is valuable to have.
So, if you run sp_cycle_errorlog every day or week, you end up with only a week worth, or a few weeks worth of errorlog file information.Suggestion 1: Increase the number oferrorlog files.
You probably want more than 6 history errorlog files. For instance, a client of mine told me that he was about to patch a server a few days before I was to visit that client. That patch procedure resulted in enough re-start of SQL Server so we ended up with only 4 days worth of errorlog files. Yes, this client had the default of 6 historic errorlog files. I typically increase this to 15. You can do this by right-clicking the "SQL Server Logs" folder under "Management" in SSMS. If you want to use T-SQL, you can use xp_instance_regwrite, as in:
,N'NumErrorLogs', REG_DWORD, 15;Suggestion 2: Set a limit for the size of the errorlog file.
But what about the size? Say that we have crash dumps, for instance. Or other things that start to happen very frequently. The good news is that as of SQL Server 2012, we can set a max size for the errorlog file. There is no GUI for this, so we have to manipulate the registry directly. Again, we can use xp_instance_regwrite. Below will limit the size to 30 MB:
,N'ErrorLogSizeInKb', REG_DWORD, 30720;
With 15 files, you canpatch of your SQL Server machine without aging out all old errorlog files. And with a max size of 30 MB, you keep each file manageable in size. And you keep the totalsize of errorlog files for that instance to450 MB. Not enough to fill your disks. But enough to have historical information for when you are about toperform a health check on your SQL Server instance.
References: thisby Jan Kåre and thisby Paul Randal.