Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Consolidation Matters Expand / Collapse
Author
Message
Posted Saturday, April 19, 2014 11:31 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:55 PM
Points: 31,278, Visits: 15,736
Comments posted to this topic are about the item Consolidation Matters






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1563272
Posted Saturday, April 19, 2014 1:10 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, April 30, 2014 6:38 AM
Points: 33, Visits: 65
With virtual machines, we have actually gone the other way creating instances for each application and may times on their own small VM. Currently we are limiting VM's to hold 3 instances max for small applications. With the entire host licensed, we do not have to worry about individual instances. The main reason we have gone in this direction is it is very hard to find a patching schedule when you have multiple areas in a 24X7 enterprise on the same machine. Ive found it takes months sometimes to come up with an agreed upon maintenance window. With everything separated it is much easier to patch, but requires patching on more servers. Are others doing the same thing with VM's?

- Tony Sweet
Post #1563281
Posted Monday, April 21, 2014 7:09 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 7:45 AM
Points: 140, Visits: 96
Our shop is has taken virtualization to almost an extreme. The VMWare team has modified configuration files so they can build a SQL Server from the ground up w/o DBA intervention. Sounds great, but the servers are directly delivered to the end user group before the DBAs have a chance for any follow on configuration. There is also no analysis to determine if the database(s) which require hosting can be placed on an existing asset. As a result, my team is being contacted on servers not performing well, and we don't even have the rights to login to the server, or even the instance.

Ray



Post #1563470
Posted Monday, April 21, 2014 8:54 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:55 PM
Points: 31,278, Visits: 15,736
nlion84DBA (4/21/2014)
Our shop is has taken virtualization to almost an extreme. The VMWare team has modified configuration files so they can build a SQL Server from the ground up w/o DBA intervention. Sounds great, but the servers are directly delivered to the end user group before the DBAs have a chance for any follow on configuration. There is also no analysis to determine if the database(s) which require hosting can be placed on an existing asset. As a result, my team is being contacted on servers not performing well, and we don't even have the rights to login to the server, or even the instance.

Ray


Certainly some work to do in your shop, but that's actually what I'd like done. Let me (as the DBA) has input into the config files for SQL Server and let instances be built. The nice thing about virtualization is that we can move the VMs across hosts to balance loads as needed, whether that's manual or automatic.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1563510
Posted Monday, April 21, 2014 9:18 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, May 22, 2014 12:08 PM
Points: 1, Visits: 6
When installing multiple instances on one virtual or physical machine, are you specifying the maximum memory used for each instance? I have always done that, but there is some disagreement in my organization about best practices. I just like the idea of being able to control my memory usage and allocate it to the most critical database instances.

Beth Albertson
City of Olympia
Post #1563520
Posted Monday, April 21, 2014 9:24 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 7:45 AM
Points: 140, Visits: 96
Since we have some active / active clusters, I configure my max memory for each instance, so there will be enough reserved memory on a node to at least allow the failed instance to restart on the other node. As a rule, for our standalone VMs, we only install one instance per VM.

-Ray



Post #1563522
Posted Monday, April 21, 2014 10:41 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: 2 days ago @ 12:57 PM
Points: 1,314, Visits: 2,897
In general we have virtualized almost all of our Windows servers except for about 10%. We do have 3 prod SQL Server clusters that are not as busy as some would think or as large as some would think. When it comes time to replace the hardware / upgrade my boss and I are in agreement to create VMs for these. SQL Server wise all of our standalone non-clustered SQL Servers are now virtualized except for one which will will do in the near future.


Post #1563552
Posted Monday, April 21, 2014 11:44 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 7:42 PM
Points: 635, Visits: 2,215
Another thing we did at our last company when we consolidated databases on SQL instances is that we (I was part of the networking team) also basically created a DNS CName record for each application's DB.

So App1 had a CName record that pointed to ServerName1 AName record. So if we found a particular DB was causing too much stress on ServerName1, we could move or restore it on ServerName3 and then just edit the App1 CName record to point to the new server. It was an evening or weekend job, but it allowed us to make changes/moves that were invisible to the end user for all intents and purposes.




----------------
Jim P.

A little bit of this and a little byte of that can cause bloatware.
Post #1563571
Posted Monday, April 21, 2014 11:49 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Monday, November 10, 2014 7:42 AM
Points: 492, Visits: 814
Due to vendor "requirements" all of our systems have their own database installation on a dedicated server. Some of them have multiple instances to save on licensing for test. Other than that we throw away a lot of money on Windows licensing and SQL licensing.

I don't understand how you can easily migrate to a different server. Some of our applications bury the database connection where we can't modify it. In rare instances we could go in and change an ODBC connection, but that requires a downtime.

I would recommend starting with the shared design from day one, which you also recommended at the end of the article. If the server is virtual, more processors and memory can be thrown at it if any performance issues arise. Our VMWare environment is well designed, and we usually have plenty of power on any virtual server.


Dave
Post #1563572
Posted Monday, April 21, 2014 5:17 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 10:03 AM
Points: 35,547, Visits: 32,138
Heh... this reminds me of hemlines in fashion. They change every other year.

Remember when distributed computing was all the rage? It wasnt' that long ago. Just before that was consolidation. Just before that was distributed computing. Just before that was.... etc, etc, ad infinitum.

Now we even have distrubuted computing with "central management". That's a hemline with a big ol' slit down the legs to make it sexy.



--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1563647
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse