Feeds:
Posts
Comments

Sql Server Management Studio provides this a very useful tool to script all database objects into SQL scripts including Data, Indexes, Triggers, Constraints, Logins and Synonyms.

Open SSMS >> Go to a user database >> Right Click >> Tasks >> Generate Scripts…

Generate Script Menu Navigation

Menu Navigation for “Generate Scripts” in SSMS

This is a very useful tool with many customization options. It allows you to script definitions of:

  1. Tables
  2. Views
  3. Stored Procedures
  4. User-Defined Functions
  5. Users
  6. Database Roles
  7. Synonyms
  8. Schemas

And if you go to “Advanced” options we can enable:

  1. Database Creation
  2. Indexes
  3. Statistics
  4. Triggers
  5. Primary Key, Foreign Key and Unique Constraints
  6. Object Level Permissions
  7. Data
  8. … and many more (just check out the tool, its a valuable tool)

For this post, I will try to script out a sample database (DBADB) and some of its objects.

Step 1: When you open the tool from the path above this is the first (standard) welcome screen:

Welcome Screen - Generate Scripts

Welcome Screen – Generate Scripts

Click Next to see the list of objects types that could be selected.

Step 2: Choose Objects screen allows you to

  • Script entire database and all database objects
  • Select specific database objects
    • Tables
    • Views
    • Schemas
    • (please note that this is a dynamic list based on the types of database objects available in the selected database )

    Select Objects - Generate Scripts

    Select Objects – Generate Scripts

Step 3: “Set Scripting Options” allows you to specify the location to save the script file and its properties. If you want the file in Unicode or ANSI text. One important point that must be mentioned here is the option to scripts each object into its own script file. This is of great value in certain situations. Also notice the “Advanced” button on the right. That allows you to set more objects that are not listed in the Step 2 screen “Choose Objects”. These are objects like Indexes, Triggers, Statistics, Data, etc. (more listed in the top portion of this post)

Specify Options - Generate Scripts

Specify Options – Generate Scripts

Step 4: “Advanced Options” menu opens when you click on the “Advanced” button in Step 3. This is deserves a special mention as it has a vast number of options available. As seen in the image below, you can set:

  • “DROP and CREATE” for each object
  • Script Data for tables
  • Defaults
  • Logins
  • Users
  • and many more.
Advanced Options - Generate Scripts

Advanced Options – Generate Scripts

Step 5: “Summary” screen show all the options you selected in the previous steps and give you a chance to review and make any changes.

Review the options - Generate Scripts

Review the options – Generate Scripts

Steps 6: “Save or Publish Scripts” screen is where you see the progress. First it gathers a list of all the objects you selected and lists them on the screen and then gathers definition of each objects. You can see the progress as it completes each object.

Progress Report - Generate Scripts

Progress Report – Generate Scripts

On Success, this is what the final screen looks like.

Note: In the “Advanced” options, you can set a flag that allows the process to continue when any errors are encountered. If for some reason an object could not be scripted, it just moves on to the next object in the list  (like in SSIS)

Hope this helps,

SqlTimes

Following are the steps that I follow to set up DB Mirroring between Sql Server 2008 databases on separate servers.

Overview:

  1. Create Sample Database for Mirroring on Principal Server
  2. Create some database objects in the database to test i.e. tables, stored procedures, etc
  3. Create Database Mirroring EndPoints on Principal, Mirror and Witness
  4. CREATE necessary accounts and GRANT permissions.
  5. Prepare Mirroring database
  6. Enable / Set up mirroring.
  7. Create Snapshot database on Mirror database.
  8. Failover:
    1. Test Failover
    2. Force Failover
  9. Server Objects.
  10. Other points.

Server Names:

Initial Instance Role

Domain Service Account

Server Name

Principal

AD\sql1

SalesDB.AD.com

Mirror

AD\sql1

SalesDBFailOver.AD.com

Witness

AD\sqlWitness

WitnessDB.AD.com

Assumptions:

  • Principal, Mirror and Witness services run with domain accounts.
  • All users and application connections to Sql Server are also domain accounts.

Step 1: Create Sample Database for Mirroring on Principal Server

First let’s create a database on Principal server for mirroring. FULL recovery model is required for databases participating in mirroring.

-- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
-- Step 01: CREATE Principal Database.
-- Run on Principal Server
-- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

CREATE DATABASE DBMir
ON
PRIMARY
(
NAME            = N'DBMir_PRIMARY_Data'
, FILENAME       = N'E:\MS SQL\MSSQL_2K8\Play1\MDF\DBMir_Primary_Data.MDF'
, SIZE           = 1024 MB
, MAXSIZE        = 2 GB
, FILEGROWTH = 10
)
LOG ON
(
NAME            = N'DBMir_Log'
, FILENAME       = N'E:\MS SQL\MSSQL_2K8\Play1\LDF\DBMir_Log.LDF'
, SIZE           = 1024 MB
, MAXSIZE        = 2048 MB
, FILEGROWTH = 10
)
GO

--    SET recovery model to FULL
ALTER DATABASE [DBMir]
SET RECOVERY FULL
GO

Step 02: Create some database objects and server level objects to test after failover i.e. logins, tables, stored procedures, etc.

--   sample server level object
USE MASTER
GO

CREATE LOGIN [test] WITH PASSWORD = 'test'
WITH  DEFAULT_DATABASE = [DBMir]
, DEFAULT_LANGUAGE = [us_english]
GO
USE [DBMir]
GO

CREATE USER [test] FOR LOGIN [test]
GO

--  Sample table
CREATE TABLE dbo.Test
(
ID INT NOT NULL PRIMARY KEY IDENTITY(1,1)
, Name   VARCHAR(40)     NULL
, Age    INT             NULL
, Blob   VARCHAR(MAX)    NULL
)
GO

-- Insert a few records, before setting up Mirroring.
INSERT INTO dbo.Test (Name, Age, Blob) VALUES('Name1', 10, REPLICATE(CONVERT(VARCHAR(MAX), 'ac'),10000))
GO 10

Step 03: Create Database Mirroring EndPoints on Principal, Mirror and Witness.

-- Create endpoint on Principal
CREATE ENDPOINT DBMirror_Principal
STATE = STARTED
AS
TCP (LISTENER_PORT = 7022) -- Do not use port 7022 on prod. server
FOR DATABASE_MIRRORING (ROLE = PARTNER)
GO

-- Create endpoint on Mirror
CREATE ENDPOINT DBMirror_Mirror
STATE = STARTED
AS
TCP (LISTENER_PORT = 7023)
FOR DATABASE_MIRRORING (ROLE = PARTNER)
GO

-- Create endpoint on Witness
CREATE ENDPOINT DBMirror_Witness
STATE = STARTED
AS
TCP (LISTENER_PORT = 7024)
FOR DATABASE_MIRRORING (ROLE = WITNESS)
GO

Step 04: CREATE necessary accounts and GRANT permissions

Run on Principal

-- CREATE LOGIN for Witness (service account) on Principal
-- and GRANT CONNECT permission on Principal's EndPoint
CREATE LOGIN [AD\sqlWitness] FROM WINDOWS;
GO
GRANT CONNECT ON ENDPOINT::DBMirror_Principal TO [AD\sqlWitness]
GO

-- CREATE LOGIN for Witness (service account) on Mirror
-- and GRANT CONNECT permission on Mirror's EndPoint
CREATE USER [AD\sqlWitness] FROM WINDOWS;
GO
GRANT CONNECT ON ENDPOINT::DBMirror_Mirror TO [AD\sqlWitness]
GO

-- CREATE LOGIN for Principal/Mirror(same service account on both) on Witness
-- and GRANT CONNECT permission on Witness's EndPoint
CREATE LOGIN [AD\sql1] FROM WINDOWS;
GO
GRANT CONNECT ON ENDPOINT::DBMirror_Witness TO [AD\sql1]
GO

Step 05: Prepare Mirroring database

-- Run on Principal
BACKUP DATABASE DBMir TO DISK = N'E:\MS SQL\MSSQL_2K8\Play1\Backup\DBMir_Principal.BAK'
GO

BACKUP LOG DBMir TO DISK = N'E:\MS SQL\MSSQL_2K8\Play1\Backup\DBMir_Principal.TRN'
GO

-- Copy the database files over to Mirror Instance

-- Run on Mirror
RESTORE DATABASE DBMir FROM DISK = N'E:\MS SQL\MSSQL_2K8\Play2\Backup\DBMir_Principal.BAK'
WITH MOVE 'DBMir_Principal_Data' TO 'E:\MS SQL\MSSQL_2K8\Play2\MDF\DBMir_Mirror.MDF'
, MOVE 'DBMir_Log' TO  'E:\MS SQL\MSSQL_2K8\Play2\LDF\DBMir_Mirror_Log.LDF'
, NORECOVERY
, REPLACE
GO
RESTORE LOG DBMir FROM DISK = N'E:\MS SQL\MSSQL_2K8\Play2\Backup\DBMir_Principal.TRN'
WITH NORECOVERY
GO

Step 06: Enable / Set up mirroring

-- Run on Mirror: Inform Mirror about Principal (first step)
ALTER DATABASE DBMir
SET PARTNER = 'TCP://SalesDB.AD.com:7022'
GO

-- Run on Principal: Inform Principal about Mirror
ALTER DATABASE DBMir
SET PARTNER = 'TCP://SalesDBFailOver.AD.com:7023'
GO

-- Run on Principal: Inform Principal about Witness
ALTER DATABASE DBMir
SET WITNESS = 'TCP://WitnessDB.AD.com:7024'
GO

Step 07: Create Snapshot database on Mirror database.

-- Create snapshot on Mirror to run sample queries
USE MASTER
GO
CREATE DATABASE DBMir_SnapShot
ON
(
NAME        =   'DBMir_Primary_Data'
, FILENAME   =   'E:\MS SQL\MSSQL_2K8\Play2\MDF\DBMir_SnapShot2.DS'
)
AS  SNAPSHOT OF DBMir
GO

SELECT COUNT(*) FROM dbo.Test
GO

Step 08: Failover

If you want to test the cussecc of failover in our environment use the following FAILOVER command.

-- To test FailOver, run the following query on Principal
-- Smooth failover happens. If there are any SQL Logins,
-- To map orphan users, run sp_change_users_login on Mirror
ALTER DATABASE DBMir
SET PARTNER FAILOVER
GO

But if the Principal goes down and you want to force FAILOVER to
the mirror server, use the following command. This could result in
some data loss.

-- To force failover, when the Principal is unavailable, run this on Mirror
-- Pre-requisite: Principal must be unavailable
ALTER DATABASE DBMir
SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
GO

Step 09:  Server Objects

A note on logins: Make sure logins are created in the same order on the Mirror server as on the Principal server. This way login SID for will remain the same and will not create any orphans.

Any other server level objects could be transferred using an SSIS package designed specifically for this purpose.

Step 10:  Other points

If you want to run any maintenance on one of the servers participating in Mirroring the following commands will come to good use. Lets say, you want to upgrade patches on Principal and Mirror database server.

  1. First, you want to perform a manual FAILOVER [from Principal to Mirror]
  2. Suspend DB mirroring [stop any data flow from new Principal to new Mirror]
  3. Upgrade original Principal Server
  4. Bring Principal up and running
  5. Resume DB Mirroring to bring previous Principal (now Mirror) up to date.
  6. Perfom another manual FAILOVER to the newly upgraded Mirror (original Principal).
  7. Suspend Mirroring
  8. Upgrade Mirror (original)
  9. Bring it back up.
  10. Resume DB Mirroring.

To perform all the above steps, the following commands will be useful.

-- To drop DB Mirroring
ALTER DATABASE DBMir
SET PARTNER OFF      -- to DROP DB Mirroring
GO

-- To re-establish DB Mirroring
ALTER DATABASE DBMir
SET PARTNER ON
GO

-- To temporarily suspend mirrorring
ALTER DATABASE DBMir
SET PARTNER SUSPEND
GO

-- To resume, suspended mirroring
ALTER DATABASE DBMir
SET PARTNER RESUME
GO

Hope this helps,
_Sqltimes

When designing VLDBs for large transactional volume, I keep these design techniques for better scalability and performance. Details on each of these points will come in future.

  • Processor related:
    1. MAX DEGREE OF PARALLELISM  and MAXDOP
    2. COST THRESHOLD FOR PARALLELISM
    3. Soft-NUMA
  • Memory
    1. /PAE, /AWE, /3GB (not needed for 32 bit machines)
    2. Lock Pages in Memory
    3. MAX/MIN SERVER MEMORY
  • FileGroups and Partitioning:
    1. Multiple FG & Files
    2. No data in Primary FG (for online restore)
    3. Use Table Partitions
    4. Allocate large file size initially for MDFs and NDFs
  • Indexes and related tasks:
    1. Covered Indexes
    2. Separate nCI and CI
    3. Online index rebuild
    4. Filtered Indexes
    5. Indexed Views (Automatic Query Substitution)
    6. Fill Factor and Pad Index
    7. Update Stats regularly
  • Disks:
    1. Disk Partition Alignment
    2. Separate disks for os/binaries, sysDB, TempDB, MDF, LDF and BAK file locations
    3. RAIO 10
  • Maintenance:
    1. Stripe Backup
    2. SET PAGE_VERIFY CHECKSUM + BACKUP with CHECKSUM + RESTORE VERIFYONLY WITH CHECKSUM
    3. DBCC CHECKDB Optimization
    4. Archiving

Hope this helps,

_SqlTimes

Today I learned about a new instance level option, its called Query Governor. Looks like its been an available feature for a while, but I never heard of it before. This setting allows you to prevent any queries running longer than a predetermined set value. Any query that has a running cost value more that a set number (Cost measured in seconds).

You can set it two ways. T-sql and SSMS.

  1. T-Sql: Since this option is an advanced option, first we must set ‘show advanced options’. Then RECONFIGURE to be able to set ‘query governor cost limit’ value

USE MASTER
go

EXEC sp_configure 'show advanced options', 1
GO

RECONFIGURE
GO

SELECT * FROM sys.configurations
WHERE name = 'query governor cost limit'
GO

Settings value before:

Query governor cost limit settings before

Query governor cost limit (before)

USE MASTER
go

EXEC sp_configure 'query governor cost limit' , 100   -- 100 seconds
GO

RECONFIGURE
GO

SELECT * FROM sys.configurations
WHERE name IN ('query governor cost limit')

EXEC sp_configure 'show advanced options', 0
GO

RECONFIGURE
GO

Settings value after:

Query governor After

Query governor cost limit (after)

Also, you can set this value per connection using SET command:

SET query_governor_cost_limit 100

2: Right click on server >> properties >> Connections >> Check box (Use query governor to prevent long running queries)

SSMS_Query_Governor

Query Governor in SSMS

Points to keep in mind:

  1. Before you activate ‘query governor’ setting in your production environment, get an estimate of the cost of queries on your production system.

Hope this helps, _SqlTimes

Since Sql Server 2005, High Availability (HA) has become very easy to implement in a Sql Server environment. Also, starting Sql 2005, there are 4 methods to implement HA.

  • Failover Clustering
  • Database Mirroring
  • Replication
  • Log Shipping

Though, Failover clustering still is the most popular option, my guess is the other options might make it a more level field going forward.

In the following matrix, I compare some features of each HA option in one table. This gives a good comparison picture of the features available in each option.

Property \ Feature FailoverClustering DB Mirroring Replication Log Shipping
Server Level Yes No No No
Database Level No Yes Yes Yes
Automatic Failover Yes Yes (Only HA Option) No No
Automatic Failure Detection Yes Yes (Only in HA option) No No
Hot, Warm or Cold standby Hot Hot and Warm Options Warm Warm
Server Level Objects Failover Yes (Automatic) Manual Manual Manual
Is data on Failover available for queries while the Primary server is running? No Yes (use Database Snapshots) Yes Yes (Standby Mode)
Are changes allowed at Failover location? No No Yes (Merge and TRN Replication with updating subscribers) No
Is Main and Failover server in a 1-1 relationship? Yes Yes Not Required Not Required
Is 1-Many relationship possible between the Main and Failover servers? No No Yes Yes
Is Many-1 relationship possible between Main and Failover server? No No Yes No
Is Automatic Application redirection possible after failover? Yes Yes No No
Recovery model required for the participating databases? Any FULL ANY FULL & BULK
Can you filter what data is sent to the Failover server? No No Yes No
Where does the logic HA reside? OS + Sql Sql Replication Agents (they run outside Sql Server Sql Agents (Run outside Sql Server)
If you want a reports server, what is the best solution? Not Possible Works, but needs constant refresh of the Snapshot database for latest data. Best Option. Works, but users connections need to be kicked out, when new log is applied.
Best solution if the Main and Failover server are separated by long distance? Not good. Works, but not recommended. Works, but with high latency Best Option. (Log compression reduces latency significantly.

Note: Please know that this is not all the features, these are just he ones I could think of off the top of my head. If you add your comments below, I can add them to the list.

Hope it helps,

_Sql Times

Recently, I used this very powerful backup method and have seen significant improvement in backup speed. So I wanted to share it with everyone.

When I did backups, I used to take entire backup to one backup disk location using the standard BACKUP command shown below. If the database is large the backup process could take longer.

BACKUP DATABASE AdventureWorks
TO DISK =N'H:\Backups\AdventureWorks\AdW_01012011.BAK'
WITH STATS = 10

Sql Server backup process is very scalable. The only limitation to it is the speed of the backup device, i.e. how fast it can read/write data. So even if you have a RAID disk drive, its speed is limited. And when you have a large database ranging more than 500 GB to multiple TB’s, FULL backups can take much longer to complete.

So stripe backup can help you cut the backup time by many folds. If you have multiple drives attached to the Server, then we could essentially stripe the backup to separate disks and take advantage of the speed of multiple hardware devices to cut short the backup time. Backup process makes sure of stripe, almost, equal amount of data to each location.

BACKUP DATABASE AdventureWorks
TO DISK =N'H:\Backups\AdventureWorks\AdW_01012011_1.BAK'
, DISK = N'I:\Backups\AdventureWorks\AdW_01012011_2.BAK'
, DISK = N'J:\Backups\AdventureWorks\AdW_01012011_3.BAK'
WITH STATS = 10

Note: In some cases, Backup Striping could cause complexity to existing BACKUP/RESTORE procedures. Now you have to remember where each part of the backup file is located, so this technique is not for everyone. Its only for large databases where the benifit our weighs the complexity.

Thought not very popular we could do the same for BACKUP LOG command, as shown below:

BACKUP LOG AdventureWorks
TO DISK =N'H:\Backups\AdventureWorks\AdW_01012011_1.TRN'
, DISK = N'I:\Backups\AdventureWorks\AdW_01012011_2.TRN'
, DISK = N'J:\Backups\AdventureWorks\AdW_01012011_3.TRN'
WITH STATS = 10

Hope this helps,
_SqlTimes

In previous two posts, (comparison with HA and other features) we looked at the new features compatibility with other existing features like Replication, Database Mirroring, Database Snapsho, etc.. Now we look at their compatibility with each other.

  • Can you configure FILESTREAM filegroup on a database set of Compression?
  • Is Compression allowed on a database encrypted with TDE?
  • Can you create FILESTREAM filegroups on a database encrypted with TDE?

Lets look at the matrix below for answers:

Compression

FILESTREAM

TDE

Compression

1

NTFS Only

N

FILESTREAM

NTFS Only

1

N

TDE

N

N

1

As you can see, TDE is not compatible with either Compression or FILESTREAM. A database set of Compression cannot be encrypted with TDE and vice versa. Since Compression requires Disk Cluster size to be 4096 bytes you cannot compress FILESTREAM data. For FILESTREAM data, the recommended Disk Cluster is 64K. I would recommend any one implementing FILESTREAM to read Paul S. Randal’s (SQLskills.com) article on MSDN

“The recommendation for using FILESTREAM is that the individual units of BLOB data be 1 MB in size or higher. If this is the case, it is recommended that the NTFS cluster size for the FILESTREAM data container volume is set to 64 KB to reduce fragmentation. This must be done manually as the default for NTFS volumes up to 2 terabytes (TB) is 4 KB. This can be done using the /A option of the format command. For example, at a command prompt type:

          format F: /FS:NTFS /V:MyFILESTREAMContainer /A:64K

Why is it this way and all other implementation details will be covered in future articles.

Hope this helps,
_SqlTimes

Follow

Get every new post delivered to your Inbox.