January 3, 2018 at 4:52 pm
For lack of a better category, I'll just ask right here - Please share what your typical day is like as a DBA?
Thanks.
January 3, 2018 at 8:10 pm
Heh...
Some days it's "Veni, vidi, vici".
Other days it's "Veni, vidi, W-T-F !!!???"
This and your other question (so far) seem to be "survey" questions. What is the purpose of your questions?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2018 at 8:28 pm
I will leave the booking writing to others. Just being bored at work and wonder how other DBA's fill their day.
Of course, I would like to know how other DBA's manage large number of instances, whether it is possible to have a standard approach that we can establish and share...
January 4, 2018 at 4:07 am
I'm not a DBA.
I'm a Senior Data Janitor. I spend most of my days dealing with ETL, ETL processes, programming, project managment, automation and people that neither understand data or computers. Very occasionally I do DBA or SysAdmin tasks because we don't have enough people or resources and I'm too dumb to say "No".
January 4, 2018 at 5:56 am
The majority of my days tend to be not-busy. I'm what most would term a "production" DBA, so it falls on me to make sure the servers are running OK, the OS and SQL is patched, help the devs and app-owners occasionally with troubleshooting problems, checking that backups ran successfully (even though I don't {currently} control the backups,) and generally trying to stay on top of what's coming up in terms of updates that might bite my servers (the Intel CPU bug that's come up recently is a good example.)
Once every quarter, I need to apply our organizations current Security Technical Implementation Guideline (STIG,) although for about the last year that's been little more than "nothing other than wording changes." Plus, by getting this done when a server is initially stood up, well, then it's just find the checks that have changed, does the change require me to do anything or did they just shuffle around the wording, and apply or make a note.
Every couple of years, we get mandated to migrate to a new OS (based on when MS ends support, so we just went from Server 2008R2 to Server 2012R2,) and typically at that time I'll make the jump to the current version of SQL (we just went from SQL 2008R2 to SQL 2014, 2017 wasn't released when I started.) So those are always a fun, busy couple months.
What with some issues getting tools on the devs PCs, I've started helping out some with SSIS packages that people need, which is actually kind of fun.
January 4, 2018 at 5:59 am
RandomStream - Wednesday, January 3, 2018 8:28 PMI will leave the booking writing to others. Just being bored at work and wonder how other DBA's fill their day.Of course, I would like to know how other DBA's manage large number of instances, whether it is possible to have a standard approach that we can establish and share...
In that case, here's a typical day for me...
First, I refuse to be bored. That makes for a not-so-fun job. To be honest, work is rather fun because of the attitude that I've developed. I don't have a large number of instances to work on because we've rather consolidated a lot of things onto just several servers and we don't have a huge number of people connecting (usually just a little over 400 connections to the "big server" at one time) so I can't help you there although some of the things I do could be applied to larger server farms.
I'm a bit of a night owl but I have to be up for the daily scrum at 9AM. A little after 8AM, during morning coffee, I login remotely and check the morning reports (which I wrote myself) for jobs that may have failed overnight. If any have failed (and it's a very rare thing), I check the error messages and any logs the jobs may have produced and send emails out to the owners of the jobs (all in IT) with what the failure was and any suggestions I may have due to esoteric knowledge even though they receive the same email. It's a color coded report and it usually takes just several seconds for the 6 main servers. Most importantly, I check to make sure that the backups had no failures (2 lines on each report) and that the nightly test-restore for the "big boy" worked correctly. If a job does appear as failed, there's a lot of data for each job on the report that helps with troubleshooting but I still have to check the logs. Like I said, it's very rare that there's a failure. If there is a failure that I can help with, then I know what a part of my morning will look like.
Then I check the "Enterprise Disk Status" report (also wrote that). It checks 285 "servers", most of which are not SQL Servers, for anything that looks out of the ordinary insofar as free-space or dirty disks or being able to access any given box (is the box up?). Again, if something goes haywire here, I know what a part of my morning will look like.
Then I check the big server a bit more closely. I check PerfMon to see how it's running before "the crowd" starts hitting it for real at 9 and I check the email folder that has any alerts for blocking and high CPU usage just to make sure that nothing went crazy during the major nightly runs that we do. Part of the checks that start with Perfmon is that I have baselines that I've "learned" and copied and if something doesn't look right, I check to see "whats runnining" (another proc I wrote) to see if someone may have had to do a rerun from a system that does a lot of runs using a different scheduling system (which I hate because I have no visibility of that).
Then I do a check of what the "worst queries" (another proc I wrote) running overnight were to see if anything changed. I may grab the included execution plan or two from that (it's checks by CPU, Reads, Writes, Duration, and Counts) if something seems a bit odd, which would also define a part of my morning if something did look odd.
Since the system handles most of the GUI stuff AND the big nightly and daily batch runs, I can tell by "feel", whether or not I need to "nuke the system" with a DBCC FREEPROCCACHE to get over any possible bad form of parameter sniffing (sometimes happens because it some huge runs over night and those runs aren't necessarily "cache-conducive" to what the GUI expects. Contrary to popular belief, it's not actually a huge evolution to do a DBCC FRRPROCCACHE on a system (it recovers VERY quickly) but your mileage may vary.
Then, at 9AM, I dial in to participate in the morning scrum. I always go last (let's other people describe any problems that I might be able to help with or have knowledge of) and describe the expected "here's what I did yesterday, here's what I'm doing today" and,. if necessary, "here's what I need help with (which is pretty rare) where I also provide a verbal reminder of the emails I may have sent out about jobs.
Then I take a shower and go to work (I've got a 12 minute commute time). After that, just about anything goes.
I do a shedload of peer reviews for the front end Developers (great bunch of folks that "get it", especially when it comes to SQL Server performance and resource usage). The peer reviews used to take a long time because I used peer reviews as a time to mentor folks in SQL Server. We don't have a high turnover rate so I've needed to do less mentoring in the last year but still do so when necessary. They know it's "not optional" when it happens and are happy to learn something new or different because they get to brag about performance fixes they may have made on their scrum and I brag about them, as well.
I work on the "DBA Task List" that the Dev Manager puts here requests for peer reviews and deployments on an tackle those usually in the morning. Of course, there's walkup questions that I help the Developers and others (like the Infrastructure Team, the Data Architect Team, etc, etc) with throughout the day and I almost never push them off. Because of the mentoring I've done, they don't usually have many questions anymore but, when they do, it's a good one and I'm happy to help them and they're happy to have the help. It sometimes keeps them from having to do hours of research and possibly from coming to a bad conclusion.
Then I turn to my projects and there's a ton of long term stuff (that I've determined need to be worked on). For example, I've found a way to determine which statistics on some of the Terra-Byte large databases are actually being used and the long term experiment is to make sure I'm right and so check my runs on that, do any tweaking, etc. I've also determined that indexes usually don't need any kind of maintenance (and that most people are actually doing it wrong) but have found some exceptions to the rule and am developing a new system for detection and handling of those. I've got several such projects that I'm working on. I may have also been given some assignments by my boss, the Enterprise Architect, such as helping with concepts and code on a major rewrite the rest of his team is doing, creating "Loan Migrations" for bank mergers or system changes, or writing code to replace or optimize poorly performing code/indexes that I may have found during my daily checks. I also work with his on-site contractors.
Not having a shedload of systems (due to some serious consolidation) to monitor is actually a double edged sword... although I have CPU, Blocking, and other alerts setup, I keep a copy of PerfMon running on an RDC to each production system (not the load on the system that most think and is critical that I already have a session established if something goes haywire) and will occasion flip over to check them especially if I get more than 1 alert from a system. Of course, if I see something odd, I'll check it out using the stored procedures that I wrote to ("whats running", etc).
Depending on the day, there may be a lot of other ad hoc stuff that I have to do.
In the evening, I'll do any deployments that couldn't be done due to contention during the day and that's when I can bear down on some of my stuff that also needs to be done after hours. Of course, sometimes, it makes for a long night. And, of course, since working with SQL Server is kind of a hobby and not just a job, I'll cruise this site for ideas and help where I can. A lot of times, I'll end up writing something to answer a question (or seeing someone else's answer) that actually has some application at work.
There are some times that I have a half hour before a meeting and it makes no sense to ramp up on working on one of my or other projects and so I'll spend a little time reading Books Online about something that I'd seen the previous evening on this site or something that I'm just curious about. I'm never bored with the job. In the very rare cases where there's little to nothing to day, I'll make the time to learn or try something new because, as long as I've been doing all of this, there's always something new to learn or some "Eureka" moment to be had, especially in the area of performance of code.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 5, 2018 at 11:35 am
My ETL is running.
But realistically mostly my day(usually weeks/months) is goal oriented not metric oriented.
January 5, 2018 at 12:00 pm
I'm in an environment where the core of the business relies on leased software solutions. That means I am not allowed to do any creative stuff at all apart from maintaining HA and DR and index maintenance.
All SQL Server agent jobs have a notification steps for success and failure so I only need to do a cursory check from time to time. I have also put in place about 25 alerts watching critical error conditions.
On each instance, I set up a job that gathers server vital information such as space, latency, config changes, critical entries in errorlog, memory dumps etc at 60 min interval to store in a set of what I call Server-Vital tables. A second job would pull together everything in html format twice a day and email me. It is mostly for quick reference and record keeping.
On a sentry box, I have a custom script that watches the Server-Vital tables at a 15-min interval. This script is central to my monitoring. It analyses the server vitals and notify me of things out of ordinary. If nothing is found, it sends an reassuring message.
All as far as monitoring goes, I rely on my phone only. I spend the rest of my time at work on exploring performance tuning and security-related topics. That's why I'm here.
January 5, 2018 at 1:33 pm
I fall into the Generalist category of DBAs, meaning I'm involved with setup, security, and maintenance of the SQL Server instances, as well as assisting developers in tuning queries, doing ETL, and indexing. I don't manage a large number of instances, only 13, but I do keep a monitoring program open during the workday to keep an eye on performance of the various servers.
Unfortunately a lot of my day ends up being interrupt driven. I view my work as a stack of queues. As new requests come in, I try to quickly interpret the severity of the situation based on the environment (production, testing, development), how many people are affected (single user, single department, the whole company), and if there is an adequate workaround for their problem. If the queue of that severity already exists in my head, I add this request to the end, if not I pop a new queue onto the stack in the appropriate severity order for this request.
January 5, 2018 at 2:09 pm
RandomStream - Friday, January 5, 2018 12:00 PMI'm in an environment where the core of the business relies on leased software solutions. That means I am not allowed to do any creative stuff at all apart from maintaining HA and DR and index maintenance.All SQL Server agent jobs have a notification steps for success and failure so I only need to do a cursory check from time to time. I have also put in place about 25 alerts watching critical error conditions.
On each instance, I set up a job that gathers server vital information such as space, latency, config changes, critical entries in errorlog, memory dumps etc at 60 min interval to store in a set of what I call Server-Vital tables. A second job would pull together everything in html format twice a day and email me. It is mostly for quick reference and record keeping.
On a sentry box, I have a custom script that watches the Server-Vital tables at a 15-min interval. This script is central to my monitoring. It analyses the server vitals and notify me of things out of ordinary. If nothing is found, it sends an reassuring message.
All as far as monitoring goes, I rely on my phone only. I spend the rest of my time at work on exploring performance tuning and security-related topics. That's why I'm here.
Now I understand why you say you're bored.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2018 at 12:56 pm
RandomStream - Wednesday, January 3, 2018 8:28 PMI will leave the booking writing to others. Just being bored at work and wonder how other DBA's fill their day.Of course, I would like to know how other DBA's manage large number of instances, whether it is possible to have a standard approach that we can establish and share...
If you are bored at work, then you are not really a DBA!
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
January 10, 2018 at 12:58 pm
Michael L John - Wednesday, January 10, 2018 12:56 PMRandomStream - Wednesday, January 3, 2018 8:28 PMI will leave the booking writing to others. Just being bored at work and wonder how other DBA's fill their day.Of course, I would like to know how other DBA's manage large number of instances, whether it is possible to have a standard approach that we can establish and share...
If you are bored at work, then you are not really a DBA!
I know I am, but a lazy one.
January 10, 2018 at 4:09 pm
RandomStream - Wednesday, January 10, 2018 12:58 PMMichael L John - Wednesday, January 10, 2018 12:56 PMRandomStream - Wednesday, January 3, 2018 8:28 PMI will leave the booking writing to others. Just being bored at work and wonder how other DBA's fill their day.Of course, I would like to know how other DBA's manage large number of instances, whether it is possible to have a standard approach that we can establish and share...
If you are bored at work, then you are not really a DBA!
I know I am, but a lazy one.
Heh... being a "lazy" DBA might be the sign that you're a really good DBA and that you're bored because you've go everything mostly automated and under control.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2018 at 6:36 am
I'm a data architect. I work primarily in the data science division where most of my days entail supporting both general and deep analysis of large datasets upwards into the millions to billions of records.
Typical days may include just following up on whatever burning project I'm working on to keeping an eye on the data platforms I built to support the business. This is a good mix of both dev and typical DBA tasks on top of management tasks of the team. I don't have a large team, so I'm more hands on than more sit back and manage the team or direct the dev/management of the data infrastructure. Ideally, I'm wearing all hats and expected to see and direct the big picture.
I have a lot more freedom in what I do than most. This means, I am also typically involved in a lot of new product ideas and POC's that may include new ways of analyzing data to X hot new data tool. This is because I'm not ideally supporting a big enterprise application, but instead supporting a data playground where we are exploring and building new data products in the form of complex analytical reporting. Therefore, I spend most of my time in very large denormalized datasets that are often hard to maintain due to the size and the changing models.
Some of the things I enjoy the most is working in Python with SQL Server. I love to build applications that interact with data such as data connectors or machine learning. I also like building and maintaining data warehouses that support large datasets where I can dive into data modeling, complex ETL development, and other areas to make it shine.
Due to all of this, I doubt I will ever work as a traditional DBA supporting a single product. I will likely always work in BI or data science or enterprise reporting until I retire of old age or find something else to do.
January 11, 2018 at 8:21 am
Jeff Moden - Wednesday, January 10, 2018 4:09 PMHeh... being a "lazy" DBA might be the sign that you're a really good DBA and that you're bored because you've go everything mostly automated and under control.
I worked really hard to become a lazy DBA, but of course other people always find things for me to do to fill my time. 😉
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply