SQL Server database maintenance covers a lot of ground, from regularly checking error logs to planning for (and practicing) disaster recovery. In a recent Twitter chat we convened with a panel of SQL Server and database experts, we explored this wide array of activities, all aimed at ensuring the database runs optimally.
Our expert panel agreed that, first and foremost, database maintenance is not just about doing one thing, or running a set of scripts, but rather it’s a continuous, never-ending process, as guest host Argenis Fernandez summarized:
A robust database maintenance practice includes use of maintenance plans and custom scripts, all closely tied to business needs, a basic tenet echoed by many on our panel, including Paul Timmerman:
Use of maintenance plans and scripts may depend on the experience level of the DBA, but is likely also to be dependent on the size of the installation, as Karen Lopez noted:
When it comes to the one maintenance activity every DBA should be doing now, without fail, our panel agreed it’s in developing, and testing, a restoration strategy, Fernandez reiterated:
According to Steve Karam, it’s important to understand that a good disaster recovery plan includes backup strategy, business requirements and service level agreements (SLAs), and fallback measures for when things go wrong:
Finally, Chris Bell reminded all DBAs that, regardless of which plan or script they’re using, it’s important to truly undertand what and why:
Read the full transcript of Twitter chat about SQL Server maintenance
Read the full transcript now to learn all the insights about SQL Server maintenance from our panel of SQL Server and database performance experts, including: Argenis Fernandez (Database Engineer at SurveyMonkey, Microsoft Certified Master), Joey D’ Antoni (Solutions Architect and Anexinet), Chris Bell (Founder, WaterOx Consulting), Robert Davis (SQL Server 2008 Certified Master and Principal DBA at OuterWall), Steve Karam (Oracle ACE and Technical Manager at Delphix), Karen Lopez (SQL Server MVP and Sr. Project Manager / Architect at Infoadvisors), John Morehouse (Database Architect Engineer at Farm Credit Services of America), Paul Timmerman (Database Administrator at Hennepin County Medical Center and SQL Serve MVP), Thomas LaRock (SQL Server MCM and MVP, and Technical Evangelist at SolarWinds) and many more.
SWI_Database
4/25/14 1:01 AM
Here we go – Q1: What does the term “maintenance” mean? #datachat #sqlserver
DBArgenis
4/25/14 1:03 AM
Your lawn needs love. So does your database. #datachat
SWI_Database
4/25/14 1:03 AM
Where would you start? RT @DBArgenis: Your lawn needs love. So does your database. #datachat
SQLRockstar
4/25/14 1:04 AM
A1: To me, “maintenance” is everything you do to the database that allows it to perform at optimal levels. @SWI_Database #datachat
OracleAlchemist
4/25/14 1:04 AM
Maintenance: The activity that happens at 4AM on the day after you are on call and have late night production issues. #datachat
AirborneGeek
4/25/14 1:04 AM
For me, overseeding. RT @SWI_Database: Where would you start? RT @DBArgenis: Your lawn needs love. So does your database. #datachat
4/25/14 1:05 AM
@OracleAlchemist Is that the after thought or the under planned? #datachat
SoftwareHollis
4/25/14 1:05 AM
Data and Access Governance: Top 6 Areas to Make Sure You Are Covered http://t.co/AE1O9ZqGuB #iwork4dell #datachat
AirborneGeek
4/25/14 1:05 AM
@SQLRockstar So, would you consider query tuning “maintenance”? @SWI_Database #datachat
DBArgenis
4/25/14 1:05 AM
A1: Maintenance is not just what @SQLRockstar said. It’s also about making sure that you can recover in event of data loss-BACKUPS #datachat
OracleAlchemist
4/25/14 1:05 AM
@SWI_Database It can be a bit of both
To be honest, maintenance is a planned or unplanned activity to keep your environment sane. #datachat
jdanton
4/25/14 1:05 AM
@AirborneGeek @SQLRockstar @SWI_Database Not really. #datachat
m82labs
4/25/14 1:06 AM
@SQLRockstar @SWI_Database I like this answer, but I like to see the word pro-active in there as well. #datachat
DBArgenis
4/25/14 1:06 AM
@AirborneGeek @SQLRockstar @SWI_Database I actually do consider frequent tunning of offending code a good maintenance practice #datachat
SQLRockstar
4/25/14 1:06 AM
A1: So, anything that you can do (rebuild/reorg indexes, update stats, alter schema) to help avoid pert issues. @SWI_Database #datachat
tameraclark
4/25/14 1:06 AM
Databases need maintenance just like people. #datachat #sqlserver
sensware
4/25/14 1:07 AM
@AirborneGeek @SQLRockstar @SWI_Database I would
#datachat
CBellDBA
4/25/14 1:07 AM
#datachat a1: maintenance is as @SQLRockstar stated, but I think it includes planning for the future as well (documentation, etc).
DBArgenis
4/25/14 1:08 AM
A1: Maintenance on a database is not just a one time thing. It’s a continuous, never ending process. #datachat
AirborneGeek
4/25/14 1:08 AM
@DBArgenis @SQLRockstar @SWI_Database I think I could argue either way; first reflex is to say “no” but the proactive angle brings it in #datachat
jdanton
4/25/14 1:09 AM
@DBArgenis yes, +1000 #datachat
SWI_Database
4/25/14 1:09 AM
@CBellDBA @SQLRockstar One size fits all? proactive planning #datachat
DBArgenis
4/25/14 1:09 AM
A1: I’m a big fan of prevention. Do as much as you can to sleep well at night. That includes making sure your code is tuned. #datachat
SQLRockstar
4/25/14 1:09 AM
@DBArgenis I consider backups to be something ancillary to maintenance tasks, I know they all get lumped together. #datachat
DBArgenis
4/25/14 1:09 AM
Databases are code, and code must be maintained as well #datachat
AirborneGeek
4/25/14 1:10 AM
@SQLRockstar @DBArgenis Lots of grey around the line between maintenance and DR #datachat
SQLSteinar
4/25/14 1:10 AM
@SQLRockstar @SWI_Database #datachat What about db on SSD? Rebuild/reorg or not at all?
jdanton
4/25/14 1:10 AM
@AirborneGeek @SQLRockstar @DBArgenis huh? #datachat
DBArgenis
4/25/14 1:11 AM
@SQLSteinar @SQLRockstar @SWI_Database that’s a big “it depends”. Dissapointing, I know 🙂 #datachat
SWI_Database
4/25/14 1:11 AM
Any good resource / checklists you know for DBAs around maintenance planning – Share URLs please #datachat
CBellDBA
4/25/14 1:11 AM
@SWI_Database @SQLRockstar one size fits all doesn’t exist in the database world. #datachat
AirborneGeek
4/25/14 1:11 AM
@jdanton @SQLRockstar @DBArgenis That was in reference to Tom’s comment about backups being ancillary to maintenance #datachat
DBArgenis
4/25/14 1:11 AM
And, before anybody brings up the point, Maintenance is not just installing @olahallengren’s scripts. #datachat
mnDBA
4/25/14 1:11 AM
@SQLSteinar @SQLRockstar @SWI_Database @DBArgenis I say still worth it. Wasted IO is wasted IO. Cache bloat is cache bloat. #datachat
m82labs
4/25/14 1:12 AM
@DBArgenis @olahallengren #datachat – but it’s a start
🙂
DBArgenis
4/25/14 1:12 AM
Yes
A very good one RT @m82labs: @DBArgenis @olahallengren #datachat – but it’s a start
🙂
jdanton
4/25/14 1:12 AM
Is setting up agent alerts part of maintanance? #datachat
SQLSteinar
4/25/14 1:12 AM
@DBArgenis @olahallengren I am sure he will be dissapoint to hear that 😉 #datachat
DBArgenis
4/25/14 1:12 AM
@mnDBA @SQLSteinar @SQLRockstar @SWI_Database I absolutely agree. #datachat
DBArgenis
4/25/14 1:13 AM
@jdanton do you want to know when something goes wrong? #datachat
GEEQL
4/25/14 1:13 AM
@SWI_Database #datachat http://t.co/g0UFLtwNTY ? Not quite hands off maintenance, but dang close.
SQLSteinar
4/25/14 1:13 AM
@DBArgenis @mnDBA @SQLRockstar @SWI_Database I am concerned w SSD wearing out … #datachat
DBArgenis
4/25/14 1:14 AM
@SQLSteinar @mnDBA @SQLRockstar @SWI_Database there’s ways around SSD wearing out. AFAs manage this through data dedupe to minimize it #datachat
SWI_Database
4/25/14 1:14 AM
Q2: Who is responsible for deciding what (and when) maintenance tasks are performed? #datachat
datachick
4/25/14 1:15 AM
In talking maintenance: remember most people think about dev, support, & maintenance. Everything has to fit in 1 of those, usually #datachat
jdanton
4/25/14 1:15 AM
@SWI_Database Some combination of the business and the admin teams. #datachat
SQLRockstar
4/25/14 1:15 AM
RT @datachick: In talking maintenance: remember most people think about dev, support, & maintenance. Everything has to fit in 1 of those, u…
sensware
4/25/14 1:15 AM
@mnDBA @SQLSteinar @SQLRockstar @SWI_Database @DBArgenis get enterprise grade + bigger size #datachat
m82labs
4/25/14 1:15 AM
@SWI_Database #datachat business needs rule all. After that, the DBA.
datachick
4/25/14 1:15 AM
A2: The person(s) assigned the tasks #datachat
mnDBA
4/25/14 1:16 AM
@SWI_Database A2: Admin teams in conjunction with business/app owners. #datachat
SQLSteinar
4/25/14 1:16 AM
RT @DBArgenis: @SQLSteinar @mnDBA @SQLRockstar @SWI_Database there’s ways around SSD wearing out. AFAs manage this through data dedupe to minimiz…
DBArgenis
4/25/14 1:16 AM
A2: Ultimately the DBA, after gathering input from the Business around availability and performance impact #datachat
OracleAlchemist
4/25/14 1:16 AM
A2: Admin teams fulfilling business requirements. The business creates a framework that a good admin team builds upon. #datachat
SQLRockstar
4/25/14 1:16 AM
A2: The DBA decides the “what”, the business decides the “when”. @SWI_Database #datachat
mnDBA
4/25/14 1:17 AM
@sensware @SQLSteinar @SQLRockstar @SWI_Database @DBArgenis Agreed. I’ve yet to hit any SSD threshold. #FingersCrossed #datachat
CBellDBA
4/25/14 1:17 AM
@SWI_Database A2: Everyone. It should be a team effort to ensure maintenance meets all requirements. #datachat
OracleAlchemist
4/25/14 1:17 AM
Kind of related to Q2 of #datachat – DBA Team, Front and Center http://t.co/Wlo4LXdqxX
SQLSteinar
4/25/14 1:21 AM
RT @mnDBA: @sensware @SQLSteinar @SQLRockstar @SWI_Database @DBArgenis Agreed. I’ve yet to hit any SSD threshold. #FingersCrossed #datachat
SWI_Database
4/25/14 1:21 AM
Q3: Which do you prefer and why: maintenance plans or custom scripts? #datachat
jdanton
4/25/14 1:21 AM
@SWI_Database Ola. Mostly. #datachat
mnDBA
4/25/14 1:21 AM
@SWI_Database A3: Custom scripts, hands down. I need flexibility and MS can’t provide that for every env. #datachat
m82labs
4/25/14 1:22 AM
@SWI_Database #datachat A3: Custom scripts, because I like to know exactly what is happening. I like getting my hands dirty.
SQLRockstar
4/25/14 1:22 AM
A3: For a novice, use SQL maintenance plans. For senior DBAs, use scripts. @SWI_Database #datachat
SQLSteinar
4/25/14 1:22 AM
@jdanton @SWI_Database @olahallengren Always Ola, with some adjustments to defaults #datachat
DBArgenis
4/25/14 1:23 AM
A3: For a novice, just use Ola Hallengren’s scripts out of the box. For everything else, customize calls to Ola’s procs #datachat
CBellDBA
4/25/14 1:23 AM
@SWI_Database #datachat A3: whatever works best for the client to ensure they keep up with maintenance & understand why & how it works.
m82labs
4/25/14 1:23 AM
@SQLRockstar @SWI_Database #datachat even with all the great pre-packaged scripts out there?
DBArgenis
4/25/14 1:23 AM
A3: Anything but Shrink Database, people 🙂 #datachat
OracleAlchemist
4/25/14 1:24 AM
A3: I think of scripts as patches and maintenance as releases. One routinely corrects minor things, the other actively improves. #datachat
datachick
4/25/14 1:24 AM
#datachat Custom Scripts fit better for enterprises w/1000s servers, databases, instances. Config, Control, Version Not really novice vs pro
OracleAlchemist
4/25/14 1:25 AM
A3: However, scripts are highly useful IN maintenance when an enterprise architecture is the target. #datachat
DBArgenis
4/25/14 1:25 AM
A3: Ola’s scripts are so easy to use that they can’t really be called “custom”. They’re a prepackaged solution. They just work. #datachat
sql_handle
4/25/14 1:26 AM
@SWI_Database #datachat “maintenance” – maybe I missed it: review and adopt applicable os/db hotfixes, CUs, SPs, versions – and trace flags 🙂
jdanton
4/25/14 1:26 AM
@DBArgenis Don’t forget to change the default backup location. #datachat
DBArgenis
4/25/14 1:26 AM
@sql_handle great point, also part of proper maintenance #datachat
CBellDBA
4/25/14 1:27 AM
@DBArgenis how much is Ola paying you to plug his solutions tonight? 0_o #datachat
OracleAlchemist
4/25/14 1:28 AM
A3: My scheduled scripts are single-purpose Jr. DBAs, doing the tasks I’m too tired to do at 2AM. #datachat
SQLSteinar
4/25/14 1:28 AM
@sql_handle @SWI_Database Regarding trace flags, I maintain a looong list here http://t.co/2175HTDhjK #datachat
SWI_Database
4/25/14 1:30 AM
onto Q4: What maintenance items you would advise DBAs start doing immediately? #datachat
mnDBA
4/25/14 1:30 AM
Most excellent
RT @SQLSteinar: @sql_handle @SWI_Database Regarding trace flags, I maintain a looong list here http://t.co/2175HTDhjK #datachat
m82labs
4/25/14 1:31 AM
@SWI_Database #datachat A4: Index/statistics maintenance, and verifying your backups.
jdanton
4/25/14 1:31 AM
@SWI_Database A4: have a standard set of check scripts that all return to a central server for reporting. #datachat
mnDBA
4/25/14 1:31 AM
@SWI_Database A4: Test restores to validate SLA/RTO/RPO. Your job depends on it (or at least it should). #datachat
AirborneGeek
4/25/14 1:31 AM
@SWI_Database Backups, if not already being done. And if you consider backups to be a maintenance task 😉 #datachat
DBArgenis
4/25/14 1:32 AM
A4: Get a RESTORE strategy going, RIGHT NOW #datachat
OracleAlchemist
4/25/14 1:32 AM
A4: Backups. Yes, there are still those out there who don’t. #datachat
jdanton
4/25/14 1:32 AM
@SWI_Database Oh yes, test restores immediately. On a scheduled basis. #datachat
DBArgenis
4/25/14 1:33 AM
A4: Backups are absolutely worthless if you never restore them and test them. That must happen, always. #datachat
OracleAlchemist
4/25/14 1:33 AM
If anyone says “routine server restarts” to Q4 I’m going to flip my lid. #datachat
m82labs
4/25/14 1:33 AM
@SWI_Database #datachat A4: And if you are thrust into the DBA role by circumstance, DOCUMENT your existing backup/restore solution.
SQLRockstar
4/25/14 1:34 AM
A4: I’d advise updating stats on non-indexed columns. @SWI_Database #datachat
DBArgenis
4/25/14 1:35 AM
A4: Just as important as testing your backups: Consistency Checks. DBCC CHECKDB your databases, frequently. #datachat
OracleAlchemist
4/25/14 1:35 AM
Not testing your backup/DR plan? #Gamification to the rescue
Gamifying the DBA Experience http://t.co/a3epKzv7mF #datachat
jdanton
4/25/14 1:35 AM
@SQLRockstar @SWI_Database Oracle does that for you stats, starting with 11G. #datachat
CBellDBA
4/25/14 1:36 AM
@SWI_Database A4: Make sure you can restore backups & time to do. Check “default” settings. Verify security is appropriate. #datachat
DBABullDog
4/25/14 1:36 AM
@SWI_Database document and publish a patching schedule for SPs, CUs and Security Patching. #datachat
CBellDBA
4/25/14 1:37 AM
This 110% à @DBArgenis: A4: Backups are absolutely worthless if you never restore them and test them. That must happen, always. #datachat”
sensware
4/25/14 1:37 AM
@SWI_Database A4: setup alerts, tune config parameter #NotTheDefaults #datachat
SWI_Database
4/25/14 1:38 AM
Q5: Which is more important and why: backup strategy or recovery strategy? #datachat
sensware
4/25/14 1:39 AM
@SWI_Database A5: Recovery of course #datachat
datachick
4/25/14 1:39 AM
@SWI_Database No one needs backups. We only need recovers. #datachat
m82labs
4/25/14 1:39 AM
@SWI_Database #datachat A5: Chicken and egg situation. They are equally important. But above both of those is testing those strategies.
OracleAlchemist
4/25/14 1:40 AM
A5: Recovery strategy should include backup strategy, business requirements/SLAs, fallback measures, testing, enablement, etc. #datachat
DBABullDog
4/25/14 1:40 AM
@SWI_Database A4 also test your offsite backup strategy. Bring back tapes if need be ensure data can be recovered and then restored. #datachat
DBArgenis
4/25/14 1:40 AM
A5: A Recovery strategy is a runbook for a data loss scenario. A Backup strategy is a set of commands you schedule. #datachat
SQLRockstar
4/25/14 1:41 AM
A5: You can’t recover without backups, but you need to know when/how to backup. So…recovery strategy is more important @SWI_Database #datachat
sql_handle
4/25/14 1:41 AM
@SWI_Database #datachat A4 maint recommendation for ‘right now’: establish performance baseline for most important workloads
jdanton
4/25/14 1:41 AM
@SWI_Database A5: recovery strategy. But it’s complicated. #datachat
SQLRockstar
4/25/14 1:41 AM
RT @OracleAlchemist: A5: Recovery strategy should include backup strategy, business requirements/SLAs, fallback measures, testing, enableme…
GEEQL
4/25/14 1:41 AM
@DBABullDog @SWI_Database #datachat we just went through that and learned a lot. Definitely good to practice.
DBABullDog
4/25/14 1:41 AM
@SWI_Database A5 recovery strategy. Document recovery times so you can answer “how long will this take”? #datachat
DBArgenis
4/25/14 1:42 AM
@DBABullDog @SWI_Database yes
That goes in line with your business expectations for RTO. #datachat
SQLRockstar
4/25/14 1:44 AM
RT @DBArgenis: @DBABullDog @SWI_Database yes
That goes in line with your business expectations for RTO. #datachat
SWI_Database
4/25/14 1:45 AM
Before we roll our last question this evening, does anyone would like get answers from our experts? #datachat #maintenance #sqlserver
DBArgenis
4/25/14 1:46 AM
Ok people, time for AMA #datachat
DBArgenis
4/25/14 1:47 AM
Database maintenance related, of course 🙂 #datachat
jdanton
4/25/14 1:47 AM
@DBArgenis so let’s talk licensing. #datachat
OracleAlchemist
4/25/14 1:47 AM
@datachick @SWI_Database http://t.co/WNq2McCaeh%20 #datachat
m82labs
4/25/14 1:47 AM
@SWI_Database #datachat How do you handle OS patches/updates? In regards to how they may effect SQL.
DBArgenis
4/25/14 1:47 AM
@jdanton actually that is a really good point for maintenance, as you can perform some of it on secondaries. #datachat
jdanton
4/25/14 1:49 AM
@DBArgenis @DBArgenis but then you have to pay for those secondaries. #datachat
DBArgenis
4/25/14 1:49 AM
@m82labs we autopatch our dev/test SQL Servers so that they get updates automatically. Prod manually. #datachat
DBArgenis
4/25/14 1:49 AM
@jdanton yes, but the impact to the primary is diminished and if big enough that would justify the expense. #datachat
m82labs
4/25/14 1:50 AM
@DBArgenis #datachat Do you typically have a set period of time you let the updates “swim” on the dev servers before manually updating prod?
sensware
4/25/14 1:50 AM
@DBArgenis Is it true that you should not shrink tempdb? <ducks> #datachat
DBArgenis
4/25/14 1:50 AM
@m82labs yes, we don’t apply to prod anything that hasn’t been released for 3 weeks, unless something like heartbleed happens #datachat
DBArgenis
4/25/14 1:51 AM
@sensware yessir, shrinking tempdb can indeed cause corruption. #datachat
CBellDBA
4/25/14 1:52 AM
@DBArgenis What do you use to test new releases to ensure things don’t break, or does a 3 week grace period assume it is Ok? #Datachat
SQLRockstar
4/25/14 1:52 AM
We did them manually, and only SP level. Hotfixes were applied only when critical. @SWI_Database @m82labs #datachat
DBArgenis
4/25/14 1:52 AM
Random Q: How many of you routinely examine your ERRORLOG? That to me is also a maintenance task #datachat
jdanton
4/25/14 1:52 AM
@DBArgenis @sensware side question–does anyone have a pattern to cause said corruption? I know it happens. #datachat
rabryst
4/25/14 1:53 AM
@DBArgenis Once a week #datachat
DBArgenis
4/25/14 1:53 AM
@jdanton @sensware I can’t repro it on demand either. #datachat
datachick
4/25/14 1:53 AM
@DBArgenis I’m good. I don’t have errors <snort> #datachat
OracleAlchemist
4/25/14 1:53 AM
When someone asks what your recovery plan is: http://t.co/WNq2McCaeh%20 #datachat /cc @DBAReactions
GEEQL
4/25/14 1:54 AM
@DBArgenis #datachat I’m in a sampling of them a day. A lot of stuff surfaces in there that is like a canary in a coal mine.
sensware
4/25/14 1:54 AM
@jdanton @DBArgenis I would try while doing an online reindex… but it’s a crapshoot #datachat
CBellDBA
4/25/14 1:55 AM
@jdanton I only ever noticed uncontrolled growth of tempdb until it fills drive or space allocated. Otherwise tempdb works fine. #datachat
SWI_Database
4/25/14 1:55 AM
Q6: What are common mistakes made with regards to maintenance? (besides not doing any) #datachat
OracleAlchemist
4/25/14 1:55 AM
@DBArgenis @SQLRockstar I have people–err, scripts–that do that for me. But I still make sure to check on a regular basis. #datachat
SQLSteinar
4/25/14 1:55 AM
@DBArgenis I do #datachat
CBellDBA
4/25/14 1:55 AM
@SWI_Database Assuming that maintenance completed worked correctly. #datachat
OracleAlchemist
4/25/14 1:56 AM
A6: Not scheduling them according to your business’s change management requirements & UNDERESTIMATING TIME #datachat
datachick
4/25/14 1:56 AM
@SWI_Database Worse that not doing it: not verifying they are being done. #datachat
m82labs
4/25/14 1:56 AM
@SWI_Database #datachat A6: Trying to implement “blanket” solutions. e.g. Set FILL to 70 on all indexes.
DBArgenis
4/25/14 1:56 AM
A6: Assuming that notifications from your server work. I once had a CHECKDB job failing for a month before I discovered it. #datachat
SQLHA
4/25/14 1:57 AM
@SWI_Database @DBArgenis Assuming that a maintenance plan will cure cancer and substitute for lack of knowledge. #datachat
DBArgenis
4/25/14 1:57 AM
A6: So, learn from my mistake: query your servers for status frequently. #datachat
m82labs
4/25/14 1:57 AM
@SWI_Database #datachat A6: Not testing maintenance scripts/task like you would test any other code going to prod.
DBABullDog
4/25/14 1:57 AM
@SWI_Database A6 3rd party or native backups running while index maintenance is running. #datachat
jdanton
4/25/14 1:58 AM
A6: automated health checks that are external are a good thing. #datachat
CBellDBA
4/25/14 1:58 AM
@SWI_Database A6: Doing any maintenance people recommend without first learning & understanding what &why it does what it does. #datachat
SQLRockstar
4/25/14 1:58 AM
A6: Most common mistake would be assuming they are working properly without verifying. @SWI_Database #datachat
sql_handle
4/25/14 1:59 AM
#datachat A4 maintenance: server restarts & @oraclealchemist flipping his lid: what can I get for periodic failover/dr activation 🙂
jdanton
4/25/14 1:59 AM
@datachick @SWI_Database Don’t JUST #$%^Iing CLICK NEXT #datachat
DBArgenis
4/25/14 1:59 AM
MT (scotch fail) @datachick: #datachat @SWI_Database Assuming that clicking NEXT NEXT NEXT NEXT is a good plan.
OracleAlchemist
4/25/14 1:59 AM
Yeah, testing health on the same box is a mistake. RT @jdanton A6: automated health checks that are external are a good thing. #datachat
datachick
4/25/14 2:00 AM
@jdanton @SWI_Database Bbbbut all those choices represent vendor best practices, right? <no> #datachat
OracleAlchemist
4/25/14 2:01 AM
@jdanton @datachick @SWI_Database Yeah, you should click BACK at least once to make sure you got the path right. #datachat
sensware
4/25/14 2:01 AM
@datachick @jdanton @SWI_Database It’s a trap #datachat
DBArgenis
4/25/14 2:01 AM
@datachick @jdanton @SWI_Database I was told that they would least to the most uptime on the database. I laughed. #datachat
CBellDBA
4/25/14 2:01 AM
@datachick @jdanton @SWI_Database Defaults are usually De Fault of a lot of problems. #datachat
jdanton
4/25/14 2:01 AM
@OracleAlchemist @datachick @SWI_Database That would be no.. #datachat
GEEQL
4/25/14 2:01 AM
@datachick @jdanton @SWI_Database vendors can learn, too. Really. :-). #datachat
DBArgenis
4/25/14 2:01 AM
@datachick @jdanton @SWI_Database I was told that they would lead to the most uptime on the database. I laughed. #datachat
SQLRockstar
4/25/14 2:03 AM
.@datachick @jdanton @SWI_Database Depends on the vendor. #datachat
datachick
4/25/14 2:03 AM
@SQLRockstar @jdanton @SWI_Database No defaults represent best practices for all situations. #datachat
DBABullDog
4/25/14 2:04 AM
@SWI_Database A6 Not doing proper maintenance because it is a”Dev” environment. Tell a dev you lost 5 days worth of work. #datachat
sensware
4/25/14 2:04 AM
@CBellDBA @DBArgenis or “Hold ma’ beer and watch this” #datachat
DBArgenis
4/25/14 2:05 AM
@DBABullDog @SWI_Database YES Dev environments are Production environments for your developers. Treat them as such. #datachat
SWI_Database
4/25/14 2:05 AM
Well this was another awesome #datachat – Thank you everyone #datachat Special thanks to @DBArgenis @SQLRockstar
SQLHA
4/25/14 2:06 AM
@DBArgenis @DBABullDog @SWI_Database And don’t forget to have staging environments. IT needs a sandbox, too. #datachat
SQLRockstar
4/25/14 2:06 AM
A wise man once wrote: “A development server is a production server to a developer.” @DBABullDog @SWI_Database @DBArgenis #datachat
sensware
4/25/14 2:06 AM
@SQLRockstar @datachick @jdanton @SWI_Database Beware those that use the words *always* or *never* #datachat
OracleAlchemist
4/25/14 2:07 AM
Development/QA: It’s the new production. From “DBA, Grow Thyself” http://www.oraclealchemist.com/news/dba-grow-thyself-moving-and-shaking-in-the-era-of-data-dominance/#datachat
datachick
4/25/14 2:08 AM
#datachat In Prod: “wonder what this does?”
Leave a Reply