May 11, 2020 at 12:00 am
Comments posted to this topic are about the item What does the Future DBA Do?
May 11, 2020 at 2:58 pm
I'm working with a company that's at the beginning of a migration to the cloud and have been in close contact with the DBA at another company that's completed the migration. For the 1st company, everyone is excited about the "Database as a Service". I guess a lot of people just don't understand the capabilities you may be giving up. As for the learning of non-relational databases (especially if some form of MPP is involved), it's amazing how much time, money, and effort people are willing to put into making such a leap from current systems to systems that they know nothing about except the marketing hype and a lot of hear-say (sometime more correctly pronounced as "heresy" :D). If they spent half the time learning how to better use what they already have, there's be a whole lot of time, money, effort, and crazy errors avoided. For the latter company, it's amazing what they gave up. There RPO went from a max of 15 minutes to as much as a week and their RTO went from however long it takes to pull off a restore to more than a week.
Be careful... it might not be the "cloud" you're moving to... it might be a bad case of "smoke'n'mirrors".
As for what the "Future DBA" will do? Same as always... save the proverbial universe from the denizens that created it. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
May 11, 2020 at 3:18 pm
I am no longer a DBA. Depending on how you define the role I probably never was.
I think my role has mainly be that of a data engineer with a deep specialism in SQL Server. I find the deep dive into SQL Server has given me a good insight into the underlying fundamentals of DB technology. The importance of data modelling, the benefit of choosing appropriately sized data types are all things I've picked up. Knowledge of Perfmon counters, the architecture of SQL Server, every scrap of knowledge has been beneficial.
For the next generation running in the cloud where is the driver to learn this stuff? It definitely helps when designing in the cloud because I design in sympathy with the platform even if a lot of the platform is now abstracted away from me.
The breadth of my role has broadened but I have lost the depth. I do worry that lack of depth will turn out to be a serious constraint on the art of the possible.
May 11, 2020 at 4:05 pm
As a DBA in the cloud era, there are many more technologies that we need to familiarize ourselves with (PowerBI, ML, Document databases) but we don't necessarily need to know the subject at the same depth or perspective that an application developer or data scientist would. In a hybrid or pure cloud environment, when someone comes to the DBA with a request, it's usually something like: "We need you to setup a PowerBI Gateway." - not "Can you create this PowerBI report for us?". I help the data analyst team setup PowerBI data sources and optimize SQL, and on a slow day I'll do something like create disk space report for use internally by our DBA team. Our pre-existing knowledge of SQL applies, since SQL is the closest thing to a universal database language - even in the NoSQL world, but I don't feel the need to learn about how to create pretty charts and graphs.
So, when looking for a book or tutorial on Azure SQL, Cosmos DB, or PowerBI - look for a book that presents the topic from the perspective of a DBA. For example, I've read the first edition of this book, and found it to be concise and useful.
https://www.amazon.com/Professional-Azure-SQL-Database-Administration/dp/1789802547
Also, here on SQL Server Central, the articles and Stairways series tend to cover topics from a DBA perspective.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 12, 2020 at 3:38 pm
Thanks for the book, Eric. I'll try to take a look. I've wanted to try and get some more Azure/AWS knowledge going over time and I find books to be more interesting than other formats.
May 12, 2020 at 4:00 pm
As a DBA avoiding the “cloud” (not by choice), are there any recommendations for someone caught in a cloudless company?
I work at a business that refuses to migrate their database to the cloud. I’m hoping I can stay with this company until I retire, in about 5 or 6 years. But on the other hand, if something does go astray and I find myself out in the market, I won’t have any of the cloud skills needed to get in the door. The company was going to pay for my MCSE certification in SQL Server but with the pending doom of those certs, courtesy of Microsoft, I no longer have the option of getting certified in that realm or in the cloud. Unless I flip the bill myself and do it on my own time, I’m stuck in a vintage world of DBA’s.
Any suggestions for someone like that?
Aubrey W Love
aka: PailWriter
https://www.aubreywlove.com/
May 12, 2020 at 4:58 pm
...
Unless I flip the bill myself and do it on my own time, I’m stuck in a vintage world of DBA’s.
Any suggestions for someone like that?
The good news is that Azure is totally cloud based and inexpensive at the Basic (~$5/month) and Standard S0 (~$15/month) tier, so you can get hands on experience without any cooperation from your employer. In your case, it won't be vCore licening, but DTU based hourly billing. For a Basic tier, you get 5 DTU (plenty for one user) and 2 GB of storage at a rate of about $5/month, and for Standard S0 you get 10 DTU and 250 GB. You can connect to your instance from anywhere using SSMS, but you'll need to configure your firewall through Azure Portal to allow your home or work IP range.
https://azure.microsoft.com/en-us/pricing/details/sql-database/single/
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 12, 2020 at 6:31 pm
Thanks for the info and link.
It looks like the on-premise DBA is going to be met with a few challenges in the future. I know there are a lot of companies out there that will never go to the cloud and will be looking for old school DBA's. Much like how we occasionally break out the old programmers that know BASIC, COBOL, JCL, Fortran....
Aubrey W Love
aka: PailWriter
https://www.aubreywlove.com/
May 12, 2020 at 7:12 pm
You can also set spending limits to prevent large charges. I was using a dev program with $100 or so of credits a month and never even hit my credit card
May 13, 2020 at 1:14 pm
Thanks for the info and link.
It looks like the on-premise DBA is going to be met with a few challenges in the future. I know there are a lot of companies out there that will never go to the cloud and will be looking for old school DBA's. Much like how we occasionally break out the old programmers that know BASIC, COBOL, JCL, Fortran....
I'm ramping up for a forced migration to the cloud (AWS, to be specific). I'm finding that there is a little bit to learn (especially if you are being forced into AWS RDS and still need old things to work) but the supposed "old school" DBA (if they were good at what they did andd especially ) will actually have an advantage because they'll know all the work arounds and will be able to invent a couple of new ones. They also won't be sold on hype and will do the necessary and proper research, instead (for example, rather than a manage system like AWS RDS, we really need AWS EC2, which is really just using other people's hardware, and it's my job to help prevent the hype-lure of RDS from impacting us).
If you were a good on-premise DBA (especially if you have some good grip on T-SQL and performance tuning), you'll make an excellent cloud DBA and it won't take you long to get up to speed.
I can't say much about Azure except that, from what I've read, I'm REALLY happy to not be going that route. I'm sure others will have better things to say about it, though. Reading about something and actually having to do something are two totally different things in cases like this and can be either good or bad.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2020 at 1:53 pm
Azure SQL is still 99% the same familiar T-SQL we've been using for decades. Some features like Availability Groups and DBCC commands are gone, because they have been replaced with Azure managed services. Other features like xp_cmdshell are just gone, because you don't need them. The whole concept of platform as a service is that you manage the database and not the server and operating system.
You can also provision an IaaS VM in Azure where you can install SQL Server using your existing license (or choose a VM image with SQL Server pre-installed). Once done, you can use it to run SQL Agent jobs, SSIS, 3rd party tools, etc. while your databases exist in Azure SQL. We have an Azure VM running SQL Agent and SSIS.
Or you can just life and shift your existing on-prem SQL Server instance without modification to an Azure VM. That would be a scenario where your organization no longer wants to be in the business of running an on-prem data center but still wants to keep running SQL Server as is.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 14, 2020 at 2:08 pm
Azure SQL is still 99% the same familiar T-SQL we've been using for decades. Some features like Availability Groups and DBCC commands are gone, because they have been replaced with Azure managed services. Other features like xp_cmdshell are just gone, because you don't need them. The whole concept of platform as a service is that you manage the database and not the server and operating system.
You can also provision an IaaS VM in Azure where you can install SQL Server using your existing license (or choose a VM image with SQL Server pre-installed). Once done, you can use it to run SQL Agent jobs, SSIS, 3rd party tools, etc. while your databases exist in Azure SQL. We have an Azure VM running SQL Agent and SSIS.
Or you can just life and shift your existing on-prem SQL Server instance without modification to an Azure VM. That would be a scenario where your organization no longer wants to be in the business of running an on-prem data center but still wants to keep running SQL Server as is.
It's funny how people think that you don't need xp_CmdShell on managed systems like Azure.
Do they also not allow for OPENROWSET()?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2020 at 3:52 pm
OPENROWSET works with limitations
https://docs.microsoft.com/en-us/azure/sql-database/sql-database-features
May 14, 2020 at 4:54 pm
...
It's funny how people think that you don't need xp_CmdShell on managed systems like Azure.
Do they also not allow for OPENROWSET()?
You can OPENROWSET (or BULK INSERT) from CSV, Excel, etc. files contained in Azure Blob storage, but not local file system. Actually there is no local file system, so whatever you're currently using xp_cmdshell for (disk space or file operations?), it wouldn't be relevant in Azure SQL.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 14, 2020 at 7:11 pm
Jeff Moden wrote:...
It's funny how people think that you don't need xp_CmdShell on managed systems like Azure.
Do they also not allow for OPENROWSET()?
You can OPENROWSET (or BULK INSERT) from CSV, Excel, etc. files contained in Azure Blob storage, but not local file system. Actually there is no local file system, so whatever you're currently using xp_cmdshell for (disk space or file operations?), it wouldn't be relevant in Azure SQL.
Cool. Thanks, Eric. Is there a way to move the files to a "done" folder from T-SQL on Azure Blob storage?
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply