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

Best Practices / Considerations Expand / Collapse
Posted Monday, October 28, 2013 11:58 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, February 14, 2014 2:05 PM
Points: 55, Visits: 162
Need to pick the minds of gurus here.

What are the considerations / what determines that application A will go to SQL Server X while application B will go to SQL Server Y?
Should there be a separation? What are the considerations involved for the separation?

Post #1509065
Posted Tuesday, October 29, 2013 12:28 AM

Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 8:24 PM
Points: 3,589, Visits: 5,095
One thing I'd look at is integration points.

If application A is using data from any application sitting on server Y, perhaps its database is best stored on server Y.

My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
Post #1509186
Posted Tuesday, October 29, 2013 4:50 AM



Group: General Forum Members
Last Login: Today @ 3:51 AM
Points: 14,788, Visits: 27,264
Assuming you're monitoring your servers, you know that server X is under some stress for CPU and this new app looks like it might have lots of recompiles, so it goes on Server Y. You need to know what your servers are doing and what the apps are going to do. This involves monitoring the servers and testing the applications. Then use the numbers in hand to make decisions. Further, Server X is Enterprise and Server Y is not. Does your application need Enterprise only options? If so, it's going on Server X, if not, Server Y.

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1509263
Posted Friday, November 01, 2013 11:48 AM



Group: General Forum Members
Last Login: Today @ 6:51 AM
Points: 178, Visits: 284
I always look at the technical aspects of the server where I plan to put the database, maybe one server has better hardware than another. If I know the performance metrics behind everything it helps to delve out space on the server that can handle the load.
Post #1510737
Posted Friday, November 01, 2013 11:59 AM



Group: General Forum Members
Last Login: Today @ 11:47 AM
Points: 20,455, Visits: 14,068
Some of the considerations need to also be business rules. In addition to the business rules (like some security separation for instance), one needs to consider Vendor interference and how much you are willing to have vendor a intermingle with vendor b.

Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server


Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #1510746
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse