TSQL2sDay was started by Adam Machanic (b | t). This is my first TSQL2sDay blog. This month’s TSQL2sDay is hosted by Koen Verbeeck (b | t) about the changing times.
The initial days
Almost nine years back when I started my career in 2008, I came out of college straight into a DBA role. We were three graduates and three senior DBAs who started supporting four clients in a newly formed team. In the first two years on that job I have seen the services and support as a primary DBA and shared between other few clients. It was challenging as we built few automated scripts and alerts. Soon we realised that we have cut down our work and had to find more work to keep ourselves busy. This is good for us, but not for the client as they see that they are paying for the time spent and not the expertise in building the automation. We still kept the clients happy with more improvements and few other projects.
Then I moved to Microsoft as a Support Engineer. Yes, I was the part of the team who was handling your cases raised for SQL Server with Microsoft. It was a short run for nine months when I joined one of my clients from my first company. It was because of the value that I would add there building a new team. I wanted to do so many projects there which was not approved as a vendor. As a direct employee in the company the influence was great. Unfortunately, they handed over their own team to another vendor. Left with no option I joined a financial services company.
Beyond DBA – Infra DBA
Till then I always looked at a DBA role as a support role. I then realised what a project mean to a DBA. Things changed as soon as I realised that all the DBA work was already automated. Then what do I do? You will be an Infra DBA – a what DBA? Yes, an Infra DBA. I will work closely with the system administrators and the application guys. I will build and solve problems beyond SQL Server which will indirectly fix issues with SQL Server.
This is where I started working on consolidation projects, capacity planning, building HA and DR solutions using SAN replication and SAN Snapshots, building read only instances and implementing load balancer to off load read workload at the database level. It was essential, to learn and understand how the underlying hardware and overlying application layer works to build these solutions.
Magic Cloud
I moved to Australia, and then came the Cloud. The magic word where everyone wants to move and very few know how. And the very big question, how will it affect my DBA job? I was excited that I can work on migrations to Cloud. But answering the fears of organisations about the future of their employees is a challenge. Fine, it is not as simple as you think. The notion of move to cloud and it all works fine is, in many cases, not true.
If you ever heard a story at a non-DBA shop – add more hardware when you see performance issues – that is a horror story for a DBA’s ears. When you move to Cloud and after few performance issues, when you are suggested to increase the resources to improve performance, it is a similar story. Moving to the cloud doesn’t mean you can lose the DBAs. It is like automating all DBA tasks, but still having a DBA to do more innovative work to improve the quality of your systems.
Learn, Innovate, Prosper
As a DBA, you will need to upgrade your skills. If you were running health checks every day and fixing regular issues and solving tickets, your job was at stake five years ago. You are lucky that you are still having a job. The only thing constant is change. It is never late to start learning and it is always early to stop learning. So Learn, Innovate, Prosper.
For thirty years, https://xanaxbest.com has been used in constant practical work. The system of long-term therapy and its possible complications occupy the minds of the best specialists of the country.
Happy Learning,
Manu
Like us on FaceBook | Join the fastest growing SQL Server group on FaceBook |
Follow me on Twitter | Follow me on FaceBook
