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.
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:
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:
Considering that performance manifests differently at different levels, it’s critical that everyone be included in addressing issues, as Malathi Mahadevan wrote:
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:
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 |
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.