1 Restore database testing from disk='G:\SQLDATA\Testing.bak' with norecovery

2 Go

3 Restore log testing from disk='G:\SQLDATA\1.trn' with norecovery

4 Go

5 Restore log testing from disk='G:\SQLDATA\2.trn' with recovery, stopat='Sep 4, 2012 7:53:00 PM'

Normalization

Apply the so-called normalization rules to check whether your database is structurally correct and optimal.

First Normal Form (1NF): A table is 1NF if every cell contains a single value, not a list of values. This properties is known as atomic. 1NF also prohibits repeating group of columns such asitem1, item2,.., itemN. Instead, you should create another table using one-to-many relationship.

Second Normal Form (2NF): A table is 2NF, if it is 1NF and every non-key column is fully dependent on the primary key. Furthermore, if the primary key is made up of several columns, every non-key column shall depend on the entire set and not part of it.

For example, the primary key of the OrderDetails table comprising orderID and productID. If unitPrice is dependent only on productID, it shall not be kept in the OrderDetails table (but in the Products table). On the other hand, if the unitPrice is dependent on the product as well as the particular order, then it shall be kept in the OrderDetails table.

Third Normal Form (3NF): A table is 3NF, if it is 2NF and the non-key columns are independent of each others. In other words, the non-key columns are dependent on primary key, only on the primary key and nothing else. For example, suppose that we have a Products table with columns productID (primary key), name and unitPrice. The column discountRate shall not belong to Products table if it is also dependent on the unitPrice, which is not part of the primary key.

Higher Normal Form: 3NF has its inadequacies, which leads to higher Normal form, such as Boyce/Codd Normal form, Fourth Normal Form (4NF) and Fifth Normal Form (5NF), which is beyond the scope of this tutorial.

At times, you may decide to break some of the normalization rules, for performance reason (e.g., create a column called totalPrice in Orders table which can be derived from theorderDetails records); or because the end-user requested for it. Make sure that you fully aware of it, develop programming logic to handle it, and properly document the decision.

Integrity Rules

You should also apply the integrity rules to check the integrity of your design:

Entity Integrity Rule: The primary key cannot contain NULL. Otherwise, it cannot uniquely identify the row. For composite key made up of several columns, none of the column can contain NULL. Most of the RDBMS check and enforce this rule.

Referential Integrity Rule: Each foreign key value must be matched to a primary key value in the table referenced (or parent table).

You can insert a row with a foreign key in the child table only if the value exists in the parent table.

If the value of the key changes in the parent table (e.g., the row updated or deleted), all rows with this foreign key in the child table(s) must be handled accordingly. You could either (a) disallow the changes; (b) cascade the change (or delete the records) in the child tables accordingly; (c) set the key value in the child tables to NULL.

Most RDBMS can be setup to perform the check and ensure the referential integrity, in the specified manner.

----------------------------------------- Physical Architecture -----------------------------------

- The transaction log is used to guarantee the data integrity of the database and for data recovery.

- The transaction log in a database maps over one or more physical files. Conceptually, the log file is a string of log records. Physically, the sequence of log records is stored efficiently in the set of physical files that implement the transaction log.

- The SQL Server Database Engine divides each physical log file internally into a number of virtual log files. Virtual log files have no fixed size, and there is no fixed number of virtual log files for a physical log file. The Database Engine chooses the size of the virtual log files dynamically while it is creating or extending log files. The size or number of virtual log files cannot be configured or set by administrators.

- The only time virtual log files affect system performance is if the log files are defined by small size and growth_increment values. If these log files grow to a large size because of many small increments, they will have lots of virtual log files. This can slow down database startup and also log backup and restore operations. We recommend that you assign log files a size value close to the final size required, and also have a relatively large growth_increment value.

- The transaction log is a wrap-around file. For example, consider a database with one physical log file divided into four virtual log files. When the database is created, the logical log file begins at the start of the physical log file. New log records are added at the end of the logical log and expand toward the end of the physical log. Log truncation frees any virtual logs whose records all appear in front of the minimum recovery log sequence number (MinLSN). The MinLSN is the log sequence number of the

oldest log record that is required for a successful database-wide rollback.

--------------------- Checkpoints and the Active Portion of the Log ----------------------

- Checkpoints flush dirty data pages from the buffer cache of the current database to disk. This minimizes the active portion of the log that must be processed during a full recovery of a database. During a full recovery, the following types of actions are performed:

The log records of modifications not flushed to disk before the system stopped are rolled forward.

All modifications associated with incomplete transactions, such as transactions for which there is no COMMIT or ROLLBACK log record, are rolled back.

Checkpoint OperationA checkpoint performs the following processes in the database:

Writes a record to the log file, marking the start of the checkpoint. Stores information recorded for the checkpoint in a chain of checkpoint log records.

One piece of information recorded in the checkpoint is the log sequence number (LSN) of the first log record that must be present for a successful database-wide rollback. This LSN is called the Minimum Recovery LSN (MinLSN).

If the database uses the simple recovery model, marks for reuse the space that precedes the MinLSN.

Writes all dirty log and data pages to disk.

Writes a record marking the end of the checkpoint to the log file.

Writes the LSN of the start of this chain to the database boot page.

The checkpoint records also contain a list of all the active transactions that have modified the database.

Activities That Cause a CheckpointCheckpoints occur in the following situations:

A CHECKPOINT statement is explicitly executed. A checkpoint occurs in the current database for the connection.

A minimally logged operation is performed in the database; for example, a bulk-copy operation is performed on a database that is using the Bulk-Logged recovery model.

Database files have been added or removed by using ALTER DATABASE.

An instance of SQL Server is stopped by a SHUTDOWN statement or by stopping the SQL Server (MSSQLSERVER) service. Either action causes a checkpoint in each database in the instance of SQL Server.

An instance of SQL Server periodically generates automatic checkpoints in each database to reduce the time that the instance would take to recover the database.

A database backup is taken.

An activity requiring a database shutdown is performed. For example, AUTO_CLOSE is ON and the last user connection to the database is closed, or a database option change is made that requires a restart of the database.

------------------------------ Write-Ahead Transaction Log -------------------------------

- SQL Server uses a write-ahead log (WAL), which guarantees that no data modifications are written to disk before the associated log record is written to disk. This maintains the ACID properties for a transaction.

- SQL Server maintains a buffer cache into which it reads data pages when data must be retrieved. Data modifications are not made directly to disk, but are made to the copy of the page in the buffer cache. The modification is not written to disk until a checkpoint occurs in the database, or the modification must be written to disk so the buffer can be used to hold a new page. Writing a modified data page from the buffer cache to disk is called flushing the page. A page modified in the cache, but not yet written to disk, is called a dirty page.

- At the time a modification is made to a page in the buffer, a log record is built in the log cache that records the modification. This log record must be written to disk before the associated dirty page is flushed from the buffer cache to disk. If the dirty page is flushed before the log record is written, the dirty page creates a modification on the disk that cannot be rolled back if the server fails before the log record is written to disk. SQL Server has logic that prevents a dirty page from being flushed before the associated log record is written. Log records are written to disk when the transactions are committed.

-- Log File Architecture in SQL Server

Whenever any query is processed, the data will be passed to Data file. Below is the process how a query is processed in SQL Server/ Importance of Log File Architecture:

Database has Data file and Log file. The query statement is passed to the buffer cache and log cache.

The data in the buffer cache is called as Dirty Data or Dirty Blocks.

Buffer cache contains the dirty data (the updated data corresponding to the query given in the application).

The process of writing the data from buffer cache to the data files of the database in the form of chuncks iscalled as Checkpoint Process.

Each chunck contains 512 KB.

The query is written into the log file from the log cache.

If any type of failure occurs while writing data to the data file, then the query in the log file is executed at the last commit transaction processed (refer commit process down) and the remaining data is written to the database whenever we start the server.

This process of writing data to the database after a failure from the log file is called as Recovery.

Procedure Cache contains the execution plan.

Context Cache contains the data of the stored procedure.

Server Level Data Structure contains the Server level information.

Commit Process:

o As soon as commit statement is written to the log file it throws a token to the user that commit is completed successfully (Ex. 1 row affected), this process is called as Commit Process.

Types of isolation levels in SQL Server

Read Committed

SQL Server acquires a share lock while reading a row into a cursor but frees the lock immediately after reading the row. Because shared lock requests are blocked by an exclusive lock, a cursor is prevented from reading a row that another task has updated but not yet committed. Read committed is the default isolation level setting for both SQL Server and ODBC.

Read Uncommitted

SQL Server requests no locks while reading a row into a cursor and honors no exclusive locks. Cursors can be populated with values that have already been updated but not yet committed. The user is bypassing all of the locking transaction control mechanisms in SQL Server.

Repeatable Read

SQL Server requests a shared lock on each row as it is read into the cursor as in READ COMMITTED, but if the cursor is opened within a transaction, the shared locks are held until the end of the transaction instead of being freed after the row is read. So phantom rows are This has the same effect as specifying HOLDLOCK on a SELECT statement.

(Phantom read:Phantom reads occurs when an insert or delete action is performed against a row that is being read by a transaction.The second transaction read shows a row that did not exist in the original read as the result of an insertion by a different transaction or due to deletion operation some rows doesn’t appear)

Serializable

In serializable read phantom reads are not allowed because while the first transaction is in progress other transaction wont execute.

Snapshot

SQL Server requests no locks while reading a row into a cursor and honors no exclusive locks. Cursor is populated with the values as of the time when the transaction first started. Scroll locks are still requested regardless of use of snapshot isolation.

Read uncommitted example:

Uncommitted Read allows your transaction to read any data that is currently on a data page, whether that has been committed or not. For example,another user might have a transaction in progress that has updated data, and even though it’s holding exclusive locks on the data, your transaction can read it anyway.

If we execute the select query before the update transaction gets committed,it will not

wait for the update transaction to commits.Query will be executed immediately without any time lapse.

Read Committed example

Read committed allows your transaction to read only if the data is committed.Read Committed operation never reads data that another application has changed but not yet committed.

If we execute the select query before the update transaction gets committed,it will wait till the update transaction gets committed.

Repeatable Read example :

In Repeatable Read issuing the same query twice within a transaction will not make any changes to data values made by another user’s transaction.Repeatable Read allows phantom reads(Data getting changed in current transaction by other transactions is called Phantom Reads).So phantom rows will appear.

While the transaction(first query) is in progress,repeatable read allows another

transaction(second query) to execute.It means it allow phantom reads.So second transaction(second query),need not wait till first transaction(first query) completes.Here values will be added before first query completes.

Serializable example : The Serializable isolation level adds to the properties of Repeatable Read by ensuring that if a query is reissued, rows will not have been added in the table. In other words, phantoms will not appear if the same query is issued twice within a transaction.

While the transaction(first query) is in progress,serializable read does not allow another transaction(second query),It means it don’t allow phantom reads.So second transaction(second query), must wait till first transaction(first query) completes.Here values will be added only after first query completes.

snapshot example : To use the snapshot isolation level you need to enable it on the database by running the following command

ALTER DATABASE DBnameSET ALLOW_SNAPSHOT_ISOLATION ON

What is lock escalation?

Lock escalation is the process of converting a lot of low level locks (like row locks, page locks) into higher level locks (like table locks). Every lock is a memory structure too many locks would mean, more memory being occupied by locks. To prevent this from happening, SQL Server escalates the many fine-grain locks to fewer coarse-grain locks. Lock escalation threshold was definable in SQL Server 6.5, but from SQL Server 7.0 onwards it’s dynamically managed by SQL Server.

MS SQL Server architecture.

The major components of SQL Server are:

1. Relational Engine2. Storage Engine

3. SQL OS

Now we will discuss and understand each one of them.

1) Relational Engine: Also called as the query processor, Relational Engine includes the components of SQL Server that determine what your query exactly needs to do and the best way to do it. It manages the execution of queries as it requests data from the storage engine and processes the results returned.

Different Tasks of Relational Engine:

1. Query Processing2. Memory Management

3. Thread and Task Management

4. Buffer Management

5. Distributed Query Processing

2) Storage Engine: Storage Engine is responsible for storage and retrieval of the data on to the storage system (Disk, SAN etc.). to understand more, let’s focus on the concepts.

When we talk about any database in SQL server, there are 2 types of files that are created at the disk level – Data file and Log file. Data file physically stores the data in data pages. Log files that are also known as write ahead logs, are used for storing transactions performed on the database.

Let’s understand data file and log file in more details:

Data File: Data File stores data in the form of Data Page (8KB) and these data pages are logically organized in extents.

Extents: Extents are logical units in the database. They are a combination of 8 data pages i.e. 64 KB forms an extent. Extents can be of two types, Mixed and Uniform. Mixed extents hold different types of pages like index, system, data etc (multiple objects). On the other hand, Uniform extents are dedicated to only one type (object).

Pages: As we should know what type of data pages can be stored in SQL Server, below mentioned are some of them:

Data Page: It holds the data entered by the user but not the data which is of type text, ntext, nvarchar(max), varchar(max), varbinary(max), image and xml data.

Index: It stores the index entries.

Text/Image: It stores LOB ( Large Object data) like text, ntext, varchar(max), nvarchar(max), varbinary(max), image and xml data.

GAM & SGAM (Global Allocation Map & Shared Global Allocation Map): They are used for saving information related to the allocation of extents.

PFS (Page Free Space): Information related to page allocation and unused space available on pages.

IAM (Index Allocation Map): Information pertaining to extents that are used by a table or index per allocation unit.

BCM (Bulk Changed Map): Keeps information about the extents changed in a Bulk Operation.

DCM (Differential Change Map): This is the information of extents that have modified since the last BACKUP DATABASE statement as per allocation unit.

Log File: It also known as write ahead log. It stores modification to the database (DML and DDL).

Sufficient information is logged to be able to: o Roll back transactions if requested

o Recover the database in case of failure

o Write Ahead Logging is used to create log entries

Transaction logs are written in chronological order in a circular way

Truncation policy for logs is based on the recovery model

SQL OS: This lies between the host machine (Windows OS) and SQL Server. All the activities performed on database engine are taken care of by SQL OS. It is a highly configurable operating system with powerful API (application programming interface), enabling automatic locality and advanced parallelism. SQL OS provides various operating system services, such as memory management deals with buffer pool, log buffer and deadlock detection using the blocking and locking structure. Other services include exception handling, hosting for external components like Common Language Runtime, CLR etc.

Pages and Extents

Q. What is a page in database systems and tell me something about pages?

Ans:

The fundamental unit of data storage in SQL Server is the page.

Page size is 8kb means 128 pages = 1 MB.

Page starts with the header of 96 bytes that is used to store page number, page type, the amount of free space on the page, and the object id that owns the page. The maximum size of a single row on a page is 8060 bytes. But this restriction is relaxed for tables which are having varchar, nvarchar, Varbinary, Taxt or Image columns.

Q. Any idea what is “ROW_OVERFLOW_DATA allocation unit”?

Ans:

When the total row size of all fixed and variable columns in a table exceeds the 8,060 byte limitation, SQL Server dynamically moves one or more variable length columns to pages in the ROW_OVERFLOW_DATA allocation unit.

This is done whenever an insert or update operation increases the total size of the row beyond the 8060 byte limit. When a column is moved to a page in the ROW_OVERFLOW_DATA allocation unit, a 24-byte pointer on the original page in the IN_ROW_DATA allocation unit is maintained. If a subsequent operation reduces the row size, SQL Server dynamically moves the columns back to the original data page.

Q. Can you briefly describe about EXTENT?

Ans:

An extent is eight physically contiguous pages, or 64 KB means 16 Extents= 1 MB.

There are two types of Extents. Uniform Extents and Mixed Extents.

Uniform extents are owned by a single object;

Mixed extents are shared by up to eight objects

Q. What are the different Types of Pages available?

Ans:

GAM and SGAM (Global Allocation Map & Shared GAM):

GAM: Extents have been allocated: 1 – Free space 0 – No space

SGAM: Mixed Extents have been allocated: 1 – Free Space + Mixed Extent and 0 – No space

Each GAM / SGAM covers 64000 extents – 4 GB

PFS (Page Free Space): Percentage of free space available in each page in an extent.

DCM (Differential Changed Map): This tracks the extents that have changed since the last BACKUP DATABASE statement. 1 – Modified, 0 – Not modified

BCM (Bulk Changed Map): This tracks the extents that have been modified by bulk logged operations since the last BACKUP LOG statement. 1 – Modified, 0 – Not modified (Used only in bulk logged Recovery model)

In each data file pages are arranged like below

Along with that we have three different data pages

Data

Index

Text/ Image (LOB, ROW_OVERFLOE, XML)

Files and File Groups

Q. Have you ever heard the word “Files” or “File Groups” in SQL Server?

Ans:

Files: There are three types, Primary- .mdf, Secondary – .ndf and Log files – .ldf

File Groups: There are two, Primary File Group – All system tables and User Defined – Depends

All secondary files and user defined file groups are created to optimize the data access and for partitioning the tables.

Q. What are the advantages and disadvantages over using filegroups?

Ans:

Advantages:

Using filegroups, you can explicitly place database objects into a particular set of database files. For example, you can separate tables and their nonclustered indexes into separate filegroups. This can improve performance, because modifications to the table can be written to both the table and the index at the same time. This can be especially useful if you are not using striping with parity (RAID-5).

Another advantage of filegroups is the ability to back up only a single filegroup at a time. This can be extremely useful for a VLDB, because the sheer size of the database could make backing up an extremely time-consuming process.

Yet another advantage is the ability to mark the filegroup and all data in the files that are part of it as either read-only or read-write.

Disadvantages

The first is the administration that is involved in keeping track of the files in the filegroup and the database objects that are placed in them.

The other is that if you are working with a smaller database and have RAID-5 implemented, you may not be improving performance.

Transaction log Architecture

Q. Can you talk about “Transactionlog” Logical and Physical architecture?

Ans:

“Transactionlog” Logical Architecture:

Each log record is identified by a unique number called LSN (Log Sequence Number). A log record contains the LSN, TransactionID to which it belongs and data modification record.

Data modification record: It’s either operation performed or before and after data image

When recorded “Operation Performed”

Transaction committed – Logical Operation is permanently applied to the data

Transaction rollback – Reverse Logical Operation is applied to the data.

When Recorded “Before and After Data Image”

Transaction committed – Applied the after transaction image

Transaction rollback – Applied the before transaction image

“Transactionlog” Physical Architecture:

The transaction log is used to guarantee the data integrity of the database and for data recovery.

The SQL Server Database Engine divides each physical log file internally into a number of virtual log files. Virtual log files have no fixed size, and there is no fixed number of virtual log files for a physical log file.

The only time virtual log files affect system performance is if the log files are defined by small size and growth_increment values. If these log files grow to a large size because of many small increments, they will have lots of virtual log files. This can slow down database startup and also log backup and restore operations.

Q. What are the CheckPoints in SQL Server database?

Ans:

Checkpoints flush dirty data pages from the buffer cache of the current database to disk. This minimizes the active portion of the log that must be processed during a full recovery of a database. During a full recovery, the following types of actions are performed:

The log records of modifications not flushed to disk before the system stopped are rolled forward.

All modifications associated with incomplete transactions, such as transactions for which there is no COMMIT or ROLLBACK log record, are rolled back.

Before a database backup, the Database Engine automatically performs a checkpoint so that all changes to the database pages are contained in the backup. Also, stopping a server issues a checkpoint in each database on the server.

Q. What is an Active Log?

Ans:

The section of the log file from the MinLSN to the last-written log record is called the active portion of the log, or the active log. This is the section of the log required to do a full recovery of the database. No part of the active log can ever be truncated. All log records must be truncated from the parts of the log before the MinLSN.

Q. What is “Write Ahead Transaction Log”?

Ans:

SQL Server uses a write-ahead log (WAL), which guarantees that no data modifications are written to disk before the associated log record is written to disk.

Data modifications are not made directly to disk, but are made to the copy of the page in the buffer cache. The modification is not written to disk until a checkpoint occurs in the database. A page modified in the cache, but not yet written to disk, is called a dirty page. The internal process that actually goes on:

1. Copy of the data pages are pulled and placed in buffer cache2. Applied the operation on the pages that are on buffer cache

3. Write the log record details (Pages modified) to Disk

4. Write / flush /apply the page to the disk

If step 4 happens before the step 3 then rollback is impossible. SQL Server takes the responsibility of writing the log details to disk before flushing the dirty pages.

Memory Management Architecture

Q. Can you describe SQL Server Memory Architecture?

Ans:

SQL Server dynamically acquires and frees memory as required. Typically, an administrator need not have to specify how much memory should be allocated to SQL Server, although the option still exists and is required in some environments.

SQL Server supports Address Windowing Extensions (AWE) allowing use of physical memory over 4 gigabytes (GB) on 32-bit versions of Microsoft Windows operating systems. This feature is deprecated from Dinali 2012.

SQL Server tries to reach a balance between two goals:

Keep the buffer pool from becoming so big that the entire system is low on memory. Minimize physical I/O to the database files by maximizing the size of the buffer pool.

Q. Do you have any idea about Buffer Management?

Ans:

A buffer is a 8kb size in memory. To reduce the I/O operations from database to disk buffer manager use the buffer cache. BM gets the data from database to buffer cache and modifies the data and the modified page is sent back to the disk

The buffer manager only performs reads and writes to the database. Other file and database operations such as open, close, extend, and shrink are performed by the database manager and file manager components.

Q. Explain effects of Min and Max memory configuration options

Ans:

The min server memory and max server memory configuration options establish upper and lower limits to the amount of memory used by the buffer pool of the Microsoft SQL Server Database Engine. The buffer pool starts with only the memory required to initialize. As the Database Engine workload increases, it keeps acquiring the memory required to support the workload. The buffer pool does not free any of the acquired memory until it reaches the amount specified in min server memory. Once min server memory is reached, the buffer pool then uses the standard algorithm to acquire and free memory as needed. The only difference is that the buffer pool never drops its memory allocation below the level specified in min server memory, and never acquires more memory than the level specified in max server memory.

Thread and Task Architecture

Q. Can you describe how SQL Server handles Batch or Task Scheduling?

Ans:

Each instance must handle potentially thousands of concurrent requests from users. Instances of SQL Server use Microsoft Windows threads, or if configured, they use fibers, to manage these concurrent tasks efficiently. This includes one or more threads for each server Net-Library, a network thread to handle network I/O, and a signal thread for communicating with the Service Control Manager.

Understanding Scheduling: Each instance of SQL Server has an internal layer (SQL OS/Kernel) that implements an environment similar to an operating system. This internal layer is used for scheduling and synchronizing concurrent tasks without having to call the Windows kernel.

Connection: A connection is established when the user is successfully logged in. The user can then submit one or more Transact-SQL statements for execution. A connection is closed when the user explicitly logs out, or the connection is terminated.

Batch: An SQL batch is a set of one or more Transact-SQL statements sent from a client to an instance of SQL Server for execution.

Task: A task represents a unit of work that is scheduled by SQL Server. A batch can map to one or more tasks.

Windows thread: Each Windows thread represents an independent execution mechanism.

Fiber: A fiber is a lightweight thread that requires fewer resources than a Windows thread. One Windows thread can be mapped to many fibers.

Worker thread: The worker thread represents a logical thread (Task) in SQL Server that is internally mapped (1:1) to either a Windows thread or, if lightweight pooling is turned ON, to a fiber. The mapping can be done till the free worker threads available. (Parameter: Max worker Threads)

Thread and Fiber Execution: Microsoft Windows uses a numeric priority system that ranges from 1 through 31 to schedule threads for execution. Zero is reserved for operating system use. When several threads are waiting to execute, Windows dispatches the thread with the highest priority.

By default, each instance of SQL Server is a priority of 7, which is referred to as the normal priority. The priority boost configuration option can be used to increase the priority of the threads from an instance of SQL Server to 13. This is referred to as high priority.

The performance of any instances running at normal priority can be adversely affected. Also, the performance of other applications and components on the server can decline if priority boost is turned on.

Query Processing Architecture

Q. I have submitted a Query to SQL Server from an Application and I got the reply as “data inserted successfully”. Can you demonstrate what the processing done inside?

Ans:

When you submit a query to a SQL Server database, a number of processes on the server go to work on that query. The purpose of all these processes is to manage the system such that it will provide your data back to you, or store it, in as timely a manner as possible, whilst maintaining the integrity of the data.

All these processes go through two stages:

1. Relational Engine

2. Storage Engine

At Client:

1. User enter data and click on submit

2. The client database library transforms the original request into a sequence of one or more Transact-SQL statements to be sent to SQL Server. These statements are encapsulated in one or more Tabular Data Stream (TDS) packets and passed to the database network library

3. The database network library uses the network library available in the client computer to repackage the TDS packets as network protocol packets.

4. The network protocol packets are sent to the server computer network library across the network

At Server:

5. The extracted TDS packets are sent to Open Data Services (ODS), where the original query is extracted.

6. ODS sends the query to the relational engine

7. A connection established to the relational engine and assign a SID to the connection

At Relational Engine:

8. Check permissions and determines if the query can be executed by the user associated with the request

9. Query sends to Query Parser

It checks that the T-SQL is written correctly

Build a Parse Tree \ Sequence Tree

10. Parse Tree sends to Algebrizer

Verifies all the columns, objects and data types Aggregate Binding (determines the location of aggregates such as GROUP BY, and MAX)

Builds a Query Processor Tree in Binary Format

11. Query Processor Tree sends to Optimizer

Based on the query processor tree and Histogram (Statistics) builds an optimized execution plan

Stores the execution plan into cache and send it to the database engine

At Database Engine:

12. Database engine map a batch into different tasks

13. Each task associated with a process

14. Each process assigned with a Windows Thread or a Windows Fiber. The worker thread takes care of this.

15. The Thread/Fiber send to the execution queue and wait for the CPU time.

16. The Thread/Fiber identifies the table location where the data need to be stored

17. Go to the file header, checks the PFS, GAM and GSAM and go to the correct page

18. Verifies the page is not corrupted using Torn page Detection / Check SUM and writes the data

19. If require allocates new pages and stores data on it. Once the data is stored/updated/added in a page, it updates the below locations

PFS Page Header – Checksum / Torn Page Detection (Sector info)

BCM

DCM

20. In this process the

Memory manager take care of allocating buffers, new pages etc, Lock manager take care of allocating appropriate locks on the objects/pages and

releasing them when task completed

Thread Scheduler: schedules the threads for CPU time

I/O manager: Establish memory bus for read/write operations from memory to disk and vice versa

Deadlock\Resource\Scheduler Monitor: Monitors the processes

21. Once the process is completed the result set is submitted to the relational engine and follow the same process for sending back the result set to client application.

22. The connection will be closed and the SID is removed

Majorly used DMV’s are :

• sys.dm_exec_connections - active user connections and internal tasks,• sys.dm_exec_requests - give details on what each connection is actually

performing in SQL Server.• sys.dm_exec_cached_plans - query plan cached.

sys.dm_exec_query_stats - DMV which returns aggregate performance statistics

difference between Sql Server 2005 and 2008 patching

SQL Server 2005:  install Service pack on active node first. the setup will launch the installation on passive nodes parallely.

SQL Server 2008:  install SP on passive nodes, failover and make this active. now install the SP on other side.

Suspect Pages in database

if dbcc command takes long time to run then use msdb..suspect_pages.

If database is huge in size Instead of restoring whole database  we can just restore corrupt pages from latest backup

RESTORE DATABASE yourDBNameHere

PAGE = 'fileid:pageid,fileid:pageid,etc'  -- e.g. 1:5224,1:5225,etc

FROM DISK = 'D:\SQLBackups\yourDbNameHere_lastFull.BAK'

WITH

NORECOVERY

GONote : Run restore with no recovery an then we can restore all t-log backups and of course last one with recovery

restore system databases:

http://msdn.microsoft.com/en-us/library/dd207003.aspx (SQL 2012)

for SQL 2012

steps:

1. insert the SQL server installation media or from command prompt go to the path thathas setup files.

by default the setup files will be in the C:\program files\Microsoft SQL Server\110\setup bootstrap\release

2. execute the below command in cmd prompt

setup /quiet /action = rebuilddatabase /instancename=<instance name> /sqlsystemadminaccounts=<group name> [/sapwd = <sa pswd>] [ /sqlcollation = <collation name>]

post rebuild t task :

restore master, msdb, model db

restore master db:

steps -

1. start the instance in single user mode. http://zarez.net/?p=117

i,e - sqlservr.exe -c -m

2. then restore proper master db backup.

difft status of process:

running - process running already in scheduler

runnable - process in the runnable queue that is waiting for scheduler to allocate

suspended - process waiting on resource

Status Meaning

Background The SPID is running a background task, such as deadlock detection.

Sleeping The SPID is not currently executing. This usually indicates that the SPID is awaiting a command from the application.

Running The SPID is currently running on a scheduler.

Runnable The SPID is in the runnable queue of a scheduler and waiting to get scheduler time.

Sos_scheduler_yield The SPID was running, but it has voluntarily yielded its time slice on the scheduler to allow another SPID to acquire scheduler time.

Suspended The SPID is waiting for an event, such as a lock or a latch.

Rollback The SPID is in rollback of a transaction.

Defwakeup Indicates that the SPID is waiting for a resource that is in the process of being freed. The waitresource field should indicate the resource in question.

Common DMV used -

sys.dm_exec_query_stat

sys.dm_exec_sql_text