Two Steps Ahead

  • Comments posted to this topic are about the item Two Steps Ahead

  • Good article. The #5 internal qualities (besides technical skill set) I look for in DBA, Proactive is at the top of my list. 😀

    1, Proactve. Does he/she sit around and just babysit servers? Or do they proactively look for issues before they become issues? Are they always looking for ways to improve our systems or are they always outside on their cell phones all the time dealing with personal issues?

    2. Problem Solver. Can he/she attack and solve problems on their own? Or do they need constant assistance to address everyday issues? If I have to walk them through everything, then I can do it myself and that defeats the purpose of hiring another person.

    3. Commitment. Is he/she willing to do what it takes to get the job done? Or do they always have an excuse to be somewhere else? If they want a 40 hour 9-5 job then go work in a flower shop. This is not the business for them.

    4. Confidentiality. Since we deal with sensitive data (ie: salaries), alot can he/she keep things under their hat? Or are they a just company PA system? Mouthpieces cause companies and departments alot of trouble. I weed them out quick.

    5. Work-Oriented. I am looking for a person that comes to work every day ready to dig in to the issues at hand. I am not running a dating service or a social club. They are being paid to work, not spend all their time in the break room socializing. I have had to let a lot of good DBA's go in the past simply because their priorties at work were in the wrong place.

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • A disaster is an emergency you didn't anticipate.

    Good editorial. Anticipating and preventing problems is key to good DBA work.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Hi Steve,

    Regarding "I wrote that calculated data growth for all databases on an instance and then used that to calculate how many days would elapse before I ran out of space on the data drives." Would you be willing to share your solution? Just the query(s) would be ideal. I've spent hours trying to do this (data growth info) but can't get it how I want it.

    Your editoral inspired me to continue working on solutions to scan SQL instances and report back to me using SSRS reports. For example, I have a report that emails me daily a list of databases on an instance with the dates of the last FULL, DIFF, and LOG backups. The report will show stuff in Red based on our business rules and expectations for SQL Server backups. For example, if a FULL backup hasn't been done within 7 days, the database name is shown in Red. Just the other day on one servers, all the dates for the DIFF and LOG backups of each database was in Red, which clearly indicated a problem. Turns out our sys admin patched the server, rebooted it, but the SQL Agent wasn't restarted so backup jobs hadn't run for a day.

    Also, on my report is information form Ola Hallengren's CommandLog table. So, daily I receive a report via e-mail for each server that saves me time from manually going to each server to inspect stuff.

    Thanks again!

  • Nice! One of the guys who broke me into the IT business use to say "Expect the unexpected"! Very sage advice.

    Thanks

    M.

    Not all gray hairs are Dinosaurs!

  • The U.S. Submarine Service had all sorts of metrics as to what a "drip", "slow leak", "fast leak", and "flooding" constisted of (water in the "boat" is not a good thing). I boiled it all down back when I served and apply it to my current DBA work.

    "If you find it, it's a leak. If it finds you, it's flooding." 😉

    Be prepared. Be proactive.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I served in the United States Submarine Service and that is very true.:-D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • TravisDBA (10/26/2012)


    I served in the United States Submarine Service and that is very true.:-D

    Diesel, boomer, or fast attack? I served mostly on SSN 604 (USS Haddo) but also did a couple of runs on the Shark (Skipjack class) and the Parche (637 stretch hull)... all nuke attack boats.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • dstanger-666122 (10/25/2012)


    Hi Steve,

    Regarding "I wrote that calculated data growth for all databases on an instance and then used that to calculate how many days would elapse before I ran out of space on the data drives." Would you be willing to share your solution? Just the query(s) would be ideal. I've spent hours trying to do this (data growth info) but can't get it how I want it.

    Your editoral inspired me to continue working on solutions to scan SQL instances and report back to me using SSRS reports. For example, I have a report that emails me daily a list of databases on an instance with the dates of the last FULL, DIFF, and LOG backups. The report will show stuff in Red based on our business rules and expectations for SQL Server backups. For example, if a FULL backup hasn't been done within 7 days, the database name is shown in Red. Just the other day on one servers, all the dates for the DIFF and LOG backups of each database was in Red, which clearly indicated a problem. Turns out our sys admin patched the server, rebooted it, but the SQL Agent wasn't restarted so backup jobs hadn't run for a day.

    Also, on my report is information form Ola Hallengren's CommandLog table. So, daily I receive a report via e-mail for each server that saves me time from manually going to each server to inspect stuff.

    Thanks again!

    Thanks.

    On the solution, I was looking for this recently. I think I lost the code in a few job changes, and I've been working on something for SQL Monitor, but haven't devoted a lot of time to testing. Really it means calculating growth across days to get a backup size, doubling it (I ususally want 2 days) and then dividing by free space. I think I used to do this in a few stages as a proc, not really a nice query, but I'm trying to get a good query that runs in one step for the Red Gate tool.

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply