May 20, 2015 at 9:33 pm
Comments posted to this topic are about the item Naming Confusion
May 21, 2015 at 1:30 am
I too have seen all these styles used - Star Wars or Star Trek characters, simple numeric, suffix and prefix. Often mixed up as the administrators decide on one thing or another then changed their minds over time.
The best advice I saw was to change the colour scheme in SMSS to red or something to indicate live server - I think you can change the tab font colour on a per server basis. Still, I don't do that anyway. Like most I check, check and check again if doing anything update-y. You can never be too paranoid.
May 21, 2015 at 1:46 am
call.copse (5/21/2015)
...The best advice I saw was to change the colour scheme in SMSS to red or something to indicate live server - I think you can change the tab font colour on a per server basis...
This is what I do. I also manually check and check again but I have found, much like traffic lights, that you often do not notice that you have checked a green subconsciously but red drags it into the conscious thinking.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 21, 2015 at 1:49 am
I was at one place where they used Lord of the Rings characters. This lead to spelling issues.
Also, there is a tendency for a name to gain meaning so when X is replaced by Y that people still refer to X with most (ONLY MOST!!!) knowing that they are really referring to Y.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 21, 2015 at 2:22 am
I think names are better than random numbers, VM000001151, VM0000001150, and VM000001149 are a prod/dev/test set of servers for one of our apps.
Someone thought this was 'more secure', which is a pretty weak argument tbh as its the old obscurity != security.
And it causes all manners of hell when you do audits, upgrade projects or data centre migrations, as you've no idea what box/app your actually talking about.
May 21, 2015 at 2:51 am
I've come across numerous naming schemes over the years. Simple letter and number codes depicting OS and a simple count of the servers of that type (e.g. ux01, win03); planets and moons; LOTR or Star Trek characters; all the way through to elaborate codes that attempt to tell you the server's purpose, location, environment type etc.
Eventually you come across the limitations of all of them.
My only real criteria now is that the names should be easily communicable in both written and verbal forms. Beyond that, use Central Management Servers and label and group your instances. Create a database mapping servers and instances to applications.
Ultimately, working with the servers will reinforce the associations between the name and what is on them, but a complex unpronounceable naming convention will make this more difficult to achieve.
May 21, 2015 at 3:46 am
Where I work, we host thousands of servers for hundreds of clients, so we have to be organised about server naming. The first 3-4 letters indicate the overall system, then the next 3 indicate the function (web server, database, domain controller etc) within that system and then a numeric suffix which is often 01 but may be higher if more than one server performing that function. Part of the name may indicate prod, dev, test.
We have adopted the convention of colouring the desktop background red for production servers.
The naming convention leads to servers having similar names to each other. Perversely, this is an obvious risk and makes people more careful about which one they are connecting to.
May 21, 2015 at 5:25 am
At the risk of being Captain Obvious, like most naming conventions the best strategy is to pick one that works and use it consistently whether it's a table, column or server/instance.
The differing color per connection scheme is great but you have to have 2008 or later.
One thing I've done is to append DEV or TEST to database names on the appropriate environment so even if I mistakenly run a script in the wrong enviroment, I get an error. Of course it also means when deployment time comes I have to change the USE statements and maybe some other code (CTRL-H is my friend), but that in my mind is less inconvenient than having to say, restore a database because I wasn't watching what I was doing.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
May 21, 2015 at 5:57 am
My favourite naming convention was when i was working for a company who used formula one drivers.
It was a good bit of fun with a touch of logic as it referenced speed, whilst i was there one of our upgrades was to replace Senna with Schumacher (yes, a few years back)
I wonder if it is still used now, maybe with Hamilton, Vettel & Rosberg currently the servers of choice.
Although with the taming down of formula one I expect Schumacher & Senna where just as quick back then, so maybe its no longer such a relevant system...:-)
May 21, 2015 at 6:21 am
Server names that include it's physical location are problematic when the server is relocated to a different data center. Like wise a name like MSSQL2012 is problematic when it's upgraded. Like Steve suggested, the most user friendly server names are simple, subject oriented, and differentiate between DEV, QA, and PROD.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 21, 2015 at 6:36 am
Eric M Russell (5/21/2015)
Server names that include it's physical location are problematic when the server is relocated to a different data center.
I'm of the opinion that metadata about a server shouldn't be included in the name. I've seen naming conventions where the servers location is part of the name along with whether it is physical or virtual. Then we had a project to virtualize our servers... but we were sure what all of the applications were that pointed to those servers so the virtual machines had names that implied they were physical. Since VM's are relatively easy to move around, we then decided to move the VM's to a different location (because the virtual hosts there were under-utilized). So in the end we had servers with names implying they were physical when they were virtual and that they were in one facility when they were in another...
If naming things is hard, changing those names once they are in the wild is even harder!
May 21, 2015 at 6:38 am
We have thousands of servers. Each is named after a random six-character word. Each is provisioned in the domain to which it makes sense (prod, dev, etc.).
Why, you ask? Well how many six-letter words are in the dictionary? Our management system plays well with this scheme.
Also, as mentioned above, be careful with embedding meaning in server names. We all know that's a bad data practice.
May 21, 2015 at 6:38 am
While there is added security through obscurity by using coded names and numeric sequences, it becomes very difficult for people to remember them or to distinguish them one from another. Back when I was a network admin at a small manufacturing plant, we named the servers after planets and moons keeping the mythological reference and their function in mind. The email server was Mercury, the large file sharing server was Jupiter, the database server was Saturn, etc. Ironically, the only server we had that was later removed from the set was Pluto! 🙂
The point was that people in the plant could easily remember those servers and their function. I've also worked at places that named their servers by location, department, and a numeric sequence. While logical and easy to keep track of, that wrecked havoc when folks would get them mixed up.
I've also worked where the servers were named after cartoon characters, Star Trek references, etc. As someone else stated, they all have their flaws. The most important thing though is that whatever method is chosen, consistency is most important. If consistency is broken then it creates even more confusion.
LinkedIn: http://www.linkedin.com/in/sqlrv
Twitter: http://www.twitter.com/sqlrv
Website: http://sqlrv.com
May 21, 2015 at 6:46 am
Where I work, we host thousands of servers for hundreds of clients, so we have to be organised about server naming. The first 3-4 letters indicate the overall system, then the next 3 indicate the function (web server, database, domain controller etc) within that system and then a numeric suffix which is often 01 but may be higher if more than one server performing that function. Part of the name may indicate prod, dev, test.
Ours is similar. 1st 3-4 are server location, next 3-4 are application abbreviation, then 2 for sequence # for that function. Followed by a code for function A - application, W - web, D - database. Then a development/test/production code. It's like a VIN # for a car, each character has a purpose 😀
lshanahan (5/21/2015)
One thing I've done is to append DEV or TEST to database names on the appropriate environment so even if I mistakenly run a script in the wrong enviroment, I get an error. Of course it also means when deployment time comes I have to change the USE statements and maybe some other code (CTRL-H is my friend), but that in my mind is less inconvenient than having to say, restore a database because I wasn't watching what I was doing.
That's been a bigger question for me on the database side. As someone with access to our test and production servers, there's that tradeoff of ease vs. accident protection. Name the DBs the same in all environments and scripts and SSIS configuration files/connection managers port nicely. Of course then we incur the risk of running a large update in the wrong environment in SSMS because we didn't have to explicitly set the DB we're sitting in.
Ken
May 21, 2015 at 6:55 am
Having been part of several data center moves, using location in the server name never seemed practical but they continue to do it. Naming servers after characters while fun can lead to some miss understandings with the wife. Getting a late night call for Miss Piggy did bring up some questions. 🙂
In an environment with many servers, numbering becomes a requirement. I require each server to have a unique number. Having multiple servers numbered 1 is not helpful. I expect we will never have more than 999 database servers but you never now.
The server name often includes an identifier for production, QA, testing, developer,... Which worked well for production, but for the other environments it was considered a suggestion after a while.
Database names, user ids, and windows groups all identify their environment. It someone is running a query against a database with the suffix of _PROD. They must know it is production. A windows group for DEV would never be granted permissions to a production server.
David Bird
Viewing 15 posts - 1 through 15 (of 52 total)
You must be logged in to reply to this topic. Login to reply