3 Ways to Lead an Accidental DBA
•Download as PPTX, PDF•
1 like•112 views
In this presentation, we’ll explore the Accidental DBA. Oracle DBA Team Lead and expert, Steve Thompson’s presentation from Kscope19 takes on the different ways to lead an Accidental DBA. The presentation explores: What is an Accidental DBA, and what scenarios create an Accidental DBA? Why it’s important to evaluate skill gaps, risks and benefits and plan for them. Why companies should invest in the training.
Recommended
Recommended
More Related Content
Similar to 3 Ways to Lead an Accidental DBA
Similar to 3 Ways to Lead an Accidental DBA (20)
More from Datavail
More from Datavail (20)
Recently uploaded
Recently uploaded (20)
3 Ways to Lead an Accidental DBA
- 2. 3 Ways to Lead an Accidental DBA Steve Thompson Team Manager – Oracle Database Practice Datavail
- 4. www.datavail.com 4 What is an Accidental DBA?
- 5. www.datavail.com 5 How Does This Happen? Loss of current DBA staff Application purchase Home grown application
- 6. Who am I? 20 years as a DBA in various roles Front line Lead Manager
- 7. www.datavail.com 7 Why Is This Important? Reduces Stress Risk Learning Curve Most of us spend too much time on what is urgent and not enough time on what is important. Stephen R. Covey
- 8. www.datavail.com 9 Why Is This Important? Has a situation like this ever happened to you?
- 9. www.datavail.com 10 Evaluate Starting Point Existing skill set, how does it translate? Existing resources that can help Risk vs Benefits Evaluate potential outcomes Don’t waste your time
- 10. www.datavail.com 11 Making a Plan Core Competencies Backup and Recovery Security General Administration Disaster Recovery Performance Tuning Maintenance Database options and licensing
- 11. www.datavail.com 12 Making a Plan Create a Framework Establish realistic timelines Milestones Review Goals are good for setting a direction, but systems are best for making progress. James Clear, Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones
- 12. www.datavail.com 13 Making a Plan Establish Expectations Time spent learning Precautions Testing Filling in the gaps
- 13. www.datavail.com 14 Making a Plan Create a Knowledge Base Processes and Procedures Business SLAs Document the environment
- 14. www.datavail.com 15 Making a Plan Internal Resources Existing DBAs Developers/Sys Admins
- 15. www.datavail.com 16 Investing in Training Speed Expertise Best Practices CFO: What happens if we train them and they leave? CEO: What happens if we don’t and they stay?
- 16. www.datavail.com 17 Investing in Training Consider your training options: Availability Training providers Other training alternatives
- 17. www.datavail.com 18 Investing in Training Creating a Sandbox Virtual Box VM Existing hardware
- 18. Resources Recommended resources for the Accidental DBA https://oracle-base.com/ https://support.oracle.com https://blogs.oracle.com/ https://asktom.oracle.com http://oaktable.net/
- 19. Preventing Downtime Establish Emergency Procedures Documentation Sandbox practice Paid support Break Glass - contacts
- 20. www.datavail.com 21 One More Thing… There are no bad teams, only bad leaders. Jocko Willink, Extreme Ownership: How U.S. Navy SEALs Lead and Win
- 21. Questions?
- 22. Thank you
Editor's Notes
- Datavail provides a broad range of services in support of databases, analytics, and applications and specializes in Oracle, Oracle E-Business Suite, OBIEE and OBIA, Hyperion, Microsoft SQL Server, MySQL, MongoDB, DB2 and SharePoint. Datavail is a leading provider of data integration and database administration services in North America, offering 24×7 managed database, applications, and BI/DW services, design, architecture, and consulting. With more than 1,000 professionals in four countries, Datavail offers deep technical expertise in a flexible, agile engagement model that focuses on customer success. Founded in 2007, Datavail is based in Broomfield, Colorado and supports enterprise clients located worldwide.
- How am I defining an Accidental DBA? Someone who is tasked with the responsibility of a DBA, but doesn’t have that skill set or background. Typically you might see an application developer or systems administrator who has been given this responsibility. Perhaps they have volunteered to take on this new role, possibly this is a side role to their normal job duties. I also see it is a DBA that is now supporting a different database system than what they have experience with, an Oracle DBA supporting MongoDB for example. This presentation is primarily focused on Oracle, but it should translate fairly easily to other databases as well.
- Could be due to the resignation or loss of current DBA. Purchase of an Application package that requires a database back end. The development of a home grown application that uses a database… a lot of developers become DBAs this way.
- Story Time: To give a little background about who I am. About 20 years ago, I got my first job out of college doing desktop support and systems administration for a small division of an insurance company. There were 3 others on my team as well as a couple of Oracle DBAs who all reported to the same manager. Approximately a year into this job, both of our DBAs handed in their notices within about a day of each other. The manager gathered me and the other SAs together to let us know what was going on. You could definitely feel a bit of panic in the room, as we weren't sure how we would be able to replace both DBAs in such a short amount of time. For some reason, during that meeting, I decided that I was going to become a DBA and I volunteered to take over one of those open positions. I'm still not quite sure why I did this, as up to that point I had no desire to become a DBA, my entire plan coming out of college was to become a network engineer and that is what I primarily studied in school. The entire concept of databases felt a bit foreign to me but I thought I could figure things out along the way. So you could say that I was an accidental DBA. But I was very fortunate, our Senior DBA had a change of heart and decided to stay on board. This gave me an opportunity to learn at a much more relaxed pace, without the fear of making a big mistake due to my inexperience as I had someone to lean on. But, not everyone is so fortunate to be in that position and that's what I wanted to talk about today. What to do with an accidental DBA, how do you lead him or her into competency and why is this important. In my time as a Database Administrator, Team Lead and DBA manager I've come across many accidental DBAs. And in my current role, I help support many individuals who never planned on becoming one. And one thing that I’ve learned is that, far and away the ones that were more successful were those who had managers that set a plan for them to get them where they needed to be, to become a competent database administrator.
- Stress – the DBA feels on getting up to speed – the customer who is concerned they don’t have a competent resource supporting them. Risk – that something will go wrong Learning curve – getting your DBA up to speed as quickly as possible
- Having a plan to lead an accidental DBA, increases the trust that you have not only with the new DBA but with the business as well. The DBA knows that you have a plan to get him or her ready and capable as soon as possible. And the business knows that you’re taking their needs seriously by getting them a competent resource to manage their databases.
- Can you think of a time when you were given a responsibility that you weren't quite sure you had the background to handle? - Stress of trying to get up to speed - Not knowing what you don't know Maybe you were at once an accidental DBA You can understand the stress this type of situation causes
- First things first, where is your DBA starting from…be honest. What skills are being brought to the table – in general - A Sys Admin should have a good understanding of - monitoring system performance - security and roles - installing software A Developer may have a good understanding of How to formulate queries How these queries could affect the database …or, may just be quicker to pick up on these topics Are there existing resources that can help take the load off of your accidental DBA as they get acclimated to their new role? - Storage Admins - Developers w/ SQL knowledge - System Administrators - DBA from a different team? Can help evaluate environment to make sure the basic needs are met (e.g. backups) Risk vs Benefits – weighing out what’s important Determine what you’re risking by not having an experienced DBA How important is this data to the business? i.e. How much money does it cost the business if the database is down, for an hour, a day, a week. Gardner estimates the average cost of an hour of downtime is $300k per hour What would happen if there was an outage? Cost factor of bringing on a DBA, do you need a full time DBA? Evaluate the potential outcomes based on your starting point How likely is it that you have on your hands a potential rock star DBA vs someone who really has no interest in taking on this responsibility or learning new things. Self motivated Quick learner Deliberate and careful Takes ownership Can handle stress If you have a choice…don’t waste your time getting someone up to speed if they have no desire to be a DBA. I recall working with one SQL DBA who was tasked with taking over Oracle duties after the Oracle DBA left. The customer didn’t want to or couldn’t spend money on bringing in an Oracle person. The problem was this DBA had no interest in learning Oracle or Linux and was very hesitant to do any work. This would be a good example of someone who you might not want to try and make an Oracle DBA at least.
- Core competencies – Your accidental DBA will need to come up to speed in several areas of administration to make sure the environment is safe, secure and optimal. Backup and Recovery Regular backups are obviously important, but it’s critical to test recovery. Testing recovery, proves that your backups are good and that your DBA knows how to restore the database. Ideally, recovery testing should be done on regular intervals, e.g. monthly or quarterly. Security Your DBA should know how users and roles work, how to provide grants and what those grants can do. How to view what users have General Administration Starting/Stopping the database and listener. Knowing where important logs are located: alert log, listener log, trace files, etc. Know how tnsnames.ora works for client connections Performance Tuning AWR/Statspack OEM 3rd party tools Maintenance Patching Upgrades What options have been enabled for the database – are they licensed? Partitioning RAC Compression Encryption Knowledge of the options are necessary, but finding out if they’ve been licensed appropriately would likely fall onto a managers shoulders.
- Create the framework that you will use to get your DBA up to speed. Understand that it will take time to become more comfortable and become competent Establish milestones at regular intervals It not only helps to track progress, but you can review to see how far along the DBA has come Can create either a project plan or track through a ticketing system like Jira, Cherwell or ServiceNow Review these milestones and progress on a regular basis
- It will likely take quite a bit of time for your DBA to become experienced and competent, they should know what the expectations are for them to get there as quickly as possible. Time during work hours they can spend learning and studying. What are the rules about making changes to the databases. Is change control required for production changes Test and Dev environments – or hopefully a completely isolated database SLAs for database issues and requests Filling in the gaps understand short-comings and work on a plan to overcome them For example, maybe they just are struggling with understanding users and roles. What are some resources they can use to get a better understanding. Manage the businesses expectations as well. They need to understand that it will take some time due to the steep learning curve and broad range of areas. Business will need to be engaged on creating reasonable SLAs too.
- Creating a documentation library or knowledge base helps to have a reference to handle the various tasks required to support the business. This should include things like processes and procedures for handling various tasks or emergencies. Checklists can be a handy tool to make it easier to remember important steps that need to be performed. SLAs should be documented as well, in order to make sure work being performed is in alignment with the business needs. This helps with prioritization when multiple requests are waiting resolution. SLAs should cover everything from daily type tasks like user creation requests to emergencies like a database outage.
- In some companies IT resources are split across different divisions or departments. Is it possible that there are experienced DBAs available elsewhere in your company that you can leverage temporarily while your DBA is learning the ropes? Perhaps there are some duties that can be shared with other members of the IT staff. Depending on the background and experience of your accidental DBA, it might make sense to engage system administrators to assist with performance of the database servers or developers to assist with queries.
- Training seems like the first line item slashed when budgeting, but I can't emphasize enough on how beneficial it can be especially in this type of situation. The advantages of training help in several key areas: Speed – How quickly and efficiently your dba learns. Expertise– the knowledge and confidence that they have the ability to manage the databases. Learn best practices – to make sure the database environments are setup correctly
- What are some of the options to consider when determining what kind of training investment to make? Availability – online has more options usually has more availability and flexibility, lower costs Classroom might be harder to find and be more expensive, but it has a tendency to be more efficient and focused in a classroom setting. Less of a chance to get distracted. Vendor training – might have more confidence in vendor training, but 3rd party training can be less expensive. Online – self-paced courses can be beneficial, can be used as time allows but not as focused – real work can get in the way.
- Now that you have invested in training, your accidental DBA needs a place to test out their skills. It’s important that they can have a safe place to experiment and gain confidence in what they’re doing. The ability to practice gives them the skills necessary to handle both standard administrative tasks, but also what to do in an emergency. Your accidental DBA should have access to a sandbox environment, an area that isn’t used for other testing or development. That way if something goes wrong with the database, other teams aren’t effected by the outage. Options for creating this type of environment are using things like Oracle’s Virtual Box software or another type of VM. Perhaps there is some old, unused server that could be setup as a DBA testing environment.
- So what happens in an emergency situation, where you have a critical database down? This is why you invest in training, create a testing area of the dba and document processes and procedures. All types of recovery scenarios should be tested and documented so that these situations can be handled relatively gracefully. Corruption loss of datafile or controlfile Standby failover All the nuances of your environment should be well known, e.g. backup locations, required logins, emergency contacts. Assuming you have database support from the vendor, then support contacts and any logins should be known and documents as they should be engaged as soon as possible. But what if you didn’t have the time to implement all of the necessary pieces before an emergency happened and your DBA just isn’t quite ready to be able to resolve the problem. It would be a good idea to have the contact information handy of a trusted DBA contractor or managed services organization.
- Leading an accidental DBA requires a team effort. It requires buy-in from the DBA, it requires patience and understanding from the business and it requires leadership from management. Leadership will help determine the best course of action and to put into place whatever is necessary for your accidental DBA to become successful and for your data to be safe and secure.