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.

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.

Well, that’s what I want to do today as well. I want to help clear up any confusion around how SQL Server collects, stores, and uses your data. I have some thoughts I want to share regarding the updated statement as well as the End User License Agreement (EULA).

First, with this updated privacy statement, the SQL Server product team becomes the first team at Microsoft to publish detailed information about what data is being collected, when it is collected, why it is collected, how it is collected, where it is being stored, and for how long. This is an amazing show of transparency and I would expect other product teams at Microsoft to follow suit. (I am not, however, expecting other companies like Oracle to be excited about sharing the same details. But that’s a different blog post).

Second, the updated privacy statement states that usage information is collected by default. In some cases, such as during the installation process, the collection is not something you can disable. In other cases, the data collection is something you can turn off, but only for paid versions of SQL Server. I have no issues with either of these items and here’s why:

1. Collecting usage information helps Microsoft make SQL Server better. This continuous feedback allows the SQL Server product team to have faster release cycles and to focus on the features that are being used or may need updating. This is why SQL Server is in the upper right Gartner Magic Quadrant for Operational Management Database Systems. This is a good thing, in my opinion, and therefore I’d like to see the continuous feedback continue (and not just for SQL Server, but for all Microsoft products).

2. If you are using a free version of SQL Server then I believe it is reasonable to expect that Microsoft will want to collect information on how you are using the product. Just as Jackson Browne once told us, “nobody rides for free”. If you have a complaint about a free product then you can (1) pay for the product or (2) not use the product. The choice is yours.

Lastly, the SQL Server 2016 EULA contains wording on what has been called “forced updates”. You should understand that these updates are not new. Here’s a screenshot from the SQL Server 2012 install screen:

That’s right, these updates have been happening for some time now. These updates are not a new thing for SQL Server 2016. This is how enterprise class software works – it will update files from previous versions to ensure the latest version works as expected. Examples of items that would be automatically updated by the SQL Server 2016 installation are the client drivers and the .NET redistributables installed by previous versions.

Anyone that has worked with enterprise class software for more than a few years should understand how software updates work. The EULA is telling you that items shared across versions of SQL Server are subject to be updated, they are not strictly versioned per release.

If you don’t want these updates to happen then you should consider running distinct servers for each version of SQL Server.

I once knew a manager that installed SQL 2000 on a production server that was running Sybase ASE (yes, I’m old). It brought the Sybase instance to a stop, as well as the business. So, if you are the type of person that would install such things on top of one another, then yeah, I guess the idea of automatic updates would be a concern for you.

And that’s reason #374 why I advocate new machines for new installs. I think you should, too.

Summary

The internet has a lot of misinformation on a lot of topics. SQL Server 2016 data collection and privacy is one of those topics where I see confusion being spread. Take the time to review the details in the privacy statement and then decide if it is worth putting on that tinfoil hat. I suspect that once you go through the details you will find that the data collection is benign and necessary for the SQL Server product team to continue to make SQL Server the best-of-breed relational database management system.

P.S. None of the above matters if you don’t allow your server to connect to the internet. SQL Server cannot “phone home” without a dial tone folks. It takes just a few seconds to configure a firewall to block SQL Server from communicating to Redmond.

P.P.S. Don’t do that because by doing so you reduce the ability for the product team to make better versions of SQL Server. If you don’t want to opt-in, then consider paying for the software you are using. Or use something else.

P.P.P.S. Forget I said that. Use SQL Server. Read about the data collection yourself and make up your own mind. But lose the hat, it doesn’t look good on you anyway.

The post SQL Server 2016 Updated Privacy Statement appeared first on Thomas LaRock.

I am fortunate that I still work with SQL Server daily. I am still consulted from time to time on various projects and performance troubleshooting. It helps keep my skills sharp. I also get to continue to build content as part of my current role, which is a wonderful thing because one of the best ways to learn something is to try to teach it to others.

All of this means that over the years I’ve been able to compile a list of issues that I would consider to be common with SQL Server (and other database platforms like Oracle, no platform is immune to such issues). These are the issues that are often avoidable but not always easy to fix once they have become a problem. The trick for senior administrators such as myself is to help teams understand the costs, benefits, and risks of their application design options so as to avoid these common problems.

So, here is my list of the top 5 most common problems with SQL Server.

Indexes

Indexes are the number one cause of problems with SQL Server. That doesn’t mean SQL Server doesn’t do indexes well. These days SQL Server does indexing quite well, actually. No, the issue with indexes and SQL Server have to do with how easy it easy for users to make mistakes with regards to indexing. Missing indexes, wrong indexes, too many indexes, outdated statistics, or a lack of index maintenance are all common issues for users with little to no experience (what we lovingly call ‘accidental DBAs’).

I know, this area covers a LOT of ground. The truth is that with a little bit of regular maintenance a lot of these issues disappear. Keep in mind that your end-users don’t get alerted that the issue is with indexing. They just know that their queries are taking too long, and that’s when your phone rings. It’s up to you to know and understand how indexing works and how to design proper maintenance.

Poor designs decisions

Everyone agrees that great database performance starts with great database design. Yet we still have issues with poor datatype choices, the use of nested views, lack of data archiving, and relational databases with no primary or foreign keys defined.

Seriously. No keys defined. At all. You might as well have a bunch of Excel spreadsheets tied together with PowerShell, deploy them to a bunch of cluster nodes with flash drives and terabytes of RAM, and then market that as PowerNoSQL. You’re welcome.

It is difficult to make changes to a system once it has been deployed to production. This means that poor design choices are something that will linger for years. And that bad design often forces developers to make decisions that end up with…

Bad code

Of course saying ‘bad code’ is subjective. Each of us has a different definition of bad. To me the phrase ‘bad code’ covers examples such as unnecessary cursors, incorrect WHERE clauses, and a reliance on user-defined functions (because T-SQL should work similar to C++, apparently). Bad code on top of bad design will lead to concurrency issues, resulting in things like blocking, locking, and deadlocks.

Because of the combination of bad code on top of poor design there has been a significant push to make the querying of a database something that can be automated. The end result has been a rise in the use of…

ORMs

Object-Relational Mapping (ORM) tools have been around for a while now. I often refer to such tools as code-first generators. When used properly they can work well. Unfortunately they often are not used properly, with the result being bad performance and wasted resources. ORMs are so frequent a problem that it has become easy to identify that they are the culprit. It’s like instead of wiping their fingerprints from a crime scene the ORM will instead find a way to leave fingerprints, hair, and blood behind, just to be certain we know it is them.

You can find lots of blog entries on the internet regarding performance problems with ORMs. One of my favorites is this one, which provides a summary of all the ways something can go wrong with an ORM deployment.

Default configurations

Because it’s easy to click ‘Next, Next, OK’ and install SQL Server without any understanding about the default configuration options. This is also true for folks that have virtualized instances of SQL Server. There’s a good chance the server admins also choose default options that may not be best for SQL Server. Things like MAXDOP, tempdb configuration, transaction log placement and sizing, and default filegrowth are all examples of options that you can configure before turning over the server to your end users.

Seeing similar issues time and again made me want to build an entire talk dedicated to helping people understand how to configure SQL Server for performance. You can watch the webinar I did with Tim Chapman here.

The above list of five items is not scientific by any means, these are the problem that I find to be the most common. Think of them as buckets. When you are presented with troubleshooting performance, or even reviewing a design, these buckets help you to rule out the common issues and allow you to then sharpen your focus.

The post The Top 5 Most Common Problems With SQL Server appeared first on Thomas LaRock.

Here we go again! It seems that it was only yesterday we were talking about all the things you want to look out for when upgrading to SQL Server 2012. Now, just two years since SQL Server 2012 was released, we have a shiny new version with SQL Server 2014. And that means, of course, people will be thinking about upgrading to SQL Server 2014. So I’ve put together a list of items that you will want to have handy when upgrading or migrating your databases from those dusty old versions to the brand new SQL Server 2014 engine.

[UPDATE: For details on upgrading to SQL Server 2016, you can go to this page, or you can start with this post.]

I’ve witnessed many novice administrators make the common mistake of believing that the upgrade process for a database server is as easy as pressing a few buttons. While you can certainly click “Next, Next, Finish” and consider your task to be complete the truth is that the upgrade process is often considerably more complex. A proper upgrade process involves detailed research, planning, and execution.

Failing to prepare a proper upgrade process for your database server is likely to result in your end users seeing diminished performance after the upgrade is complete. Since your goal is to increase performance and stability as a result of the upgrade you can understand that your users are likely to be upset if things were to get worse!

Since it can be a daunting task to put together everything you need in a pre-upgrade checklist, I’ve compiled this list of items that you need to include in any checklist you put together for migrating your database server to SQL Server 2014. Including these items into your checklist is likely to help you avoid 98% of any potential upgrade issues.

Please note that these steps are specific for an upgrade to the database schema and data. They do not include anything regarding the upgrading or testing of an application that is going to be accessing the upgraded database. You will want to remember to test your application and not just assume it will work perfectly even after the database has been upgraded. I would also advise that you perform these steps in a non-production environment first because I often find that common sense isn’t so common after all.

Also please note that this list is meant to serve as a guide for you to use when doing either an in-place upgrade or when migrating from a previous version. However, I always recommend doing a migration whenever possible as opposed to the in-place upgrades. Migrations (typically done by restoring a database backup from the current instance) just make me feel more comfortable should I need to troubleshoot issues later. I like knowing I started with a clean slate, but that’s just how I roll. You should do what works best for you.

1. Using the SQL 2014 Upgrade Advisor

The SQL Server 2014 Upgrade Advisor (UA) is just that: an advisor. Much like a consultant, it doesn’t fix everything that is wrong, it merely advises you on what actions you should take when upgrading to SQL 2014. The actions the UA recommends will come in two forms: those actions to be done prior to a migration, and those actions to be completed post-migration. The UA is really good at finding what I call the “stub-your-big-toe” things that need fixing prior to a migration. But it is not foolproof, it will not identify every last detail. You will need to play the role of an actual DBA when migrating to a new version. Many of the items below will help you to do just that.

2. Reviewing the “breaking changes” section in the Books Online

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, just be 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)”? I would like to believe that the UA will alert you to many of these breaking changes but the truth is the UA is not as dynamic as the BOL. That means the BOL may have an entry or two that doesn’t make it into the UA checklist, and that is why you should review this section.

Currently (as of this post in June of 2014) the link above lists the breaking changes for SQL Server 2014 simple as “no new issues”. I believe this is simply because this BOL entry has yet to be updated, so check back on this page often and I am certain you will find content listed.

3. Reviewing the “behavioral changes” section in the Books Online

Similar to the breaking changes, the behavioral changes are changes that could still affect you in an adverse way. They are definitely worth reviewing, and they are also things that the UA is likely to never report back to you about because they aren’t things that *will* break, but merely things that *could* break. Also worth noting is that the BOL appears to have two entries for behavioral changes, one for SQL Server features, and one specific for the database engine.  I’d advise you keep your eye on both going forward.

4. Executing DBCC CHECKDB WITH DATA_PURITY

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 rather important to take. For databases created in SQL 2005 and later, the DATA_PURITY check is supposed to be 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. That way you know it is getting done.

5. Executing DBCC UPDATEUSAGE command

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. For SQL Server 2012, this check was recommended for databases created prior to SQL Server 2005. However, in SQL Server 2014, the BOL entry link lists this command as being applicable for databases created in SQL Server 2008 and later. That seems odd to me, since this command is valid for SQL Server 2005. I’m not certain why the SQL Server 2014 documentation states this as a command for SQL Server 2008 and later. I’d recommend you run this for SQL Server 2005 databases being migrated to SQL Server 2014 anyway. [If I can get an answer from someone at Microsoft regarding this documentation issue I will update this post accordingly. In fact, I see this message for a handful of SQL Server 2014 entries, and I think that it’s usage is slightly misleading.]

6. Updating statistics

This one is not to be skipped and is simply 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 that command with the FULLSCAN option. I’m the type of person that would rather be safe than sorry and therefore would end up running something like this:

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

Bottom line: don’t forget to update the statistics after an upgrade. Failure to do so could result in your queries running slowly as you start your testing and may end up wasting your time while you try to troubleshoot the possible bottlenecks. With SQL Server 2014 there is also a new Cardinality Estimator (CE), and I’ll talk more about this later, but you are going to want to make certain your statistics are as accurate as possible before you begin any testing. So, take care of the stats now, and you don’t have to worry about it later.

7. Refreshing your views using sp_refreshview

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 that your view may not be of data that is contained in just the database 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.

So, if you are migrating a database in your environment to a new server then it would be a good idea to refresh 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 like flossing: it doesn’t take much effort, and the end result is usually worth it.

8. Taking backups

You’re a DBA. Backups should be in your DNA. You should have taken one prior to the start of any upgrade or migration, and you had better take one right before you turn that database over to your end users. Also, you should save any output from the items listed here, as it could prove helpful should something go awry later. (bonus item – make sure your backups are good!)

9. Upgrading your hardware

Microsoft lists the minimum requirements for installing SQL Server 2014 on this page. However, 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 will still require 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 2014 in order to take advantage of In-Memory OLTP Hekaton. I can’t find any MSDN article that states if there are minimum hardware requirements for Hekaton, but I did find this blog post from the SQL Server team that suggests some guidelines. Considering there is a lot of shiny new things in SQL Server 2014, chances are you’ll need to do some extra legwork here to scope out what hardware you’ll need in order to leverage many of these new features.

10. Knowing the right upgrade path

For those folks running SQL Server 2000 instances (yes we KNOW you still exist) you are not able to upgrade directly to SQL Server 2014 without first upgrading to an intermediary version. You have two options to choose from when going from pre-SQL Server 2005 versions. The first option is to do an upgrade in place to SQL Server 2005, SQL Server 2008, or SQL Server 2008 R2. The second option is to do a backup (or even detach) your database and restore/attach to an instance running SQL Server 2005, SQL Server 2008, or SQL Server 2008 R2. At that point you will be able to complete the upgrade to SQL 2014.

And like I said at the beginning, I prefer to do migrations rather than upgrades in place. It’s just a preference. For something like a SQL Server 2000 database, I’d need to do a backup, restore it to an intermediary version (like SQL Server 2008 R2), then do another backup and restore that to SQL Server 2014. At that point you should run through this checklist before turning it over for testing.

11. Check your compatibility levels

If you have been going through SQL Server upgrades for the past ten years then you are likely to have noticed that the compatibility level does not get set to the newest version after the migration is complete. You need to manually set the compatibility level yourself. With SQL Server 2014 this becomes more important than in previous versions due to the new Cardinality Estimator (CE).

I delivered a session at TechEd this year on the new CE, Jimmy May has a short summary blog post regarding the new CE, and there’s also what I consider to be the “Gold Standard” on the new CE in 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 2014 instance to compatibility mode 120 and test, test, test. [This assumes that you have baselined performance for your critical queries prior to the migration, so that you can verify if the new CE is working for or against you.]

12. 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.

Conclusion

Upgrades are a necessary part of any development lifecycle. The chances of having a successful upgrade increases along with the amount of planning and preparation you invest in building a proper upgrade process. If you are planning to upgrade to SQL 2014 you can use this post as a guide to help put together your checklist.

If you haven’t started building up your SQL 2014 migration or upgrade checklist yet, now is the time, and get these items included. They will save you pain, I promise.

The post Upgrading to SQL Server 2014: A Dozen Things to Check appeared first on Thomas LaRock.

Here’s the short version:

1. Create your VM
2. Open a port for the VM inside the Azure management portal
3. Open a port in the Windows firewall on the Azure VM
4. Configure security for the instance; verify TCP is enabled
5. Connect remotely with SSMS

It’s that easy. Now let’s take a look at the steps in more detail.

Create Your VM

First we will create an Azure VM. Here I will choose the “Quick Create” option that has an image of SQL 2012 SP1 running on Windows Server 2012:

Open a port

Once the VM is created you will need to open up a port in order to allow access to the instance of SQL Server. I’m going to stick with the default port of 1433 and create a new endpoint here:

Configure firewall rules

Next up we need to configure the firewall on the server itself. I will use Remote Desktop to connect to the server to get this part done. From the dashboard, I can click on ‘Connect” in the lower left:

This will open up RDP session for me. From there I will configure a new inbound rule in the Windows firewall for port 1433:

I will select a rule type of ‘Port’, as shown above. The port will be for 1433 because I’m showing a trivial example here. I’d encourage anyone actually opening up an instance of SQL Server like this to use a non-default port.

After clicking next, the options I will select are as follows (sparing you from a bunch of additional screenshots):

• Select TCP and specify port 1433
• Next, select ‘Allows This Connection’
• Then, select when you want the rule applied (I chose ‘Public’, choose what is right for you)
• Lastly, assign this rule a name (I chose ‘SQL’ because I’m lazy, but do what is right for you)

Here is where I also would advise you take a moment to verify that SQL Server is enabled to use the TCP protocol:

Configure security

Next, we will configure SQL Server to use mixed mode authentication for the purpose of a simple example. Note that Windows Azure does support Active Directory at this time, so this may be an option for you.

We will change the security to ‘Mixed Mode’ and create a new SQL login:

Connect

After a restart to the instance we should be able to connect from SSMS running locally. The server name is the DNS name you chose when creating the VM. In this case, I chose sql2012-tl, so my URL becomes sql2012-tl.cloudapp.net:

Connecting to an instance of SQL Server running in an Azure VM is very simple and straightforward process. You are just a few clicks away from being able to access your instance running in an Azure VM from the client tools installed on your desktop.

The post HOW TO: Connect To A Windows Azure VM Using SQL Server Management Studio appeared first on Thomas LaRock.

I always describe the interview process as being a lot like being on a blind date. You shouldn’t be looking to stump someone during an interview. Memorization of obscure facts such as database mirroring is only supported starting with SQL 2005 SP1 is not going to translate to success in a DBA role.

The DBA role does not require you to know the answer as much as being able to find the answer. A good DBA will be able to teach, and train, others. This will require a good deal of patience.

The five questions I posted previously helped you get an idea of the skill level of the candidate. Since that post came out two years ago the industry has changed quite a bit. Virtualization is more common. The Cloud is here to assimilate everyone. Despite all that has changed there remains some core skills needed by any successful DBA: good troubleshooting skills, communication skills, a sense of humility, the ability to listen, the ability to work well with others, and the ability to work well under pressure with multiple deliverables (including the middle-of-the night disasters).

Today I wanted to offer up five additional questions for you to use when interviewing a database administrator. They will help you learn more about the candidate’s practical work experience better than any resume ever will.

1. What is the most important job function for a database administrator?

This question gives you the opportunity to understand what “being a DBA” means to the candidate. If you are conducting the interview then I will assume you know that (1) you have an idea of exactly what duties you expect the DBA to perform and (2) that a DBA wears a lot of hats depending on the shop they came from. They may be more server and hardware focused and rarely write T-SQL. Or they could have been more on the development side and knew how to do a restore but have never racked a server in their life.

You need to know a bit more about what their practical experience has been. I’m talking about hands-on experience, too. If they haven’t touched it, then it doesn’t count as experience. It counts as classroom learning, but that’s about it. And if that classroom learning didn’t have a hands-on lab it counts as listening, maybe. Once you can get an understanding of the tasks they have been doing you can also understand if their understanding of what is most important matches your expectations.

For example, to me the most important function would be the ability to recover data to a specified point in time. That’s what I expect a DBA to get done. That may not be what you want. But unless you ask the question you will never know how much gap exists between you and the candidate.

2. Hyper-V or VMWare?

Similar question to asking someone if the prefer Kirk or Picard, depending upon the role you have in mind for your DBA you may expect the candidate has some experience with virtualization. It would be good to know if they have practical, hands-on experience with any particular type of virtualization software. Unless you are expecting them to be your VM admin, I wouldn’t worry too much if they only have experience with one or the other. In other words if you are a VMWare shop I wouldn’t think that the candidate only using Hyper-V would be a deal breaker for you. The important thing here is that they can demonstrate some familiarity with the concepts of virtualization, if needed.

This may be one of the more technical discussions you have, as the answers could lead you down a path of talking about network cards and cable, virtual switches, storage, RAID, virtual CPU, live migrations, etc. Listening to the candidate share some war stories is good way to get an understanding of their true skills.

3. How do you plan for upgrades?

Most database software vendors release new versions within 2-3 years of the previous version. At some point, no matter how slow it may take, a company will upgrade to the newer version. If the candidate has not been around long enough in IT to go through an upgrade then you’ll want to know that up front.

I’m not saying that not having done upgrades is a red flag. There are plenty of reasons why a company may have not done any upgrades at all. What I am saying is that having someone go through the experience at least once is quite valuable. This is a good discussion point for things like upgrade in place versus installing something new. You get to see how they approached the idea of upgrades and migrations. You can talk about project plans, timelines, lessons learned, etc.

You may even learn something new, too.

4. What trends do you see coming in the next 3 years that will impact your role the most?

This is along the same lines as “how do you stay current”, but I think it is better because it gives me some insight into how the candidate can ascertain the costs, benefits, and risks in their role as a DBA. It’s too easy to make up answers about how you stay current. It’s harder to offer insight into industry trends. Doing show shows vision and creative thinking.

This is also your opportunity to see how well the candidate reacts to new things. A good DBA must be flexible to new ideas and concepts. If you find someone too rigid in their thinking then consider that a red flag. You want a DBA that leans more to the “we can do that, and here’s what it will take, and here’s the risk” versus the “never touch that thing over there because I’m afraid of change”.

5. What frustrated you most at your previous job?

Lastly, there’s a reason why the candidate came to your office today, and you need to know more about why. I like how this question is framed better than the traditional “why are you leaving your last job”. Asking them about their frustrations allows for you to get some insight as to what they are looking for in their new role. This allows for you to know rather quickly if they are likely to be frustrated with you as well. For example “I was frustrated with being called every night” won’t bode well for them if you are expecting them to also be on call.

This also gives you some insight as to how they work with others. If they sit there and bad mouth everyone they used to work with, that’s a huge red flag about the working relationship you can expect as well.

In addition to the questions, and the conversation that ensues, you are also going to want to evaluate the candidate in other areas. For example, you can look for certain things that would have the candidate stand out among the others, or where they fail to measure up.

And there you have it, five additional questions to ask of any DBA in an interview. You can alter these to fit your needs for whatever role you are trying to fill, just keep in mind that you want to frame everything in the form of a conversation. After these questions you can move into more targeted questions with any candidate that has done well.

If you can follow this outline and have a good conversation then you are going to be able to identify the right candidate.

The post 5 More Questions For Interviewing a Database Administrator appeared first on Thomas LaRock.