Tag: administration

  • The Need for DRE

    “Today’s database professionals must be engineers, not administrators”

    That’s a quote from an interview at O’Reilly on Database Reliability Engineering. I don’t want to quibble about whether those of us working in technology are engineers in name or not, but in function, I do think the world is changing to one where we need to do more than be caretakers of systems. We need to be actively involved in ensuring we have very reliable, well-designed systems that use the best practices and patterns of highly available and reliable database systems.

    There is advice to learn and work closer with developers. I like that, and I do think the idea of learning to script and automate tasks is important, perhaps more important all the time, for data professionals. Some of the advice to look towards the quick moving, limited lifetime of many software components today doesn’t make sense. A database, at least some parts of a database, don’t fit within that model. There are valid reasons why a datastore must provide some stability and persistence for an application and won’t fit within a model of multiple systems. Or at least not practically within a model.

    However, there is good advice in the piece to learn more about different types of database services and patterns, and consider other ways of implementing datastores other than a RDBMS. I wouldn’t necessarily abandon a RDBMS for some NoSQL store just because developers think it’s easier, but I would consider whether I actually need to very tight coupling between different parts of the database and complete consistency. I think there are a fair number of domains where a CQRS pattern or some distributed store would work well. The move to microservices might be an enabler for your business if you consider the advantages for OLTP type transactions.

    The flip side of all the power that many stores provide is that many also make reporting and aggregating information more difficult. I would venture that in many cases, a data warehouse (perhaps even a RDBMS-based or columnar store) is necessary, along with the ETL process necessary to keep it up to date. These aren’t simple processes, and take resources to build. For most of us, because we don’t work at extreme scales, I’m not sure it’s worth leaving a relational platform, but I do think that we can learn to evolve and enhance our relational databases faster with DevOps ideas and techniques.

    Steve Jones

     

  • Renaming MDF/LDF Files–SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    I would guess many people would run into this situation at some point. A developer or DBA creates a database, then decides to rename it, but the logical and physical names aren’t correct. This post will look at how to do this. A couple of notes and then the process below.

    This might not matter to many of you, but in development, I sometimes find I’ll rename a database and then attempt to recreate (or deploy) a new database with the old name. The mdf/ldf files don’t match, and I realize it’s because I’m using defaults.

    However, I’d also say this is an issue in a DR situation. If the filenames don’t seem to match, someone might restore the wrong database or the wrong files. Or worse, think the can delete a file on the file system because there’s no database with that name.

    Renaming the Database

    This is easy. Right click, select Rename.

    2017-06-07 09_38_49-

    Then type the name name. In this case, I’m going from WideWorldImporters-SSDT to WideWorldImporters-RR.

    2017-06-07 09_38_59-SQLQuery1.sql - (local)_SQL2016.msdb (PLATO_Steve (52)) - Microsoft SQL Server M

    That renames the database, but what about the files? If I run this:

    sp_helpdb ‘WideWorldImporters-RR’

    I get this:

    2017-06-07 09_42_00-SQLQuery1.sql - (local)_SQL2016.msdb (PLATO_Steve (53)) - Microsoft SQL Server M

    Not really what I want. I need these mdf/ldf files to be changed. How do I do this?

    I can get to the properties for the database and select the “Files” pane to get a list of files. Here I can change the logical name by clicking that field and typing a new name. I’ve done that here.

    2017-06-07 09_43_29-Database Properties - WideWorldImporters-RR

    However, if I scroll to the right to the File Name column, I can’t change anything.

    2017-06-07 09_43_44-SQLQuery1.sql - (local)_SQL2016.msdb (PLATO_Steve (53))_ - Microsoft SQL Server

    What I need to do is use the ALTER DATABASE command with the MODIFY FILE command. I need to do this twice.

    1. Change the physical file name
    2. Change the logical file name

    Let’s do that. Here’s the code to change the physical name.

    ALTER DATABASE [WideWorldImporters-RR]
     MODIFY FILE
     (   NAME = 'WideWorldImporters-SSDT_Data',
         FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\WideWorldImporters-RR.mdf'
     );

    I need to repeat this for the log file and the MOT file. Once I change the names, I get this message.

    2017-06-07 09_48_38-SQLQuery1.sql - (local)_SQL2016.WideWorldImporters-RR (PLATO_Steve (53))_ - Micr

    This is key. If I were to restart my system now, when the database attempted to start and go through recovery, the files would not have been found. Now, I need to change the physical file names.

    To do that, I first need to take the database offline.

    USE master
    go
    ALTER DATABASE [WideWorldImporters-RR] SET OFFLINE

    Then I go to the location of the physical files and rename them in Windows Explorer.

    2017-06-07 09_53_35-DATA

    Now I bring the database online.

    ALTER DATABASE [WideWorldImporters-RR] SET ONLINE

    Once that’s done, I can then use ALTER DATABASE again to change the logical file names.

    ALTER DATABASE [WideWorldImporters-RR]
      MODIFY FILE (NAME='USERDATA_612671E2',
                   NEWNAME = 'WWI_UserData'
                   );

     

    And run a final sp_helpdb.

    2017-06-07 09_54_13-SQLQuery1.sql - (local)_SQL2016.master (PLATO_Steve (53))_ - Microsoft SQL Serve

    SQLNewBlogger

    An easy task, with a touch of research in Books Online, but not too difficult. This took me about 10 minutes to do, and since I realized this was a good skill, I took screenshots and saved code as I went.

    Then about 10 minutes to write this up.

  • Why Does My Log Grow–SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    This is a great topic, and really, every DBA or admin should blog this and be sure they understand the issue.

    I saw a posting from someone that said this: they kept running low on disk space where the transaction log was kept. They would shrink the log, and they had 3 log backups per day, but the log kept growing, and this was an issue. What can they do?

    Let’s examine what happens: first, assume you have a trans‌‌action log that gets 2 transactions an hour. You have enough log space for 4 transactions in your log file. You back up 3 times a day (every 8 hours). Here’s your log size in transactions:

    1:00am - 2 transactions
    2:00am - 4 transactions‌‌‌
    3:00am - 6 transactions (log grows)
    4:00am - 8 transactions (log grows) 
    ‌5:00am‌‌ - 10 transactions (log grows)
    ‌5:00am‌‌ - 12 transactions (log grows)
    ‌5:00am‌‌ - 14 transactions (log grows)
    8:00am‌‌ - log backup with 14 transactions. Log is large enough for 14 transactions
    ‌9:00am - 2 transactions
    10:00am - 4 transactions‌‌‌
    11:00am - 6 transactions 
    12:00pm - 8 transactions 
    1:00pm‌‌ - 10 transactions 
    ‌2:00pm‌‌ - 12 transactions 
    ‌3:00pm‌‌ - 14 transactions 
    4:00pm‌‌ - log backup with 14 transactions. Log is large enough for 14 transactions
    ‌4:30 - you shrink the log back to 4 transaction size
    5:00pm - 2 transactions
    6:00pm - 4 transactions‌‌‌
    7:00pm - 6 transactions (log grows)
    8:00pm - 8 transactions (log grows) 
    9:00pm‌‌ - 10 transactions (log grows)
    ‌10:00pm‌‌ - 12 transactions (log grows)
    11:00pm‌‌ - 14 transactions (log grows)
    12:00am‌‌ - log backup with 14 transactions. Log is large enough for 14 transactions
    ‌

    Repeat this every day.

    Now, how does this change if we run log backups more often? Let’s say we decide to run log backups every hour. Now I get:

    1:00am - 2 transactions‌‌‌, log backup runs
    2:00am - 2 transactions‌‌‌, log backup runs
    3:00am -2 transactions‌‌‌, log backup runs
    4:00am - 2 transactions‌‌‌, log backup runs
    ‌5:00am‌‌ - 2 transactions‌‌‌, log backup runs
    ‌5:00am‌‌ - 2 transactions‌‌‌, log backup runs
    ‌5:00am‌‌ - 2 transactions‌‌‌, log backup runs
    8:00am‌‌ - 2 transactions‌‌‌, log backup runs
    ‌9:00am - 2 transactions, log backup runs
    10:00am - 2 transactions‌‌‌, log backup runs
    11:00am - 2 transactions‌‌‌, log backup runs
    12:00pm - 2 transactions‌‌‌, log backup runs
    1:00pm‌‌ - 2 transactions‌‌‌, log backup runs
    ‌2:00pm‌‌ - 2 transactions‌‌‌, log backup runs
    ‌3:00pm‌‌ - 2 transactions‌‌‌, log backup runs
    4:00pm‌‌ - 2 transactions‌‌‌, log backup runs
    5:00pm - 2 transactions‌‌‌, log backup runs
    6:00pm - 2 transactions‌‌‌, log backup runs
    7:00pm - 2 transactions‌‌‌, log backup runs
    8:00pm - 2 transactions‌‌‌, log backup runs
    9:00pm‌‌ - 2 transactions‌‌‌, log backup runs
    ‌10:00pm‌‌ - 2 transactions‌‌‌, log backup runs
    11:00pm‌‌ - 2 transactions‌‌‌, log backup runs
    12:00am‌‌ - 2 transactions‌‌‌, log backup runs

    In both scenarios, the total log transaction load across the day is the same. The total log backup size is the same across the day. However, a log backup allows me to reuse the log, so I never run out of space and get growths in the second scenario.

    If you aren’t sure how things work, or want to write your own blog, I would also recommend you read this:  http://www.sqlservercentral.com/articles/Administration/64582/

     

    ‌‌

  • SQL Server is Getting Smarter

    There’s been a lot of press and media about Microsoft on the AI and machine learning work they’re heavily investing in. From Cognitive Services to Cortana to Bots, Microsoft is really investing in developers and applications that will perform detailed analysis and make more complex decisions in any environment. Event SQL Server has gotten Python added to R Services and will change the way we run queries for analysis and reporting.

    The effect this will have on data professionals is not just limited to SQL Server’s machine learning capabilities. This week I saw a couple announcements from Microsoft on changes in SQL Server. Automatic plan correction is coming in SQL Server 2017 and automatic index management is in SQL Azure. I expect the latter to make an appearance in the on-premises product at some point, perhaps 2018 or 2019, but I would certainly count on this coming to your local installations at some point.

    Currently plan correction still requires a DBA to decide which plans need correcting, but once that the decisions are made, SQL Server can handle things. However, with automatic plan correction, we can allow SQL Server to force the last good plan when it detects an regression. This isn’t a huge change, but it can dramatically reduce some of the random calls that DBAs get when plans regress and performance tanks. Over time, we might find that many of those nuisance calls go away. I hope that most of you have other work that you can do instead of tracking down plan regressions, and you certainly should have more.

    There are other changes, such as threat detection, that I expect will allow a single person, perhaps the accidental DBA or developer, to manage a lot of the trivial, but important, administrative items for a SQL Server instance. This means that we need less data professionals that focus on the infrastructure side of databases. There will be more and more ways that SQL Server improves to handle the mundane tasks, amplifying the power of a single human, reducing the management burden, and using less people to manage more and more.

    I expect additional capabilities in SQL Server to simplify most tasks over time, and I’m hoping there’s one in particular that gets built soon. I’d like to see automatic backups (full and log) as a part of the database creation process. Some helpful defaults, perhaps at the instance level, that are applied to ensure that all databases are being backed up and we never see the “transaction log full” error unless we run out of disk space. It will come, as we move to the quick, button click, automatic setting method of managing all the cattle in our infrastructure. At least, I’m planning on this happening.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.8MB) podcast or subscribe to the feed at iTunes and Libsyn.