SQLServerCentral / Article Discussions / Article Discussions by Author / Discuss content posted by Ken Simmons / SQL Server Preproduction Tasks / Latest Posts

RE: SQL Server Preproduction Tasks

Wayne West — Fri, 02 Jan 2009 10:23:21 GMT

Forgot something that I do on 2005. I have all my 2005 instances set to use checksums for torn page detection, so I run the following code in addition to my DBCC step:[code]select * from msdb..suspect_pagesgo[/code]The output goes into a text file, suspectpagesresult.txt. If I get any rows in my result, I know I have a problem (haven't gotten any yet).I also filter my DBCC runs [code]d:cd\dbccstype dbccresult.txt | find "errors" >server1_dbcc.txttype suspectpagesresult.txt >>server1_dbcc.txt[/code]So my result file looks someting like this:[code]....DBCC Results:CHECKDB found 0 allocation errors and 0 consistency errors in databaseCHECKDB found 0 allocation errors and 0 consistency errors in databaseCHECKDB found 0 allocation errors and 0 consistency errors in databaseCHECKDB found 0 allocation errors and 0 consistency errors in databaseCHECKDB found 0 allocation errors and 0 consistency errors in databaseCHECKDB found 0 allocation errors and 0 consistency errors in databaseCHECKDB found 0 allocation errors and 0 consistency errors in databaseCHECKDB found 0 allocation errors and 0 consistency errors in databaseCHECKDB found 0 allocation errors and 0 consistency errors in databaseCHECKDB found 0 allocation errors and 0 consistency errors in database1> 2> 1> 2> 3> database_id file_id page_id event_type error_count last_update_date ----------- ----------- -------------------- ----------- ----------- ----------------------- (0 rows affected)1> [/code]Makes things a lot easier to see if there are problems rather than sifting through pages of DBCC results. If I see a non-zero result, I know there is a problem and I have the full log on my server to investigate further.

RE: SQL Server Preproduction Tasks

Wayne West — Fri, 02 Jan 2009 09:17:34 GMT

Excellent article, Ken. Your list should be part of every administrator's personal standard practices list, perhaps altered a bit for individual taste and installation specifics.I also do full audits, but then every night I parse my error logs through a Perl script that ignores successful logins and gives me a text file of just SQL events and failed logins. I can always go back to the server log and check it for successful logins: we're almost exclusively 2000, so we don't do login audit triggers at this time.I would add one thing for pre-2005 servers: create yourself an additional admin account in case something happens to your network login or you lose network connectivity and have to go local console. I like to use a strong password, sometimes completely random, for SA just to ensure it won't be used, so this serves as my back door when an admin connection can't be used.And I'd add backing up the master, model, and msdb databases regularly. Great help for restoring systems.

RE: SQL Server Preproduction Tasks

mishaluba — Sun, 14 Dec 2008 21:39:22 GMT

Wow, no offense to any other authors, but this is probably one of the most valuable articles I have ever seen on SQL Server Central. What a great compilation of immediately useful resources in one place. Thank you for all the work!

RE: SQL Server Preproduction Tasks

JStiney — Mon, 01 Dec 2008 13:08:00 GMT

Ken,Nice article. I will be adding some of the items you mentioned.Some of the things we do may be of interest.6. Determine Drive Structure and move system databases if necessary.We also resize all the system databases and set them to grow by a reasonable amount of MB and set a max after the growth factor is applied 2 to 4 times. I would stay away from 10MB as a growth number, as I have seen this still be interpreted as 10%.15. Make sure each maintenance job has an output file in a standard directory.We set up a jobs directory on each server with a cmd, reports, and sql subdirectory.All jobs are run from the cmd directory and the output of each job is piped to a member in the reports directory with the same name as the cmd member name.One of the jobs in the cmd directory is sqlcmd that accepts a database and a sql script as input.When you set up a new server you can copy this directory structure to the server and copy the server jobs with an SSIS package and you have most of the jobs you need on the new server.We also have a daily report for each server that contains the space available on each disk drive. The size and space available for each database file. The log space used and recovery mode of each database. An edited report containing backups, update statistics, and reindex along with errors found in the last two logs, backups, and dbcccs. We keep a copy of these reports for each server for 30 days.

RE: SQL Server Preproduction Tasks

Tom Garth — Thu, 27 Nov 2008 15:33:21 GMT

Ken,Great article / checklist!Thanks,

RE: SQL Server Preproduction Tasks

Vivien Xing — Thu, 27 Nov 2008 14:53:41 GMT

Nice article. I keep 99 (max) errorlogs. It depends on the size of each errorlog/entries in the errorlog. When the size is over 1 MB; it takes time to open it (in my case). This is one of the factors I consider how often to recycle the errorlog.I zip the old errorlogs by the end of the year and move it to a central depository. This can be automated, too.Keeping 25000 errorlog may be not realistic; it will take a lot of space on the current live system.

RE: SQL Server Preproduction Tasks

Mohit K. Gupta — Thu, 27 Nov 2008 07:36:27 GMT

[quote][b]Jack Corbett (11/27/2008)[/b][hr]The problem is that Builtin\Administrators are sysadmins if you don't remove them or change them. This can be an audit problem. Does the server operations group grant you domain admin or server admin on every server? You should manage them just like you manage other users and grant them specific permissions based on business needs.[/quote]:hehe::laugh::hehe::laugh:Yaa right I don't get access to all the servers or domain admin LOL. They did have a heart attack, yaa I said the same thing few times. Heh, and actually on new servers I am starting to implement that; so far no one has noticed :rolleyes:. Lets see how long it lasts ;-).

RE: SQL Server Preproduction Tasks

Jack Corbett — Thu, 27 Nov 2008 07:13:06 GMT

[quote][b]Mohit (11/27/2008)[/b][hr]I was considering removing Bulti-In Administrators but wasn't sure if that is a good idea or not. I thought I am just being over jelouse by not wanting to give server operations any permissions on the SQL Servers.[/quote]The problem is that Builtin\Administrators are sysadmins if you don't remove them or change them. This can be an audit problem. Does the server operations group grant you domain admin or server admin on every server? You should manage them just like you manage other users and grant them specific permissions based on business needs.

RE: SQL Server Preproduction Tasks

Mohit K. Gupta — Thu, 27 Nov 2008 06:57:31 GMT

[quote][b]MarkusB (11/27/2008)[/b][hr]I would add two more tasks to the checklist1. Remove Built-in admiinstrators2. Disable or at least rename the sa account (in 2005 or higher).About hte loging of succesful logins I would recommend to use a LOGIN TRIGGER which records the login and the last time it connected. This avoids filling up the SQL errorlog and it's much easier to search through in case you want to know when was the last time a login was used.[/quote]I was considering removing Bulti-In Administrators but wasn't sure if that is a good idea or not. I thought I am just being over jelouse by not wanting to give server operations any permissions on the SQL Servers.But as for SA account I don't think it needs to be renamed because you shouldn't be using the SA for day-to-day work anyways. I tend to leave the SA account name as is, but set a strong password with at least 15 characters, caps, lower-case, number, symbols, etc.Thanks.

RE: SQL Server Preproduction Tasks

MarkusB — Thu, 27 Nov 2008 03:37:45 GMT

I would add two more tasks to the checklist1. Remove Built-in admiinstrators2. Disable or at least rename the sa account (in 2005 or higher).About hte loging of succesful logins I would recommend to use a LOGIN TRIGGER which records the login and the last time it connected. This avoids filling up the SQL errorlog and it's much easier to search through in case you want to know when was the last time a login was used.

RE: SQL Server Preproduction Tasks

KenSimmons — Wed, 26 Nov 2008 12:22:41 GMT

[quote][b]Steven Webster (11/26/2008)[/b][hr]I'd certainly agree that a registry hack is not the way forward. Unfortunately though where I work an auditors word is always taken ahead of mine! Interesting point tho whether the registry would be overwritten if a service pack were to be applied - I'll test that out and get back.[/quote]Isn't an Auditor asking you to hack the registry kind of like an Oxymoron anyway? Should't they be making sure we are using the reccomended settings instead of ones that are not supported?

RE: SQL Server Preproduction Tasks

DPhillips-731960 — Wed, 26 Nov 2008 10:46:22 GMT

Very nice article! It runs where the tires meet the road with specifics that even the newest to the product can eventually digest. This is good list to keep and train with. It also in effect shows more of what a DBA does, on a level that even management can digest, and demonstrates that a database is not just a maintenance-free "bucket" some place to dump and retrieve data.

RE: SQL Server Preproduction Tasks

Steven Webster-494809 — Wed, 26 Nov 2008 09:35:29 GMT

Some very good pointers there guys, thanks a million. I'd imagine some kind of archiving process along with a server side trace would suffice, particularily if the trace was set up to capture more than the error logs would. Thanks again!

RE: SQL Server Preproduction Tasks

Jack Corbett — Wed, 26 Nov 2008 09:19:46 GMT

[quote][b]Steven Webster (11/26/2008)[/b][hr]I'd certainly agree that a registry hack is not the way forward. Unfortunately though where I work an auditors word is always taken ahead of mine! Interesting point tho whether the registry would be overwritten if a service pack were to be applied - I'll test that out and get back.[/quote]Maybe Ken's idea of archiving the error logs would work for you and the auditors. Also you could use the Default Trace or a server-side trace set to start at startup to do the auditing necessary and archive that data as well.

RE: SQL Server Preproduction Tasks

Steven Webster-494809 — Wed, 26 Nov 2008 09:15:55 GMT

I'd certainly agree that a registry hack is not the way forward. Unfortunately though where I work an auditors word is always taken ahead of mine! Interesting point tho whether the registry would be overwritten if a service pack were to be applied - I'll test that out and get back.

RE: SQL Server Preproduction Tasks

Jack Corbett — Wed, 26 Nov 2008 09:01:20 GMT

Nice article Ken. Makes me think I need to be doing more. I particularly like the fact that you included all the links in the article. This could/should be a must read.

RE: SQL Server Preproduction Tasks

KenSimmons — Wed, 26 Nov 2008 08:43:01 GMT

[quote][b]Steven Webster (11/26/2008)[/b][hr]Great article Ken. Much appreciated.Can I ask your views on the following - I recently had auditors in and one of their recommendations was to increase the maximum number of error log files to a value of 25000 or higher via a registry hack. In the vulnerability report they give the following reason for this:[i]To prevent the loss of auditing data, it is recommended that you set this value high enough that the error logs will not be overwritten when restarting the database. Also note that there is a stored procedure, sp_cycle_errorlog, that closes an errorlog and creates a new file. An attacker could attempt to cover their tracks by overwriting files using this stored procedure. It is recommended that you set the value high enough that an attacker could not cycle the logs enough times in a reasonable amount of time to overwrite the error log containing an attack.[/i]Many thanksSteven[/quote]I am not sure I would want to use a registry hack. I would see if I could archive the logs somewhere or something. I would just make sure to test it first. I know it is a registry setting that gets changed when you script it out, but I have never tried anything over the maximum value of 99.It wonder if it would get reset after a service pack upgrade?

RE: SQL Server Preproduction Tasks

Mohit K. Gupta — Wed, 26 Nov 2008 08:41:24 GMT

[quote][b]Ken Simmons (11/26/2008)[/b][hr]Failed logins are really the most important. It just depends on how busy your system is. It is all preference on what you would like to monitor.I use the maintenace database to hold procedures and tables for...reindexing, capturing database size for trending, capturing critical events from the error log, etc.Jonathan Kehayias did a real good presentation called Automating Common DBA Tasks that has a lot of other good ideas. It can be found under the live meeting recordings here.http://www.sqlpass.org/Community/SIGs/DatabaseAdministrationSIG/tabid/80/Default.aspx[/quote]Thank-you Mr. Ken. I'll add that to my articles to read/watch ;-). Thanks again for a important article :D.

RE: SQL Server Preproduction Tasks

Anipaul — Wed, 26 Nov 2008 08:34:42 GMT

Well written. Excellent article...

RE: SQL Server Preproduction Tasks

KenSimmons — Wed, 26 Nov 2008 08:32:30 GMT

[quote][b]Jeff Moden (11/25/2008)[/b][hr]Very nicely done, Ken. Lot's o' work went into that one. Great job.[/quote]Thanks Jeff. It really wasn't that much work. I just wanted to share some of the things I do (or at least think about doing) when setting up a server.I would love to hear what some other people do as well. I am always looking for new ideas to help improve performance and maintain system stability.

RE: SQL Server Preproduction Tasks

KenSimmons — Wed, 26 Nov 2008 08:22:33 GMT

Failed logins are really the most important. It just depends on how busy your system is. It is all preference on what you would like to monitor.I use the maintenace database to hold procedures and tables for...reindexing, capturing database size for trending, capturing critical events from the error log, etc.Jonathan Kehayias did a real good presentation called Automating Common DBA Tasks that has a lot of other good ideas. It can be found under the live meeting recordings here.http://www.sqlpass.org/Community/SIGs/DatabaseAdministrationSIG/tabid/80/Default.aspx

RE: SQL Server Preproduction Tasks

Mohit K. Gupta — Wed, 26 Nov 2008 07:52:31 GMT

Oops forgot to ask questions regarding the article :P.Point #2, Enable Successful and Failed logs ...I understand having that on for the first little while in a new system to make sure you know who is hitting the system. But by enabling both Successfull and Failed will it not fill up the error log alot quicker. Like for example on some of my serers there are over 3000 successful connections/day. I track successful for a while when setting up new server to make sure things are funcitonal; then I switch to Failed log ons only. Recommendations are both or just failed? Comments?Point #7, Create a maintenance database ...I just starting doing that recently on SQL Server 2000 environment because we needed to track access to the user/database login. And be able to report it out quickly. I am also using this for storing some Stored procedure for selective reindexing? What else can be in this database?Thanks for the Article, really good pointers :D.I will be reading the articles you posted today they look really good :D. :w00t:

RE: SQL Server Preproduction Tasks

Mohit K. Gupta — Wed, 26 Nov 2008 07:49:10 GMT

Steve, For auduting purpose I would recommend saving up the Default Trace log; depending on your work load, you can save that daily, or multiple times/day. And that trace log has alot more information the SQL Server error logs do.- Mohit.

RE: SQL Server Preproduction Tasks

Steven Webster-494809 — Wed, 26 Nov 2008 03:35:29 GMT

Great article Ken. Much appreciated.Can I ask your views on the following - I recently had auditors in and one of their recommendations was to increase the maximum number of error log files to a value of 25000 or higher via a registry hack. In the vulnerability report they give the following reason for this:[i]To prevent the loss of auditing data, it is recommended that you set this value high enough that the error logs will not be overwritten when restarting the database. Also note that there is a stored procedure, sp_cycle_errorlog, that closes an errorlog and creates a new file. An attacker could attempt to cover their tracks by overwriting files using this stored procedure. It is recommended that you set the value high enough that an attacker could not cycle the logs enough times in a reasonable amount of time to overwrite the error log containing an attack.[/i]Many thanksSteven

RE: SQL Server Preproduction Tasks

magarity kerns — Wed, 26 Nov 2008 03:09:46 GMT

Excellent checklist! May I add a caveat to #1: The latest patch level [i]supported by the front end app's picky vendor (if applicable).[/i]

RE: SQL Server Preproduction Tasks

humbleDBA — Wed, 26 Nov 2008 01:36:33 GMT

Ditto Jeff's comments, Ken.

RE: SQL Server Preproduction Tasks

Jeff Moden — Tue, 25 Nov 2008 23:08:00 GMT

Very nicely done, Ken. Lot's o' work went into that one. Great job.

SQL Server Preproduction Tasks

KenSimmons — Tue, 25 Nov 2008 23:06:35 GMT

Comments posted to this topic are about the item [B]SQL Server Preproduction Tasks[/B]