Throwing Hardware at SQL Server Performance: Does It Work?

By:


If you’re database professional, you continuously face the challenge of improving database performance. Throwing hardware at the problem is a common solution to slow performance. And this approach often focuses on procuring SSD storage, servers, or CPU. But is ‘throwing hardware at the problem’ the right solution or is it just a big gamble?

We brought together a group of expert DBAs, geeks and IT/System administrators to share what they thought about hardware scaling as a solution to accelerate database performance. They joined hosts SolarWinds Head Geek Thomas LaRock (@SQLRockstar) and SQL Server MVP Jason Strate (@StrateSQL) from Pragmatic Works.  We posed some key questions to the participants on using hardware to address database performance problems, and here are some key takeaways from the conversation (you can see the full chat transcript at the end of this article).

Tip: Hardware may solve database performance issues, but know the root cause first

Many participants referred directly to the need to do a thorough analysis to isolate the root cause, before taking corrective action. Although this may seem obvious, there are some situations in which this might not happen, including:

  • When hardware is cheaper than spending time to redo code.
  • When there is a lack of departmental expertise to identify performance tuning to resolve bottleneck, as Kong Yang pointed out:

On the other hand, many participants pointed out that fixing code is almost (always) faster than procuring (unneeded) hardware.

Yang Lack of Expertise

For 8 tips on speeding SQL Server performance without provisioning new hardware, see this helpful infographic.

Tip: Throwing hardware at performance issues incurs hidden costs

 Most of the participants agreed that the real cost of adding hardware without understanding the root cause of performance issues is long-term ‘technical debt,’ as you are not solving the real problem. Part of the technical debt is the creation of unneeded complexity as Paul Timmerman points out:

PTimmerman Complexity

Tip: Performance is everyone’s problem

On this topic, participants were unanimous that everyone, from users to IT is responsible for application performance. Jason Strate reminded everyone that bad performance is not an us vs them issue:

Strate Bad Performance Not Us vs Them

Considering that performance manifests differently at different levels, it’s critical that everyone be included in addressing issues, as Malathi Mahadevan wrote:

Mahadevan Everyone has a role

Conclusion

It’s not uncommon to opt for hardware to address slow performance or simply try to accelerate performance, without completing a thorough analysis of the bottleneck and the root cause. Before you opt for that shiny new hardware, though, you should take the time to gather information, establish baselines and maintain performance history, so that you can properly assess root cause.

And, in the final analysis, great database performance starts long before production issues. As lamented by Thomas LaRock, great database performance should always start with great design:

LaRock Great Design

Read the full datachat transcript here

Handle Tweet
SWI_Database Q1: So, who *should* we throw hardware at instead? In other words, “when” does it make sense to throw hardware at the problem? #datachat
StrateSQL .@SWI_Database Q1: Solutions that are designed to be hardware scalable, PDW and Hadoop come to mind first. #datachat
SQLRockstar RT @SWI_Database: Q1: So, who *should* we throw hardware at instead? In other words, “when” does it make sense to throw hardware at the p…
StrateSQL .@SWI_Database Q1: (cont) But also resource constrained solutions AFTER code has been optimized. #datachat
SQLMickey In memory (Hekaton) solutions will need it as well. #datachat
StrateSQL RT @SWI_Database: Q1: So, who *should* we throw hardware at instead? In other words, “when” does it make sense to throw hardware at the p…
StrateSQL RT @SQLMickey: In memory (Hekaton) solutions will need it as well. #datachat <– this as well, new features
SQLRockstar .@SWI_Database A1: When you have ruled out everything else as a bottleneck, that’s when you should think about hardware. #datachat
jdanton @SQLRockstar @SWI_Database a1: Sometimes, HW is cheaper than fixing code. #datachat
SQLRockstar .@SWI_Database A1: Also, there are times when you decide hardware is cheaper than spending time to redo code. #datachat
SQLRockstar RT @jdanton: @SQLRockstar @SWI_Database a1: Sometimes, HW is cheaper than fixing code. #datachat
LawrenceGarvin @jdanton @SQLRockstar @SWI_Database Cheaper != Better #datachat
SQLRockstar RT @LawrenceGarvin: @jdanton @SQLRockstar @SWI_Database Cheaper != Better #datachat
SQLRockstar OH HAI LAWRENCE! @LawrenceGarvin @jdanton @SWI_Database #datachat
jdanton @LawrenceGarvin @SQLRockstar @SWI_Database RAM solves a lot of code problems, not all. but a lot. #datachat
StrateSQL RT @jdanton: @SQLRockstar @SWI_Database a1: Sometimes, HW is cheaper than fixing code. #datachat
StrateSQL RT @LawrenceGarvin: @jdanton @SQLRockstar @SWI_Database Cheaper != Better #datachat
SWI_Database @jdanton @Eshbaugh welcome back! #datachat
StrateSQL RT @jdanton: @LawrenceGarvin @SQLRockstar @SWI_Database RAM solves a lot of code problems, not all. but a lot. #datachat
StrateSQL RT @SWI_Database: @jdanton @Eshbaugh welcome back! #datachat
SQLRockstar RT @SQLMickey: In memory (Hekaton) solutions will need it as well. #datachat
LawrenceGarvin .@SQLRockstar Cheers Tom! #datachat
StrateSQL .@jdanton @LawrenceGarvin @SQLRockstar @SWI_Database RAM can forgive some sins, especially the sin of improper initial RAM #datachat
SQLRockstar .@jdanton @SWI_Database Yeah, but too often hardware is the choice w/o doing proper analysis first. #datachat
StrateSQL RT @SQLRockstar: .@jdanton @SWI_Database Yeah, but too often hardware is the choice w/o doing proper analysis first. #datachat
jdanton @SQLRockstar @SWI_Database Agreed—I’m thinking of a very specific case I encountered. #datachat
chapmandew @StrateSQL @jdanton @LawrenceGarvin @SQLRockstar @SWI_Database lots of RAM solves less problems than you’d think. #datachat
SQLRockstar RT @chapmandew: @StrateSQL @jdanton @LawrenceGarvin @SQLRockstar @SWI_Database lots of RAM solves less problems than you’d think. #datachat
SQLRockstar OH HAI TIM! @chapmandew @StrateSQL @jdanton @LawrenceGarvin @SWI_Database #datachat
SWI_Database Q2: What are the hidden costs with extra hardware? #datachat
Eshbaugh A1: In the past hardware was an easy answer,  aside from SSD & multi core there have not been any advancements in some time#datachat
StrateSQL .@chapmandew @jdanton @LawrenceGarvin @SQLRockstar @SWI_Database definitely.  More RAM solved 4GB of RAM issues. #datachat #savingpennys
jdanton @SWI_Database A2: Database licensing. #datachat
StrateSQL .@SWI_Database A2: The hidden cost is failure.  More hardware doesn’t always mean better performance and can lead to harder issues #datachat
mnDBA RT @jdanton: @SWI_Database A2: Database licensing. #datachat
StrateSQL RT @jdanton: @SWI_Database A2: Database licensing. #datachat <– hehe, let me just add a few dozen cores
Eshbaugh A2: Procurement headaches #datachat
LawrenceGarvin @SWI_Database A2. To the prev point about RAM… extra hardware begets more inefficient coding. #datachat
SQLRockstar .@SWI_Database A2: Core-based licensing, for one. But another is “technical debt”, you aren’t solving the real issue. #datachat
StrateSQL RT @LawrenceGarvin: @SWI_Database A2. To the prev point about RAM… extra hardware begets more inefficient coding. #datachat
SQLMickey A2: Downtime #datachat
StrateSQL RT @SQLRockstar: .@SWI_Database A2: Core-based licensing, for one. But another is “technical debt”, you aren’t solving the real issue. #dat…
SWI_Database RT @SQLRockstar: .@SWI_Database A2: Core-based licensing, for one. But another is “technical debt”, you aren’t solving the real issue. #dat…
MikeOlkin “@jdanton: @SWI_Database A2: Database licensing. #datachat” I’ll second that.
Eshbaugh RT @LawrenceGarvin: @SWI_Database A2. To the prev point about RAM… extra hardware begets more inefficient coding. #datachat
SQLRockstar .@LawrenceGarvin @SWI_Database Yep, buying more hardware just means you have more room for bad code. #datachat
SQLRockstar RT @MikeOlkin: “@jdanton: @SWI_Database A2: Database licensing. #datachat” I’ll second that.
SQLRockstar RT @StrateSQL: .@chapmandew @jdanton @LawrenceGarvin @SQLRockstar @SWI_Database definitely.  More RAM solved 4GB of RAM issues. #datachat #…
SQLMickey I agree with @SQLRockstar . The problem will still grow and now budget has been depleted #datachat
KongYang A1: when your department doesn’t have enough SQL Server tuning & perf tuning expertise to resolve the bottleneck #datachat
StrateSQL RT @SQLMickey: I agree with @SQLRockstar . The problem will still grow and now budget has been depleted #datachat
StrateSQL RT @SQLRockstar: .@LawrenceGarvin @SWI_Database Yep, buying more hardware just means you have more room for bad code. #datachat
StrateSQL RT @Eshbaugh: A2: Procurement headaches #datachat
StrateSQL RT @KongYang: A1: when your department doesn’t have enough SQL Server tuning & perf tuning expertise to resolve the bottleneck #datachat
datachick RT @SQLRockstar: .@SWI_Database A1: When you have ruled out everything else as a bottleneck, that’s when you should think about hardware. #…
mnDBA @SWI_Database A2: Complexity. Seen folks throw new “fancy” hardware at an issue without actually understanding it. #datachat
SQLRockstar RT @KongYang: A1: when your department doesn’t have enough SQL Server tuning & perf tuning expertise to resolve the bottleneck #datachat
SQLRockstar RT @mnDBA: @SWI_Database A2: Complexity. Seen folks throw new “fancy” hardware at an issue without actually understanding it. #datachat
sqlmal @KongYang @StrateSQL @SQLRockstar @SWI_Database Late to the party, greetings from KY! #datachat
SQLRockstar RT @sqlmal: @KongYang @StrateSQL @SQLRockstar @SWI_Database Late to the party, greetings from KY! #datachat
GDada7 RT @SQLRockstar: .@SWI_Database A2: Core-based licensing, for one. But another is “technical debt”, you aren’t solving the real issue. #dat…
StrateSQL RT @sqlmal: @KongYang @StrateSQL @SQLRockstar @SWI_Database Late to the party, greetings from KY! #datachat
StrateSQL RT @mnDBA: @SWI_Database A2: Complexity. Seen folks throw new “fancy” hardware at an issue without actually understanding it. #datachat
SWI_Database @sqlmal @mnDBA Welcome! #datachat
StrateSQL .@mnDBA @SWI_Database then there is the training and support for the new “fancy” hardware.  That’s free right? #datachat
Eshbaugh A2: Your Job!  if the million dollars in hardware does nothing to improve performance. #datachat
SWI_Database RT @mnDBA: . @SQLRockstar @SWI_Database And then you end up with a whole other set of problems to solve. #datachat
SQLRockstar RT @Eshbaugh: A2: Your Job!  if the million dollars in hardware does nothing to improve performance. #datachat
KongYang @sqlmal @KongYang @StrateSQL @SQLRockstar @SWI_Database Cheers! #datachat
StrateSQL RT @SWI_Database: RT @mnDBA: . @SQLRockstar @SWI_Database And then you end up with a whole other set of problems to solve. #datachat
SQLRockstar .@StrateSQL @mnDBA @SWI_Database and the fancy new application likely needs specialized support, too. #datachat
GDada7 @jdanton @SQLRockstar @SWI_Database true, but buying HW w/o understanding the app bottlenecks is not smart #datachat
StrateSQL RT @Eshbaugh: A2: Your Job!  if the million dollars in hardware does nothing to improve performance. #datachat
mnDBA . @StrateSQL @SWI_Database Hardware is often seen as cheaper than hiring a person w/expertise to solve your problems. #datachat
datachick This.  Time. Contracts.  Sales reps RT @Eshbaugh: A2: Procurement headaches #datachat
SWI_Database Q3: What is faster to deploy and why: throwing hardware or better code/design? #datachat
SQLRockstar .@datachick We’re talking about “throwing” hardware at performance issues. So, yeah, solve the perf issue 1st. #datachat
StrateSQL .@SWI_Database A3: Usually, code.  No procurement and less of an outage to deploy. #datachat
SQLMickey Q3: That depends on experience and red tape. #datachat
SQLRockstar .@datachick But not every piece of code can be changed, so sometimes you are stuck. #datachat
LawrenceGarvin @SWI_Database A3. Fixing code is almost always faster than procuring (unneeded) hardware! #datachat
SQLRockstar RT @SWI_Database: Q3: What is faster to deploy and why: throwing hardware or better code/design? #datachat
SWI_Database RT @adazlian:  A2:  Extraneous fees besides SQL server. How many people remember backup, monitoring, & misc server fees/licenses. #datachat
SQLRockstar .@SWI_Database A3: Fixing code is faster than ordering new. But you can scale up in #Azure pretty fast, too. #datachat
StrateSQL .@SWI_Database A3: And when code will take longer, hardware probably won’t fix it, unless that it was designed for hardware scale #datachat
KongYang A2: More HW = more complexity & variables. And the actual problem still hasn’t been root caused. #datachat
SQLRockstar .@SWI_Database A3: The real question is “which is better”, and I would always vote for better code and design. #datachat
StrateSQL RT @LawrenceGarvin: @SWI_Database A3. Fixing code is almost always faster than procuring (unneeded) hardware! #datachat
StrateSQL RT @SWI_Database: RT @adazlian:  A2:  Extraneous fees besides SQL server. How many people remember backup, monitoring, & misc server fees/l…
GDada7 RT @SQLRockstar: .@datachick We’re talking about “throwing” hardware at performance issues. So, yeah, solve the perf issue 1st. #datachat
StrateSQL RT @SQLRockstar: .@SWI_Database A3: Fixing code is faster than ordering new. But you can scale up in #Azure pretty fast, too. #datachat
SQLRockstar .@SWI_Database “Great database performance starts with great database design.” – Me #datachat
mnDBA @SWI_Database @StrateSQL Bad things happen faster too on new hardware. Don’t solve underlying problem = double trouble #datachat
SQLRockstar RT @StrateSQL: .@SWI_Database A3: And when code will take longer, hardware probably won’t fix it, unless that it was designed for hardware …
SWI_Database RT @sqlmal: @SQLRockstar @SWI_Database A3: Tom’s suggestion gets my vote also as long as I own the software to fix. #datachat
Eshbaugh A3:  Another alternative to code/hardware is database configuraiton (Indexes, table partitioning, in memory, …) #datachat
StrateSQL RT @SWI_Database: RT @sqlmal: @SQLRockstar @SWI_Database A3: Tom’s suggestion gets my vote also as long as I own the software to fix. #data…
StrateSQL RT @Eshbaugh: A3:  Another alternative to code/hardware is database configuraiton (Indexes, table partitioning, in memory, …) #datachat
SWI_Database RT @adazlian @SWI_Database A3 Changes to code+design increase exponentially. Hardware is hardware, fixed time to implement usually #datachat
mnDBA RT @SQLRockstar: .@SWI_Database “Great database performance starts with great database design.” – Me #datachat
datachick . @SWI_Database RAM upgrades can be fast and cheap. Just like 1/2 #datachat
datachick RT @SQLRockstar: .@SWI_Database “Great database performance starts with great database design.” – Me #datachat
KongYang RT @sqlmal: @StrateSQL @SQLRockstar @SWI_Database My 2c: Vendor software that you can’t fix or is too expensive to fix. #datachat
KongYang RT @SQLRockstar: .@SWI_Database “Great database performance starts with great database design.” – Me #datachat < +1
StrateSQL RT @KongYang: RT @SQLRockstar: .@SWI_Database “Great database performance starts with great database design.” – Me #datachat < +1
SQLMickey RT @SQLRockstar: .@SWI_Database “Great database performance starts with great database design.” – Me #datachat
SWI_Database Q4: Who is truly responsible for application performance? DBA? Developers? Other? #datachat
StrateSQL .@SQLRockstar @SWI_Database And if you can code changes to allow for linear improvements with new hardware… that’s even better #datachat
SQLRockstar RT @SWI_Database: Q4: Who is truly responsible for application performance? DBA? Developers? Other? #datachat
StrateSQL .@SWI_Database A4: Everyone. Bad performance is not an “us vs them” issue. Customers don’t want to know that it’s the DBA’s fault #datachat
StrateSQL RT @SWI_Database: Q4: Who is truly responsible for application performance? DBA? Developers? Other? #datachat
SQLRockstar .@SWI_Database A4: Everyone is responsible for database performance. Everyone. #datachat
SQLMickey Q4: It has to be a team effort. If the DBA and the App Dev and the Help Desk doesn’t communicate, then problems will be exist. #datachat
mnDBA @SWI_Database A4: Yes #datachat
SQLMickey RT @StrateSQL: .@SQLRockstar @SWI_Database And if you can code changes to allow for linear improvements with new hardware… that’s even be…
SQLRockstar .@SWI_Database A4: You can’t single one team out and say it is their responsibility. It’s shared. #datachat
SQLRockstar RT @StrateSQL: .@SWI_Database A4: Everyone. Bad performance is not an “us vs them” issue. Customers don’t want to know that it’s the DBA’s …
Eshbaugh A4: Who is will differ between organizations, but who should be is everyone who can impact performance.  #datachat
IAMM0NEY RT @SQLRockstar: .@SWI_Database “Great database performance starts with great database design.” – Me #datachat
StrateSQL .@SQLRockstar @SWI_Database @mnDBA @SQLMickey performance issues should bring everyone together in a kumbaya moment. #datachat
SQLRockstar .@SWI_Database A4: This is why we can’t have nice things. #datachat
StrateSQL RT @SQLRockstar: .@SWI_Database A4: This is why we can’t have nice things. #datachat
SQLMickey I think even users need to be added to the list. I had a user tell me 6 months later that she stopped using a rpt cuz of perfom. #datachat
SQLRockstar RT @SQLMickey: I think even users need to be added to the list. I had a user tell me 6 months later that she stopped using a rpt cuz of per…
manuSQLGeek @SQLRockstar @SWI_Database Well answered. It’s always team work. Collaboration and coordination #datachat
StrateSQL RT @SQLMickey: I think even users need to be added to the list. I had a user tell me 6 months later that she stopped using a rpt cuz of per…
mnDBA @SWI_Database A4: Everyone must communicate and understand workflow. Your one button click might result in hundreds of txn on DB. #datachat
SQLRockstar .@SQLMickey Yeah, everyone plays a part. Perhaps what is truly lacking is one person to gather all the data and help build a plan. #datachat
KongYang .@swi_database Dev + Ops share responsibility for app performance. They’re creating the ecosystem. It’s their responsibility. #datachat
onpnt @SQLMickey that information shouldn’t be a user lead finding. You should know if the tpt is unused and slow from logging #datachat
datachick RT @StrateSQL: .@SWI_Database A4: Everyone. Bad performance is not an “us vs them” issue. Customers don’t want to know that it’s the DBA’s …
StrateSQL .@SQLRockstar @SQLMickey maybe a role for a business analyst in an organization. #datachat
Eshbaugh A4: Q4.1  Do you think QA teams  and process helps or hurt performance by taking the responsibility away from “everybody”? #datachat
SWI_Database RT @StrateSQL: .@SQLRockstar @SQLMickey maybe a role for a business analyst in an organization. #datachat
mnDBA @SWI_Database A4: Don’t assume because something is running slow, everyone knows it. Perf manifests differently at each layer #datachat
SQLRockstar .@onpnt @SQLMickey Yeah, but many reports are ad-hoc, it can be difficult to know what is “normal”. #datachat
datachick .@SWI_Database Vendors. But they can’t fix what they don’t know performs poorly. Most SW vendors can’t dogfood their products #datachat
Eshbaugh RT @mnDBA: @SWI_Database A4: Don’t assume because something is running slow, everyone knows it. Perf manifests differently at each layer #d…
SWI_Database RT @mnDBA: @SWI_Database A4: Don’t assume because something is running slow, everyone knows it. Perf manifests differently at each layer #d…
SQLRockstar RT @mnDBA: @SWI_Database A4: Don’t assume because something is running slow, everyone knows it. Perf manifests differently at each layer #d…
SQLRockstar RT @Eshbaugh: A4: Q4.1  Do you think QA teams  and process helps or hurt performance by taking the responsibility away from “everybody”? #d…
sqlmal @SWI_Database Everyone has a role to play.DBAs,developers,good managers also should care about performance&support best practices. #datachat
StrateSQL .@Eshbaugh @SWI_Database A4.1 that depends a lot on the org.  But it can definitely happen. #datachat #throwItOverTheFence
datachick .@SWI_Database So vendor customers need to be able to show how the product performs under their workloads. And request changes. #datachat
SQLRockstar RT @sqlmal: @SWI_Database Everyone has a role to play.DBAs,developers,good managers also should care about performance&support best practic…
onpnt @SQLRockstar @SQLMickey plenty of native monitoring tools for all of this. It’s not the users job. If it comes to them, we failed #datachat
SQLMickey @onpnt You’re right, but not all places have metrics being gathered. THat is something that is developed as the team matures. #datachat
nadineCO RT @mnDBA: @SWI_Database A4: Don’t assume because something is running slow, everyone knows it. Perf manifests differently at each layer #d…
jdanton @datachick @SWI_Database ISVs are well served to have advisory group of good customers to help with that. cc @scoraellis #datachat
SQLRockstar .@datachick @SWI_Database Yeah, I’ve seen few vendors that truly care about making improvements. #datachat
MelaniePerry RT @Eshbaugh: A4: Who is will differ between organizations, but who should be is everyone who can impact performance.  #datachat
StrateSQL RT @jdanton: @datachick @SWI_Database ISVs are well served to have advisory group of good customers to help with that. cc @scoraellis #data…
StrateSQL RT @SQLRockstar: .@datachick @SWI_Database Yeah, I’ve seen few vendors that truly care about making improvements. #datachat
SQLRockstar .@datachick @SWI_Database I think where the vendor is in their lifecycle matters most. #datachat
datachick RT @jdanton: @datachick @SWI_Database ISVs are well served to have advisory group of good customers to help with that. cc @scoraellis #data…
mnDBA RT @datachick: .@SWI_Database So vendor customers need to be able to show how the product performs under their workloads. And request chang…
MelaniePerry @SWI_Database #datachat I agree with those who say everyone, top to bottom. As SysAdmin, it falls to me to find out who, lol.
SQLRockstar .@datachick @SWI_Database Some companies get to a point where they can’t help, even if they want to help. #datachat
suaadsait RT @SWI_Database: Q4: Who is truly responsible for application performance? DBA? Developers? Other? #datachat
Eshbaugh It is amazing the dollars spent to promote hardware solutions for #SqlServer and #Oracle performance  #datachat
datachick .@SQLRockstar @SWI_Database Yep I’ve sent index recommendations to vendors who don’t believe in them. #datachat
SWI_Database Q5: What advances in hardware technology are a “must-have” for the next five years and why? #datachat
mnDBA @SWI_Database Aside from obvious issues, I can’t fix what I don’t know is broken. Tell me where it hurts and we’ll work on it. #datachat
jdanton @SWI_Database A5: RAM is going to be a LOT more dense in the next 5 yrs. #datachat
SQLRockstar RT @datachick: .@SQLRockstar @SWI_Database Yep I’ve sent index recommendations to vendors who don’t believe in them. #datachat
SQLRockstar RT @SWI_Database: Q5: What advances in hardware technology are a “must-have” for the next five years and why? #datachat
SQLMickey Q5: Solid state drives as well as other media that is written to. The important part will be to understand which to use when. #datachat
Eshbaugh RT @SQLMickey: Q5: Solid state drives as well as other media that is written to. The important part will be to understand which to use when…
SQLRockstar .@SWI_Database A5: VSAN. There is a new generation of arrays coming out, and that’s the shiny everyone should want. #datachat
StrateSQL .@SWI_Database A5: Depends on the features and needs of the application.  Fitting features to hardware choices won’t end well #datachat
mnDBA @SWI_Database A5: Solid state. No more spinning disk. Understand the tech though! Not a magic bullet. #datachat
SQLRockstar RT @StrateSQL: .@SWI_Database A5: Depends on the features and needs of the application.  Fitting features to hardware choices won’t end wel…
StrateSQL RT @jdanton: @SWI_Database A5: RAM is going to be a LOT more dense in the next 5 yrs. #datachat <– #truestory
jdanton @SQLRockstar @SWI_Database A5: spinning disk is going to mostly be dead. #datachat
mnDBA RT @jdanton: @SWI_Database A5: RAM is going to be a LOT more dense in the next 5 yrs. #datachat
SQLRockstar .@jdanton @SWI_Database You spelled “spinning rust” wrong. #datachat
SQLRockstar RT @jdanton: @SWI_Database A5: RAM is going to be a LOT more dense in the next 5 yrs. #datachat
StrateSQL .@jdanton @SQLRockstar @SWI_Database until the #sqlhipsters bring it back for old school performance issues #datachat
jdanton @SQLRockstar @SWI_Database I think we should just call it high latency storage. #datachat
StrateSQL RT @jdanton: @SQLRockstar @SWI_Database I think we should just call it high latency storage. #datachat
SQLRockstar .@thatjeffsmith I will! Many vendors build vanilla solutions, knowing they will work well for 80% of customers. #datachat
SQLMickey RT @StrateSQL: .@jdanton @SQLRockstar @SWI_Database until the #sqlhipsters bring it back for old school performance issues #datachat
mnDBA Love it!! RT @jdanton: @SQLRockstar @SWI_Database I think we should just call it high latency storage. #datachat
SQLRockstar .@thatjeffsmith But not many vendors make efforts to help the 20%. Some do, and some don’t care. #datachat
StrateSQL RT @mnDBA: @SWI_Database A5: Solid state. No more spinning disk. Understand the tech though! Not a magic bullet. #datachat
StrateSQL RT @jdanton: @SQLRockstar @SWI_Database A5: spinning disk is going to mostly be dead. #datachat
StrateSQL RT @SQLRockstar: .@SWI_Database A5: VSAN. There is a new generation of arrays coming out, and that’s the shiny everyone should want. #datac…
SQLRockstar .@thatjeffsmith I know one company, leaders in stock trading software, that have essentially said “live with it”. #datachat
StrateSQL RT @jdanton: @SWI_Database A5: RAM is going to be a LOT more dense in the next 5 yrs. #datachat
DBABullDog @SWI_Database A5: hardware replication old  but new to many providing quick DR turnaround. #datachat
sqlmal @SQLRockstar @thatjeffsmith yes vanilla slns oriented many times towards app functionality,not necessary good tech that goes w/it #datachat
SQLRockstar .@thatjeffsmith They didn’t care about perf issues, or retaining us as a customer. They knew our options were limited. #datachat
jdanton @DBABullDog @SWI_Database a5: physical servers will be a rarity. #datachat
SQLRockstar RT @StrateSQL: .@jdanton @SQLRockstar @SWI_Database until the #sqlhipsters bring it back for old school performance issues #datachat
sqlmal @SQLRockstar @thatjeffsmith some apps esp in healthcare are pretty rare to find, lot of vendor solns ride on that with poor tech #datachat
SQLRockstar .@StrateSQL @jdanton @SWI_Database I bet #sqlhipsters will bring it back for edge case reasoning. #datachat
SQLRockstar RT @jdanton: @SQLRockstar @SWI_Database I think we should just call it high latency storage. #datachat
SQLRockstar RT @sqlmal: @SQLRockstar @thatjeffsmith some apps esp in healthcare are pretty rare to find, lot of vendor solns ride on that with poor tec…
StrateSQL .@SQLRockstar @jdanton @SWI_Database that.. and to make music #sqlhipsters https://t.co/yMBFGCcAEk #datachat
SQLRockstar RT @StrateSQL: .@SQLRockstar @jdanton @SWI_Database that.. and to make music #sqlhipsters https://t.co/yMBFGCcAEk #datachat
SWI_Database Q6 anyone? #datachat
SQLMickey Bueller? >> RT @SWI_Database: Q6 anyone? #datachat
blisslogixIT RT @Eshbaugh: It is amazing the dollars spent to promote hardware solutions for #SqlServer and #Oracle performance  #datachat
StrateSQL .@SWI_Database go for it.  #YouCanDoIt #datachat
SWI_Database Q6: What hardware should every DBA want to receive as a gift this holiday season? #datachat
StrateSQL .@SWI_Database A6: X-Box One.  DBA’s work hard enough, they need something to play with. #datachat
SQLRockstar RT @SWI_Database: Q6: What hardware should every DBA want to receive as a gift this holiday season? #datachat
jdanton @SWI_Database !6: A new laptop. #datachat
SQLRockstar RT @StrateSQL: .@SWI_Database A6: X-Box One.  DBA’s work hard enough, they need something to play with. #datachat
Eshbaugh A5: Spinning disks will vanish,  we just need some improvements in the SSD Technology to make it happen faster.    #datachat
mnDBA @SWI_Database See solutions all the time geared towards lowest common support denominator. Then we hear “u want t do what??” #datachat #isv
manuSQLGeek @mnDBA @jdanton @SQLRockstar @SWI_Database One reason why my SAN Admin is a heavy weight lifting champion https://t.co/CljBGvJV22 #datachat
SQLMickey @SWI_Database A faster laptop that doesn’t weigh 9lbs with a smaller longer battery! #datachat
StrateSQL .@onpnt @DBABullDog @jdanton @SQLRockstar @SWI_Database it definintely does stay around, good choices early are critical #datachat
datachick RT @jdanton: @DBABullDog @SWI_Database a5: physical servers will be a rarity. #datachat
mnDBA Check! RT @StrateSQL: .@SWI_Database A6: X-Box One. DBA’s work hard enough, they need something to play with. #datachat
DBABullDog @jdanton @SWI_Database agree 100% and if they do exist we will be virtualizing and doing more with less. #datachat
SQLMickey RT @mnDBA: Check! RT @StrateSQL: .@SWI_Database A6: X-Box One. DBA’s work hard enough, they need something to play with. #datachat
jdanton @DBABullDog @SWI_Database The forthcoming memory density will help. I hope. #datachat
manuSQLGeek RT @StrateSQL: .@SWI_Database A6: X-Box One.  DBA’s work hard enough, they need something to play with. #datachat
mnDBA @SWI_Database A6: Whatever they need to do their job. Orgs throw $$ at server space but miss low hanging fruit for support staff. #datachat
SQLRockstar .@SWI_Database A6: A hammer, for their phone the next time they get woken up in the middle of the night. #datachat
StrateSQL RT @SQLRockstar: .@SWI_Database A6: A hammer, for their phone the next time they get woken up in the middle of the night. #datachat
StrateSQL RT @SWI_Database: Q6: What hardware should every DBA want to receive as a gift this holiday season? #datachat
datachick .A6 @SWI_Database a heart rate monitor that feeds into monitoring SW and send appropriate alerts when it is too low or too high. #datachat
SQLRockstar RT @datachick: .A6 @SWI_Database a heart rate monitor that feeds into monitoring SW and send appropriate alerts when it is too low or too h…
StrateSQL RT @datachick: .A6 @SWI_Database a heart rate monitor that feeds into monitoring SW and send appropriate alerts when it is too low or too h…
StrateSQL RT @mnDBA: @SWI_Database A6: Whatever they need to do their job. Orgs throw $$ at server space but miss low hanging fruit for support staff…
SWI_Database RT @datachick: .A6 @SWI_Database a heart rate monitor that feeds into monitoring SW and send appropriate alerts when it is too low or too h…
SQLMickey RT @datachick: .A6 @SWI_Database a heart rate monitor that feeds into monitoring SW and send appropriate alerts when it is too low or too h…
manuSQLGeek RT @StrateSQL: .@SQLRockstar @jdanton @SWI_Database that.. and to make music #sqlhipsters https://t.co/yMBFGCcAEk #datachat
datachick . @SQLRockstar @SWI_Database a Data Architect to do all that businessy design stuff #datachat
SWI_Database RT @_stump: @SWI_Database A5: physical servers and spinning disks. We’re in a virtual / flash bubble. #datachat
SQLRockstar .@datachick @SWI_Database That’s not hardware. #datachat
jdanton @DBABullDog @SWI_Database a6: you want nan Xtreme IO and not a VMax. #datachat
SWI_Database Q7: If you could redesign one feature of #sqlserver, what would it be and why #datachat
DBABullDog “@jdanton: @SWI_Database a6: you want nan Xtreme IO and not a VMax. #datachat” – list updated and sent to the big man
datachick .@SQLRockstar @SWI_Database Meatware?  It’s not software #datachat
mnDBA Have on….. LOVE IT!! RT @jdanton: @DBABullDog @SWI_Database a6: you want nan Xtreme IO and not a VMax. #datachat
SQLMickey @SWI_Database Really stupid code would not compile. #datachat
SQLRockstar RT @SWI_Database: Q7: If you could redesign one feature of #sqlserver, what would it be and why #datachat
StrateSQL .@SWI_Database A7: Not necessarily a feature, but the dev/deploy xp is not where it needs to be leading to bad design practices #datachat
SQLRockstar .@SWI_Database A7: Updating SQL Agent to be closer to a true enterprise-class job scheduler. #datachat
StrateSQL RT @SQLRockstar: .@SWI_Database A7: Updating SQL Agent to be closer to a true enterprise-class job scheduler. #datachat
DBABullDog RT @SQLRockstar: .@SWI_Database A7: Updating SQL Agent to be closer to a true enterprise-class job scheduler. #datachat
SWI_Database Well THANK YOU for another awesome #datachat everyone! cc: @StrateSQL @SQLRockstar
StrateSQL RT @SWI_Database: Well THANK YOU for another awesome #datachat everyone! cc: @StrateSQL @SQLRockstar
SQLRockstar .@datachick @SWI_Database Meatware? Is there a steam table with #bacon nearby that I missed? #datachat
StrateSQL RT @SQLRockstar: .@datachick @SWI_Database Meatware? Is there a steam table with #bacon nearby that I missed? #datachat
SQLRockstar RT @SWI_Database: Join us 12/11 Webinar: Stop Throwing Hardware @ #SQLServer Performance! @StrateSQL @sqlballs @rwolter50 http://t.co/fmHjE…
StrateSQL RT @SWI_Database: Join us 12/11 Webinar: Stop Throwing Hardware @ #SQLServer Performance! @StrateSQL @sqlballs @rwolter50 http://t.co/fmHjE…
SQLRockstar @SWI_Database @StrateSQL @sqlballs @rwolter50 I’ll be there! #datachat
StrateSQL .@SWI_Database @sqlballs @rwolter50 looking forward to this on Thursday #datachat
SQLRockstar @StrateSQL @SWI_Database @sqlballs @rwolter50 I’m looking forward to the webinar as well. I’ll be the one with the scotch. #datachat
DBABullDog @SWI_Database object level backup and restore without 3rd party product #SQLServer would be nice. #datachat
SQLRockstar RT @DBABullDog: @SWI_Database object level backup and restore without 3rd party product #SQLServer would be nice. #datachat
StrateSQL RT @SQLRockstar: @StrateSQL @SWI_Database @sqlballs @rwolter50 I’m looking forward to the webinar as well. I’ll be the one with the scotch.…
StrateSQL RT @DBABullDog: @SWI_Database object level backup and restore without 3rd party product #SQLServer would be nice. #datachat
DBABullDog RT @SWI_Database: Join us 12/11 Webinar: Stop Throwing Hardware @ #SQLServer Performance! @StrateSQL @sqlballs @rwolter50 http://t.co/fmHjE…
SWI_Database If you have questions for our hosts, feel free to prop them. We’ll be here for a little longer. #datachat
mnDBA RT @SWI_Database: Well THANK YOU for another awesome #datachat everyone! cc: @StrateSQL @SQLRockstar
DBABullDog @SWI_Database if you had to choose  only one goal for 2015 what would it be? #datachat
datachick RT @SQLRockstar: GAMETIME! #datachat @solarwinds http://t.co/aWhTAff11y
SWI_Database RT @DBABullDog: @SWI_Database if you had to choose  only one goal for 2015 what would it be? #datachat
SQLRockstar .@DBABullDog @SWI_Database  Finding the perfect beach house for our family vacation next summer. #datachat
dumb_chauffeur RT @DBABullDog: @SWI_Database object level backup and restore without 3rd party product #SQLServer would be nice. #datachat
bradykelly RT @DBABullDog: @SWI_Database object level backup and restore without 3rd party product #SQLServer would be nice. #datachat

Comments

  1. good discussion. At my prior employer, server administration / hardware teams had no political clout, so were always losing the battle between tuning vs. resources. Then the decision was made to move some large applications to a hosted site/platform. When the development team specified the resources they wanted/needed and were used to internally, the price was astronomical and totally out of question. I think at that point, it was kind of an eye opening highlighting the amount of resources that had been dedicated internally, with tuning being a low priority.

Leave a Reply