January 29, 2009 at 9:40 am
We need to get a formalized document to use enterprise wide as we have lots of divisions setting up their own SQL boxes now and doing it by just clicking "Next, Next, Next, Finish..." and then never touching it again after that..... until they call central IT because it crashed because of (and you can imagine the list of issues...)
ANYWAY, the obvious ideal solution is full centralization of all SQL server databases into a server cluster or some centralized system.... but this is the Real World and you know how well those things go over... baby steps.
So this is the first step.
I'm looking for a good FAQ or Microsoft document that speaks well and that I can use as the basis for our document.
I have my own notes that I always follow, but I want to compare those to industry standards and make sure I'M not making any stupid mistakes and not realizing it.
(I'm guessing there are probably some good resources here as well I should check out... if anyone would be willing to link me to those as well).
Once we finish this portion of our project we'll look at publishing documentation on how to take an already existing box, secure it, and also work to get it to the most recent service pack as well as other patches as they happen, etc...
(Honestly, I expect half the organizations once they see this to finally realize that SQL isn't like installing Word by clicking NEXT and FINISH, you have to actually do care and feeding.... so one positive outcome may be that people start WILLINGLY asking to have central IT host their SQL databases. For the other half, it will be good to have a nice, straight forward document they can follow with confidence.)
Thank you for your help!
February 2, 2009 at 1:31 am
Are you talking about servers consolidation?
MJ
February 2, 2009 at 6:42 am
No, but that is our end goal... way down the line.
I just mean to setup a new box.
You have hardware sitting there, and an SQL 05 install DVD/CDs in the other.
I just wondered if people had a check list they go through or a Microsoft doc they used as their base to build up their own internal procedures, etc...
I was looking for a "good" reference to use to compare and contrast against what I use personally and then refine it for organizational wide usage.
February 3, 2009 at 5:33 am
Hi
I have just gone through an exercise where I had to migrate from SQL 2K to 2K5 in 3 different locations (including merge replication and linked ORACLE servers). As the hardware was old and weak I had to replace this as well. Hence I was just migrating the data and the rest was built from scratch. During this process I put together several documents from configuring the server, installing SQL 2005, applying latest patches and yadayada...you name it.
As I'm just a DBA by accident I called in an external company as well to review our plans and settings.
To cut a long story short: I have some documentation which is used as standard now but it is not finished yet and before I share it with the world I need to remove/cover up some sensitive information. Hope you understand 😉
So I cannot promise you anything tomorrow or next week but I'll post it here as reply.
Cheers René
PS: Our servers run like a dream since then 😀
February 3, 2009 at 6:35 am
Think about the Packaging of SQL Server 2005.
It will help you to retain the standard as well as minimal knowledge.
HTH
---------------------------------------------------
"Thare are only 10 types of people in the world:
Those who understand binary, and those who don't."
February 3, 2009 at 7:18 am
That would be great.
Perhaps everyone could comment on it and a sort of "community accepted" document could come out of it and be refered to in a FAQ or something.
February 3, 2009 at 7:45 am
After I've analyzed my disk layout, server size, etc... and installed SQL 2005 with the latest SP. I then use the attached doc.... this should be a good start. I'd welcome any additions....
Tim White
February 3, 2009 at 8:44 am
Tim,
It was my understanding that the /3GB parm in the boot.ini was only needed for windows XP. If you are running your SQL Servers on Server 2003 or greater that shouldn't be an issue.
Good move IMO to remove the Built-in/Administrators group, we do that as quickly after an install as possible.
To OP:
I think a lot of the problems that building a standard form/procedure for people to use is that maintenance plans, T-Logs, maintenance clean-ups, etc... is something that would be different for each install and difficult to standardize. To hand someone with little to no experience a procedure on these things is difficult enough, but if you plan on creating an 'all inclusive' type document for this type of thing you would be up to 50 pages to make someone feel 'comfortable'. Who is going to follow a 50 page procedure?
If there is no way around stopping them from installing SQL Servers at will, then you must implement a policy that if your team is not notified of the install, at the time of the install, then you will not support the system.
There has to be some give and take, if you have IT depts. doing this at each location then setting up a notification policy like that should be very easy. If business departments are doing these installs, good luck to you my friend.
February 4, 2009 at 7:13 am
Have a look at SQL Server FineBuild. Even if you decide you don't want to use the scripts to do the installs, it can be worth raiding the Reference Manual for a step by step guide on getting a best-practice install.
If you do decide to use the scripts, they can be a great way to get a consistant build for your developers. If you tell them they just have to click on a file and FineBuild does everything for them, they are more likely to do that than click many times on the standard SQL install.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply