“What do you think made him so good?”

“He was very quick, and he was also very generous.”

That line. That sentence fragment. It hit me. Hard. Right in the brain.

And it came from an unlikely source. Season four, episode three of Comedians in Cars Getting Coffee, with Robert Klein. Go to 1:57 in and watch for yourself:

If you watch the series you will hear that same phrase used over and over again. Jerry and his guests use it to describe other comedians…no, other humans that were influential to others. They just happened to work in comedy. But the key ingredient for success is their generosity. It’s what made Johnny Carson so great, and it’s why Jimmy Fallon is so good as well. And it *may* explain why Conan O’Brien struggled in his first attempt at hosting, too. But I digress.

I don’t see enough of this generosity inside of IT departments. I see more of a “what’s in it for me” attitude. And, since I work in marketing, I see many examples of where people treat others as prospects, and not as friends or colleagues.

For me, being generous means you don’t expect anything in return. If you are expecting kindness in return then you are doing business, not kindness.

But there are exceptions in the world of data professionals. Robert Davis was one of them. He passed away early this week. And with him, our #sqlfamily lost a very generous soul.

Robert showed us all that generosity need not be of a monetary value. Sometimes a person’s time and/or skill is the most precious thing they can give. And Robert did just that. Here are a few examples:

– Robert’s contributions to the #sqlhelp hashtag
– His efforts on Spiceworks forums
– All his MSDN forum activity
– His SQL Server Mirroring book
– The private Microsoft MVP and MCM email distribution lists

I’m certain that I’ve missed many more examples of his reach. The point I want to make is that he was generous with his time and it influenced thousands of other data professionals.

And he did that without ever expecting anything in return.

That’s being generous. And that’s why there is an outpouring of admiration and respect for Robert.

If you are so motivated to do so, you can make a donation to his wife, Chrissy, at their GoFundMe page.

The world needs more people like Robert.

Thank you, Robert, for all your generosity, to me and everyone else, for so many years.

RIP, my friend.

The post The Generous DBA appeared first on Thomas LaRock.

Since last week I’ve seen a lot of scare tactics and knee-jerk reactions to Meltdown and Spectre. My post last week was meant to help keep everybody calm. I want you to understand that there *could* be a performance hit, but you won’t know unless you test. If you are afraid to test then you have more issues than just a chipset flaw. I also wanted you to understand the level of risk for your server to be compromised. Chances are it’s a small risk, so you might be able to avoid patching right away.

But you should patch anyway. There are few reasons why you would not want, or be able, to patch. And in those cases you will want to take extra measures to ensure your server will not be compromised.

As it turns out the word “patching” is overloaded with meaning. This is leading to confusion with users thinking they are protected, but they have not installed the correct patches.

To be fully protected from Meltdown and Spectre you need to install a patch from the manufacturer of your PC or server in addition to the software patches for your OS. You need both, just having one won’t be enough. And you are only going to get the microcode update form the manufacturer website at this time. You will need to install this update manually, outside of Windows Update. Microsoft has made this very clear, that you need distinct updates.

How to Check if Your Database Server Is Protected Against Meltdown and Spectre

Microsoft has made available a Powershell script to use to check if your system is protected. That KB article also tells you that you need two distinct updates. I can’t stress that point enough here: you need two updates.

Let’s get started with the Powershell script. We will right-click on the Windows menu (I’m on my Surface here) and launch Powershell as an Administrator:

Next, we need to install the module. We can do that with the following command:

Install-Module SpeculationControl

I had to click ‘Y’ to trust the repository, you will likely need to do the same. Next, we need to make sure our execution policy is configured. So, let’s run the following command:

Set-ExecutionPolicy RemoteSigned -Scope Currentuser

Now, we should be able to import the module, then run the command:

Import-Module SpeculationControl
Get-SpeculationControlSettings

And this was my result:

As you can see, I have the Windows update, but not the hardware update. Looks like I have some work to do to be protected.

How to Get the Patches

Here’s the current list of places you need to check for patching against Meltdown and Spectre.

For Windows:

Here is the Windows KB article: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

The Windows Update patches can be found at Settings > Update & security > Windows Update. Click “Check for updates” to install any available updates.

For Red Hat Linux:

Red Hat has a page dedicated to the issue, complete with a long list of patches available. If you are running something other than RHEL, you should be able to find a patch from wherever you got your distribution from.

For SQL Server:

Here is the SQL Server KB article: https://support.microsoft.com/en-us/help/4073225/guidance-for-sql-server

That KB article lists all the available patches for the affected and supported versions of SQL Server. I’d rather you reference that KB article than a long list of patches here.

For CPUs:

The hardware updates should be located on the website of the manufacturer. For example, here is the page for Dell, and for HP. You can find a comprehensive list of manufacturers at https://meltdownattack.com/

Lastly, you will want to patch your browsers, too. If there is one thing we can all learn from Meltdown and Spectre it is this: keep your software up to date.

The post How to Check if Your Database Server Is Protected Against Meltdown and Spectre appeared first on Thomas LaRock.

In the last post, we reviewed the options for upgrading SQL Server 2016. After upgrading SQL Server you need to perform a series of tasks to verify the databases are ready. You want to do this before the server is handed over to the end users for further testing. This post will provide you a checklist of items to review after the upgrade is complete.

1. Take backups

Right now. Before you do anything else. You’re a DBA. Backups should be in your DNA. You should have taken one prior to the start of upgrading to SQL Server 2016, and you had better take one right now and again before you turn that database over to your end users.

2. DBCC CHECKDB

One of your post-migration or upgrade tasks should be to run the following statement:

DBCC CHECKDB WITH DATA_PURITY;

This statement will check your data for values that are no longer valid for the column datatype. For databases created prior to SQL 2005 (and you *know* they are still out there), this step is important. For databases created in SQL 2005 and later, the DATA_PURITY check is done automatically with a regular CHECKDB.

But what about a database that was created in SQL 2000, migrated (poorly) to a SQL 2008 instance, and left in the SQL 2000 (80) backward compatibility mode? What about that little feller? Do you want to assume that the DATA_PURITY check has been getting done? Here’s a thought: just go run it yourself anyway.

Also worth noting that column integrity checks are not performed when the PHYSICAL_ONLY option is used.

3. DBCC UPDATEUSAGE

While not as critical as the DATA_PURITY command noted previously, this one still has a place in any migration or upgrade process:

DBCC UPDATEUSAGE(db_name);

This command will help fix any page count inaccuracies that are resulting in the sp_spaceused stored procedure returning wrong results. Be aware that it can take some time to run depending upon table or database size. Ideally, you would run this on a regular basis for one of the following reasons:

• You suspect that you are seeing incorrect values returned for sp_spaceused.
• Your database has a high volume of DDL statements (CREATE, ALTER, or DROP).

4. Updating Statistics

This is a MUST for any migration or upgrade checklist:

USE db_name; 
GO 
EXEC sp_updatestats;

This command will update the statistics for all the tables in your database. It issues the UPDATE STATISTICS command, which warrants mentioning because you *may* want to use the FULLSCAN option. I’m the type of person that would rather be safe than sorry. Therefore I would execute this:

USE db_name; 
GO 
EXEC sp_MSforeachtable @command1='UPDATE STATISTICS ? WITH FULLSCAN';

Bottom line: don’t forget to update the statistics after upgrading to SQL Server 2016. Failure to do so could result in your queries running longer as you start your testing. The end result is a waste of time while you troubleshoot all possible bottlenecks. With SQL Server 2016 there is also a new Cardinality Estimator (CE). Since the query optimizer relies on accurate statistics for plan estimation purposes, you will want your statistics are as accurate as possible before you begin any testing.

Take care of the stats now and you won’t have to worry about them later.

5. Refresh view definitions

Believe it or not, every now and then someone will build a view that spans into another database on the same instance. And, in what may be a complete surprise to many, sometimes these views will go across a linked server as well. The point here is the view may not be contained to data on that single instance. In what could be the most dramatic twist of all, sometimes these views are created using a SELECT * syntax.

I know, I know…what are the odds that you could have such code in your shop? But it happens. And when you have bad code on top of views that go to other databases (or views of views of views of whatever else some sadistic person built) you are going to want to use sp_refreshview to refresh those views.

If you are migrating a database to a new server then consider refreshing your views using sp_refreshview. Most of the time it won’t do anything for you, just like a burger topped with veggie bacon. But there is that one chance where it will dramatically improve performance and your customer will be happy as a result. Using sp_refreshview is a lot like flossing: it doesn’t take much effort, and the end result is usually worth it.

(Beware that previous versions of SQL Server Management Studio (SSMS) had a bug related to sp_refreshview, check out the comments in this post for more details.)

6. Check compatibility levels

If you have upgraded SQL Server within the past ten years then you have noticed how the compatibility level is not set to the newest version after the migration is complete. You must set the compatibility level yourself. With SQL Server 2016 this becomes more important than in previous versions due to the new Cardinality Estimator (CE).

There is a great whitepaper from Joe Sack that details the good, the bad, and the ugly with the new CE. The TL;DR version of the whitepaper is this: you’ll want to take advantage of the new CE except for the times when you won’t. Part of this is knowing which compatibility level you are using. I’d recommend you update every database on the SQL Server 2016 instance to compatibility mode 130 and test, test, test. [This assumes that you have baselined performance for your critical queries before the migration so you can verify if the new CE is working for or against you.]

7. Verify counts of objects

Remember the counts of objects such as tables and stored procedures that you took before? Now is when you want to review those counts. Make sure you have the same number of objects that you started with prior to the upgrade and migration. Remember the SQL Server upgrade motto: No table left behind!

8. Check Configurations

As part of the pre-upgrade tasks, we collected details on the in-house and third party vendor applications using the database server. We also collected information about the specific configurations applied to the server O/S, database instance, and the database itself. Review those details now to confirm the configurations were applied to the new server.

The use of a POC test system saves you a lot of time with the ‘after’ phase. A POC allows you to work through any issues early on in test and incorporate them into your upgrade plans. Also worth mentioning again is how easy Azure makes this for you.

This is also a good time to mention that sometimes it is worth running “production parallel”, where you have two systems running at the same time, both are considered production. How the data is kept in sync is up to you, but the idea is that the business users get a chance to verify that the new system is working as expected.

Summary

Upgrades are a necessary part of any development lifecycle. The chances of having a successful upgrade increase with the amount of planning and preparation you invest in building a proper upgrade process. If you are planning on upgrading to SQL Server 2016 use these series of posts as a guide to put together your checklist.

If you haven’t started building up your SQL 2016 migration or upgrade checklist yet, now is the time. Include the items listed above. They will save you pain, I promise.

Don’t forget that you can also download and read the upgrade whitepaper I wrote for SolarWinds. It contains more information as well as a set of tips and reference links that you will find useful.

The post Upgrading to SQL Server 2016: Post-upgrade tasks appeared first on Thomas LaRock.

In the last post, I mentioned that when upgrading SQL Server 2016 you have two options: in-place or side-by-side. With in-place upgrades, there is no need to worry about the transferring of data to a new server. Side-by-side upgrades require you to move data from one server to another. For data migrations there are four main options for you to consider:

• Backup and restore. Good option for smaller systems and if you want piecemeal migrations. You may also consider detach and attach here.
• Pre-staging the data using full, differential, and transaction log backups to minimize the data transfer. Log shipping is also a consideration.
• Database mirroring. This allows for easy migration of data from the old system to the new.
• Availability Groups. More complex than database mirroring because multiple databases can be involved.

The concept of rolling upgrades was also mentioned in the last post. This is when you use a high-availability feature such as mirroring, clustering, or Availability Groups. The idea is that you can upgrade a secondary node, failover, and continue upgrading all nodes in this manner until you upgrade the primary node, and then fail back if needed.

Let’s look at the steps involved for each.

Steps for an In-Place Upgrade

In-place upgrades are the easiest to perform, but the most difficult to rollback. The steps involved for in-place upgrades are as follows:

1. Verify that backups exist for all databases (user and system). If you have a database that is not in SIMPLE recovery mode, make certain a transaction log backup exists. Verify that these backups can be restored.
2. Review the list of prerequisites for SQL Server 2016, and install whatever necessary.
3. Run the SQL Server 2016 installation media.
4. Perform your post-upgrade tasks.
5. Test, test, and test that everything is working as expected.

Steps for a Side-by-side Upgrade

Side-by-side upgrades have more steps and are more complex. They also give you more flexibility for rolling back, because you are not touching the original system while it is still in use.

The steps involved in a side-by-side upgrade are similar for both an existing or new database server. The only difference is that for a new server you will need to install SQL Server. Here are the steps:

1. Verify that backups exist for all databases (user and system). If you have a database that is not in SIMPLE recovery mode, make certain a transaction log backup exists. Verify that these backups are able to be restored.
2. Script out any necessary system objects.
3. Script out any necessary SSIS packages (either from MSDB or as flat files).
4. For a new instance on a new server:
(a.) Review the list of prerequisites for SQL Server 2016, and install whatever prerequisites necessary.
(b.) Install the desired version and edition of SQL Server 2016.
5. Use script(s) from old server to create necessary system objects on the new server.
6. Migrate SSIS packages to MSDB (or as flat files, if applicable).
7. Select database(s) to migrate, take offline.
8. Migrate database to new instance. Repeat for each database.
9. Perform your post-upgrade tasks.
10. Test, test, and test that everything is working as expected.

Steps for a Rolling Upgrade

Rolling upgrades can reduce downtime during upgrades. Database mirroring is my preferred method for doing rolling SQL Server upgrades. But we could also use log shipping or Availability Groups, the choice of which feature you want is up to you. Make sure you have a solid rollback plan for whichever feature you are using.

The steps involved for rolling upgrades are as follows:

1. Choose your high-availability method (log-shipping, mirroring, Availability Groups).
2. Choose one of the following:
(a.) Upgrade one of the secondary nodes following the in-place upgrade instructions above.
(b.) Install SQL Server 2016 on a new server (and add it as a node if applicable)
(c.) Use script(s) from primary node to create necessary system objects on the new server.
3. Failover to the secondary node.
4. Perform any post-upgrade tasks.
5. Test, test, and test that everything is working as expected.
6. Repeat the upgrade for any remaining secondary nodes.
7. Perform any post-upgrade tasks.
8. Test, test, and test that everything is working as expected for each node.
9. Repeat the upgrade for the primary node.
10. Perform any post-upgrade tasks.
11. Test, test, and test that everything is working as expected for the primary node.

With rolling upgrades, you don’t have to fail back to the original server (the primary node). It is fine to configure database mirroring for the single purpose of a rolling upgrade. After you have failed over to the secondary you then break the mirror and remove the server from your inventory. This is the same result as a side-by-side migration but with less downtime than doing the traditional method of backup/restore or detach/attach. And for very large databases (VLDBs) this concept is crucial because restoring can be a cumbersome task.

Finally, it is important to note that data movement in a rolling upgrade is in one direction only. As a result, you can migrate from an older version to a newer version of SQL Server, not the other way around. If you are doing a rolling upgrade and you move your data to an upgraded node, you can’t go back without recovering from backups on the original server. You will see error messages indicating this issue. Recognize that SQL is telling you that you cannot migrate down to an earlier version.

Summary

For help with the migration of system objects, have a look at the DBAtools.io project. The DBAtools.io project has a lot of PowerShell cmdlets available to assist you with migrating objects and data.

In the next post, we will look at the tasks necessary after the upgrade is complete.

Don’t forget that you can also download and read the upgrade whitepaper I wrote for SolarWinds. It contains additional information as well as a set of tips and reference links that I believe you will find useful.

The post Upgrading to SQL Server 2016: Upgrade tasks appeared first on Thomas LaRock.

In our previous post on upgrading to SQL Server 2016 we talked about the reasons you might have for wanting to upgrade. For this post, we will look at the pre-upgrade checklist items you should consider before upgrading to SQL Server 2016.

After you have decided that upgrading is something you want, you will need to start putting together a project plan. The simplest plan involves three steps:

1. Pre-upgrade tasks
2. Upgrade tasks
3. Post-upgrade tasks

Seems simple, right? Well, it can be, especially if you take the time to review the details. Before the upgrade project begins you need to do a lot of legwork. Trust me when I tell you that the extra legwork now will save you headaches later. Here is a checklist of items to review before your data is migrated.

1. Know your path(s)

To get to SQL Server 2016 you can upgrade directly from:
• SQL Server 2014
• SQL Server 2012 SP2
• SQL Server 2008R2 SP3
• SQL Server 2008 SP4

If you are running SQL Server 2005 or earlier, you need to upgrade to an intermediate version before upgrading to SQL Server 2016.

For those folks running SQL Server 2000 instances (yes we KNOW you still exist) you are not able to upgrade directly to SQL Server 2016 without first upgrading to an intermediary version.

2. Licensing changes

Starting with SQL Server 2012 licensing is done per-core, not per-socket. There will result in licensing changes for SQL Server 2016 compared to your current version. But SQL Server 2016 Standard edition does allow for Server + CAL licensing, too. Because of the change from socket to core, in-place upgrades may come with a hefty cost increase.

Also worth mentioning is that SQL Server 2016 SP1 allows for many features that were once Enterprise-only such as Availability Groups, data compression, partitioning, Columnstore, etc. Evaluate licensing costs and the list of features now available in Standard edition prior to starting any upgrade project.

3. Know your options

4. Gather inventory details

You must gather information about the servers and the database instances that are in scope for upgrading to SQL Server 2016. There are many tools available to help you collect these details such as Microsoft Assessment and Planning (MAP) Toolkit and SQL Power Doc, as well as 3rd party tools.

Gathering a list of server and database names may not be enough, you will want to collect details about the databases as well. Even a simple count of tables is a valuable piece of information to have. If you have 873 tables at the start, then you need to verify you have 873 when you are done. Same for stored procedures. Consider collecting details at the column level, too. Make certain that datatypes and collations are intact, view definitions haven’t changed, etc.

You need to collect details on the in-house and third party vendor applications using the database server. List out the availability requirements for every application using the instance and you need to include the applications that are connecting remotely.

Also worth noting is any application specific configurations that are applied to the server O/S, the database instance, and the database itself. You need to know what non-default configurations are in use by the application using the instance.

This might seem like overkill for many reading this, but if you have ever had the unpleasant situation where a table was missed because of a migration and/or upgrading to SQL Server 2016, you will know it can be quite valuable.

5. Data Migration Assistant

6. Deprecated features

With each new version of SQL Server there are some features that are marked as deprecated. Deprecated does not mean the features have been removed, it means that the features will possibly be removed in a future version. You should not use deprecated features for any new development work. The list of deprecated database engine features for SQL Server 2016 is here.

7. Discontinued features

With SQL Server 2016, Microsoft started publishing a list of discontinued items. These items are removed from SQL Server. You can see the list of discontinued items here. You should review these items and make certain your applications are not relying on a feature that will not be there.

8. Breaking changes

Did you know that Microsoft publishes a list of breaking changes for each version of SQL Server? Well, you do now. You should review them to the point that they are familiar to you. You don’t have to memorize them all. Become familiar with them so that if something odd happens you can think to yourself “…hey, is this odd behavior listed in the breaking changes section of the Books Online (BOL)”?

9. Behavioral changes

Previous versions of SQL Server have published a list of behavioral changes for the database engine. Similar to the breaking changes, the behavioral changes are changes that could still affect you in an adverse way. They are worth reviewing, and they are also things that the DMA is likely to never report back to you about because they aren’t things that *will* break, but things that *could* break.

I was not able to find a BOL entry for SQL Server 2016 for the database engine. There are pages for Analysis Services, Integration Services, and Reporting Services. You could always review the previous versions over at the SQL Server 2012 page and use that as a starting list.

10. Read the release notes

Because you’re a geek, that’s why. Take a few minutes and read the release notes. No, they aren’t as funny as the release notes for apps on your phone, but they can be useful for you to review anyway. It’s good to have as complete a picture as possible for the new version should something not work as expected, and there are details in the release notes you may not find elsewhere.

11. New environment requirements

Updating your server O/S should be part of the upgrading to SQL Server 2016 project plan.

Microsoft lists the minimum requirements for installing SQL Server 2016 on this page. But, those are the *minimums* there. Chances are if your servers don’t already meet those requirements then you aren’t looking to upgrade anytime soon anyway. But if you are upgrading, then it might be time to upgrade your hardware as well. Heck, you may even consider going virtual (if you aren’t already), which still requires you to examine your hardware requirements.

But here’s the real reason you will want to upgrade your hardware: new features. Let’s say that you are thinking of upgrading to SQL Server 2016 to take advantage of Hekaton. Considering there is a lot of shiny new things in SQL Server 2016, you’ll want to do the extra legwork here to scope out what hardware you’ll need. Otherwise, you won’t be able to leverage many of the new features.

12. Take baselines

Collect performance baselines before you begin the upgrade process. If you don’t then you won’t have any way of knowing if performance is better or worse when the upgrade is complete. Since each SQL Server implementation is unique, there will be different performance metrics that are illbe to you and your business users.

You must also include a baseline of the current server operating system. Perfmon works well for this, but there are many 3rd party tools that can capture these details as well. If you are using Perfmon, you can output the counters to a file and then use the Performance Analysis of Logs (PAL) tool to analyze the output.

Know how your system is expected to grow over time. For physical implementations, this means you will try to size the physical server for end-of-life expectations. For virtualized servers, you will try to size for your performance needs now and expand later as needed.

13. Capture workloads

You can use the Distributed Replay feature to capture a production workload from a source server and replay it on a target server. Doing so will help to assess the impact of upgrading SQL Server by comparing the workload performance against both systems. Distributed Replay is most useful for scenarios that have high concurrency and a single client cannot simulate the workload properly.

The Database Experimentation Assistant is a new tool currently available in Technical Preview. It uses Distributed Reply along with R services to give the user a way to do A/B testing of workloads. Using statistical analysis of workloads allows for greater confidence when upgrading to newer versions of SQL Server.

14. Testing the Server O/S

Tools like iPerf and DskSpd can test the server network and disk performance to verify it is as expected before installing SQL Server. These tools are good at helping to identify if there are any possible configuration issues with the network and disk layout. It is better to check for such issues now before the installation of SQL Server 2016 begins.

15. Take backups

Before you start any upgrade process make certain you take backups of everything; databases, application files, and the server O/S. Sometimes you can utilize a VM snapshot (or checkpoint) to help with this process. I would recommend that when it comes to backups to consider the Computer Backup Rule of Three.

Also worth knowing: backups are only good if they can be restored. So, you will want to test the restore process before you move forward with upgrading.

In the event of a rollback during the upgrade process, you must decide how to handle potential data loss. For example, if you are running a production parallel scenario the business may need to redo a full day’s worth of data entry. It’s better to have those discussions now, not later.

Summary

The above pre-upgrade checklist items are a great starting point for any upgrading to SQL Server 2016 project. They form the foundation for gathering information about your server and databases you want prior to any upgrade taking place. With this information, you will save yourself time and avoid frustrations with upgrading to SQL Server 2016.

In the next post, we will look at the tasks that take place during the upgrade itself.

Don’t forget that you can also download and read the upgrade whitepaper I wrote for SolarWinds. It contains additional information and a set of reference links that I believe you will find useful.

The post Upgrading to SQL Server 2016: Pre-upgrade tasks appeared first on Thomas LaRock.

There exist many valid reasons to upgrade to the latest version of SQL Server. Database and system administrators do not take on upgrade projects simply because we like to make changes and watch things break. There are new performance features, new security features, and new scalability features in SQL Server 2016 that make it worth the time and effort to upgrade.

Here is a short list of reasons why anyone might consider upgrading to SQL Server 2016.

1. New Features in SQL Server 2016

With any new version of SQL Server we always have something shiny to play with. By upgrading to SQL Server 2016 we can take advantage of the following new features:

• Always Encrypted
• Dynamic Data Masking
• Row Level Security
• Stretch Database
• Temporal tables
• Automatic soft NUMA
• Query Store

We also have enhancements to features introduced in recent versions:

• In-Memory OLTP enhancements
• Always On Availability Groups enhancements
• Updateable non-clustered columnstore indexes
• DBCC CHECKDB enhancements

For a complete list of all the things in SQL Server 2016 that have been enhanced, check out SQL Server 2016: It Just Runs Faster.

2. Supportability

End of support is fast approaching for earlier versions. This means no new service packs or updates. Yes, you can purchase extended support, but it is costly. Microsoft has extended support for Win2008 and SQL 2008, that doesn’t mean it’s a good thing to keep using them. At some point you need to let go of that Windows NT 4.0 box running SQL Server 6.5. Just let it go and transport yourself into the 21st century.

3. Vendor Requirements

You may be using software from a third-party vendor that has strict requirements about which version of SQL Server you can be using. Yes, this goes both ways, it could require newer versions, and it could require older versions. You should check with your vendor. That’s what a good DBA would do.

4. Company or Industry Standard

Some companies may not allow for you to be running more than one full major version behind for any software product. And some industries may have those requirements, too. And don’t forget the auditors, they like to have their own suggestions. I also found upgrades to be a good time to revisit such standards and make sure they still apply. And, if they do, the upgrades also offered the opportunity to do some cleaning up of stuff on servers you aren’t using anymore. Like IE 6.

5. Scalability

The SQL Server engine has had many enhancements in the past ten years to address scalability concerns. I listed a few of those above (Columnstore, Availability Groups, In-Memory OLTP), but the engine itself has been updated to include things like new cardinality estimation techniques to help build better query plans based upon the distribution of your data. Upgrading to SQL Server 2016 will bring you greater scalability opportunities than previous versions.

Summary

This post was meant to highlight a handful of reasons as to why you would want to upgrade to SQL Server 2016. You might be interested in new features. Or you might be forced to keep your version current. Or you might be looking for a reason to retire some older servers and migrate your data to something shiny and new.

In the next post, we will take a look at the tasks you need to perform prior to the upgrade taking place.

Don’t forget that you can also download and read the upgrade whitepaper I wrote for SolarWinds. It contains additional information as well as a set of tips and reference links that I believe you will find useful.

The post Upgrading to SQL Server 2016: Reasons for upgrading appeared first on Thomas LaRock.

The same holds true for restoring the master database in SQL Server 2016, because it’s the same routine as what I posted for SQL Server 2014, which is the same routine as what I posted for SQL Server 2012. If you only click on one link, click on the 2012 link because that has the details on how to properly test that the restore worked.

For those of you too lazy to click on the links, I will summarize the steps for you here:

1. Using SQL Configuration manager, stop the SQL Server instance
2. Open a command window or Powershell session
3. In that command window, start the instance executable in maintenance mode using a secret command known only to people that have read my posts
4. Open a second command window or Powershell session and connect to the server instance using SQLCMD
5. Restore master from within that SQLCMD window
6. Using SQL configuration manager, restart instance

One thing to note here is that the instructions I provided assume you will be opening your command line sessions with ‘Run as Administrator’. If you don’t do that, bad things may happen. What bad things? This bad thing:

“Your SQL Server installation is either corrupt or has been tapered with (Error getting instance ID from name.).  Please uninstall then re-run setup to correct this problem”

Or this bad thing:

“RegOpenKeyEx of “Software\Microsoft SQL Server\MSSQL13.SQL2016\MSSQLServer\HADR” failed.”

My first thought when seeing this was trying to figure out what had gone wrong with the installation. I spent about seven (7) seconds thinking about the possible installation issues and then started thinking about user permissions for the command window. Once I switched to running the command window or Powershell session as an administrator, all was good.

That’s all there is to it, again. While SQL Server 2016 has been making a lot of headlines with all of the shiny new things inside, the steps to restore the master database has not changed.

You’re welcome.

The post HOW TO: Restore the Master Database in SQL Server 2016 appeared first on Thomas LaRock.