Check your databases are in the correct version

DECLARE @ver nvarchar(128)
SET @ver = CAST(serverproperty('ProductVersion') AS nvarchar)
SET @ver = SUBSTRING(@ver, 1, CHARINDEX('.', @ver) - 1)

SELECT
[name] AS DatabaseName ,
200 AS Priority ,
'Performance' AS FindingsGroup ,
'Old Compatibility Level' AS Finding ,

( 'Database ' + [name]
 + ' is compatibility level '
 + CAST(compatibility_level AS VARCHAR(20))






 + ', which may cause unwanted results when trying to run queries that have newer T-SQL features.' ) AS Details
FROM    sys.databases


where
   CASE compatibility_level
    WHEN 65  THEN '6'
    WHEN 70  THEN '7'
    WHEN 80  THEN '8'
    WHEN 90  THEN '9'
    WHEN 100 THEN '10'
    WHEN 110 THEN '11'
    WHEN 120 THEN '12'
    end

    <>   @ver

Finding the Active SQL Node

Ever needed to know what node of your SQL cluster is the alive one.  Wonder no more.

SQL:-

Select ServerProperty('ComputerNamePhysicalNetBIOS')

Will show all nodes and there current state.

Or in Powershell:-

# Set cluster name 
$cluster_name = "ClusterName";
# Load SMO extension
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") | out-null;
$srv = New-Object "Microsoft.SqlServer.Management.Smo.Server" $cluster_name;
# Get server properties
$properties = $srv.Properties
$owner_node = $properties.Item("ComputerNamePhysicalNetBIOS").Value;
$is_clustered = $properties.Item("IsClustered").Value
if($is_clustered)
{
 Write-Host "The current active node of $cluster_name is $owner_node.";
}
else
{
 Write-Host "$cluster_name is not a clustered instance of SQL Server.";
}

SLAs

Finding SLA's can be one of the hardest things to do as a DBA.  As it totally depends from company to company.

Some company's will have a list of very tight SLA's that are very hard to keep to.  And others will have none.

That's why I have always found its best to come at this from a DBA angle.  Get to know your databases, what application do they affect, what do them applications do, and who uses them are they client facing?

Understanding the databases and businesses importance will mark you out from other DBA's and ensure you fully know why each database has/Or should have the SLA's assigned to them. 

DFS

Just been reading up on what DFS is. I have known of it for some time.  But never the basics of how it works

HA / DR / Replication relationships

Working out the companies existing HA and DR procedures is vital.

I find the best way to do this is to map them out in something like visio, Its important to look at this on a database level not server, as no all will go to the same server.

First thing is to get an idea of any Mirrors, AG's or Log shipping.

I recommend that there are mapped in Visio with a different colour line per HA type.

The same can be done with Replication.

SP_whoisactive

This is bloody great.  Gives you a lot move info on whats doing on point in time.

SP_WHOISACTIVE

DNS are a DBA's best friend

Pah who needs diamonds.  A few DNS address can make you life much more simple.

SQL 2012 + Method 

In SQL 2012 high availability groups Microsoft brought in the ability to use a single Arecord.  This means that you can choose a set of databases that are related to a single product and have them six in a box with a virtual server name, that can fail over to DR with them.  an example set up below.

SERVER1 - Primary sever

DRSERVER2 - Your DR server

You could  have all databases related to say communications sitting in an AG.

Lync
EAS
Quest

These would all now have a virtual server name of say SQLComms

So no matter what server your databases now end up on, any application pointing to the arecord of SQLComms will see the right server.

All very useful as you can ensure that you have seamless DR, and also allows you to move databases about with ease.

NOTE You will still need to ensure that correct users sit on both servers.

 Pre SQL 2012 Method

The same can be achieved in older versions of SQL, however it does require a bit of manual intervention.

Set up a Cname (alias) for the same set of databases, you can then re-point this name to the failed over DR server once your at DR.

Another good use for this, is to stop hard coded server names.  If as far as every one else is concerned the server name is that alias, you can always just pick up and move the databases.