SQL Server uses PARTNER TIMEOUT to determine the maximum period of time an instance waits to get a “ping” message from another instance of SQL Server before determining whether a failover should occur.

To see the current setting, run this query:

   SELECT db_name(database_id) “database_name”
        , mirroring_connection_timeout
     FROM sys.database_mirroring
GO

To change the current setting, run this query:

ALTER DATABASE [databasename] SET PARTNER TIMEOUT 10
GO

lowest value: 5
default value: 10

To generate change sql:

   SELECT db_name(database_id)
        , mirroring_connection_timeout
        , ‘alter database [‘ + db_name(database_id) 
        + ‘] set partner timeout 30’
     FROM sys.database_mirroring
    WHERE mirroring_role_desc = ‘PRINCIPAL’

Here is how to do it in SQL 2008+

     SELECT cp.plan_handle
          , st.text
          , ‘DBCC FREEPROCCACHE (‘ + convert(varchar(max), cp.plan_handle, 2) + ‘);’
       FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st

In SQL 2005

Could use undocumented function

master.dbo.fn_varbintohexstr

or XML

cast(” as xml).value(‘xs:hexBinary(sql:variable(“column_or_variable“))’, ‘varchar(max)’);

VEEAM’s vmware backup management software often touts how it can “backup SQL Server databases and truncate the transaction log”.

This is probably significant for many corporations that do not have a DBA on staff and only have system administrators and helpdesk folks minding the database servers.

Out of the box, databases are not backed up unless someone does something to back them up.  That and the transaction logs for FULL and BULK_LOGGED recovery model databases continue to grow until they get backed up and then are automatically truncated once they are backed up.

This can result in poor performing databases that have disks filling up and transaction log files that are many times larger than the actual data files.

VEEAM allows system administrators a way to trigger native database and transaction log backups.   A sysadmin would probably think it is enough that now those unruly transaction logs aren’t filling up disks anymore, pat themselves on the back, and think they are done.

Unfortunately, folks tend to stop short of asking questions “What are transaction logs, are they important?”, “I wonder why transaction logs grow until they are backed up?’, etc…

The trouble with this is that if database and transaction log backups are being performed by other processes, then if VEEAM initiates a backup, it can break the continuity of your backup chain and cripple your ability to do point in time restores to a point in time between full backups.

Having a mixture of tools managing database backups is a recipe for disaster.

If you have squirrelly sysadmins who insist on using VEEAM to back up databases, you will need to do one of two things:

1.  Tell them to perform only COPY-ONLY full backups and not to perform any transaction log backups.  Then assure them that you are performing your own full and transaction log backups using your own backup management tools and that the transaction logs are getting truncated.

-OR-

2.  Use VEEAM to manage ALL of your full and transaction log backups

While linked servers are a convenient feature that developers like because they are easy to implement, they are not very efficient at moving large amounts of data

General recommendations for any data integration include:

1. Do not “push” data over a link
– Do not perform inserts or updates over link

2. Use linked servers only for “pulling” small and medium amounts of data
– Simple select statement against a view in remote system — Execute stored procedure in remote system that returns a data set
– This allows for remote system to optimize the query plan
– Alternative bulk copy methods should be used for really large amounts of data, remember that data pulled across linked servers will be eating up memory that your production SQL Server needs

3. The system that is being updated (written to) should perform a read-only pull
– this is better for security in that it only needs read-only connection to remote system
– DML is transactional and causes additional overhead that a select statement does not

4. Data pulls should be a single dataset
– There should not be “cross system” joins in the where clause
– Do not perform looping or cursors across a connection
– Either of these make it very difficult for query optimizer to develop query plan across systems
– If have to, it is better to pull more data than needed from remote system, and then filter it with join in local system than to try and join across systems

5. Also, did I mention “Do not perform inserts or updates over links”?

What happened to the export SSIS package?

Going from 2008R2 to 2012, SSIS packages began using the project deployment model.

The quick way to get a copy of the SSIS package out of SQL is to run SQL Server Management Studio as Administrator and expand the tree:

“Integration Services Catalogs” -> SSISDB -> ProjectFolderName -> Projects -> ProjectName


Then right-click the ProjectName and select “Export…”


Save and remember the name and path you save the *.ispac file.

Rename the ispac file with *.zip

Then can unzip the file.

Connecting with [NT AUTHORITYSYSTEM] in older versions of SQL Server

D:PSTools>psexec -i -s “C:Program Files (x86)Microsoft SQL Server100ToolsBinnVSShellCommon7IDESsms.exe”

D:PSTools>psexec -i -s “C:Program FilesMicrosoft SQL Server100ToolsBinnSQLCMD.exe”

After applying CU8 for SQL 2012 SP2 @@Servername was null 

Somehow ended up in condition of no entry in sys.servers for server_id 0

select * from sys.servers where server_id=0

This returned 0 rows.  Can add the local server with:

sp_addserver ‘<servername>’, local

Then had to restart the server for it to take effect

If it will be a while before can reboot, then suggest using 

serverproperty(‘ServerName’)

First verify the “Distribute Transaction Coordinator” Service is running on both database server computer and client computers

1.      Go to “Administrative Tools > Services”

2.      Turn on the “Distribute Transaction Coordinator” Service if it is not running

If it is running and client application is not on the same computer as the database server, on the computer running database server

1.      Go to “Administrative Tools > Component Services”

2.      On the left navigation tree, go to 

“Component Services > Computers > My Computer”  (you may need to double click and wait as some nodes need time to expand)

3.      Right click on “My Computer”, select “Properties”

4.      Select “MSDTC” tab

5.      Click “Security Configuration”

6.      Make sure you check “Network DTC Access”, “Allow Remote Client”, “Allow Inbound/Outbound”, “Enable TIP”  (Some option may not be necessary, have a try to get your configuration)

7.      The service will restart

8.      BUT YOU MAY NEED TO REBOOT YOUR SERVER IF IT STILL DOESN’T WORK

On your client computer use the same above procedure to open the “Security Configuration” setting, make sure you check “Network DTC Access”, “Allow Inbound/Outbound” option, restart service and computer if necessary.

On you SQL server service manager, click “Service” dropdown, select “Distribute Transaction Coordinator”, it should be also running on your server computer.

The setup routines for the Oracle ODBC client in instantclient64_12_1 could not be loaded. System error code 126: The denoted module was not found. (C:Program FilesOracleinstantclient64_12_1SQLORAS32.DLL).

Download and install the Microsoft Visual C++ 2010 Redistributable Package:

http://www.microsoft.com/en-us/download/confirmation.aspx?id=14632

The problem is not with the SQLORA dlls, but the modules that those ddls refer to (missing from a default Windows installation).

http://serverfault.com/questions/555972/cannot-create-oracle-odbc-source-on-64bit-windows-7