1.
SQL Server- Internal Processes
Sunil Kumar Anna

2.
 First of all, the service stops and before the service stops,
 Checkpoint is issued on all databases
 Check for the jobs that are running and stop them
 Release the locks on database files to Operating System
 Release the memory used by SQL Server instance
 Flush the metadata collected for DMV’s and DMF’s
 Record an event in default trace and event viewer regarding the SQL Server instance shutdown
 During the starting of SQL Server service,
 The service is authenticated by verifying the credentials provided in the logon account and the
service is started.
 Startup parameters (master database data file path, log file path and error log file path, etc… if
any) are verified
 The port on which SQL server is listening is opened.
 Memory is allocated
 Read master database metadata for information about user databases
 Attach all the user database
 Undergo database recovery phases (Analysis, redo and undo phases.)
 Obtain lock on the database files
 tempdb files are allocated based on the initial size settings and other setting like collation are
copied from model database.
 An entry to default trace is recorded about the start of SQL Server instance
 All the events are recorded to SQL Server log file and event viewer
 Accept connections to databases
 Start the metadata collection for DMV’s and DMF’s
 Recompile Stored Procedures
SQL Server instance restart procedure

3.
Dedicated Admin Connection
WHAT’s THE DIFFERENCE BETWEEN the DAC AND REMOTE DAC?
DAC and Remote DAC are the same feature — the difference is in where you connect to it from. The DAC
is already enabled for local connections. In order to use that from a remote machine, however, we need to
enable remote connections. In either case, only sysadmins can use it, and only one connection can be
made at a time How to Enable the Remote DAC
/* Check for any pending configurations before you start. */
/* Reconfigure applies to EVERYTHING pending. */
SELECT * FROM sys.configurations WHERE value <> value_in_use;
GO
EXEC sp_configure 'remote admin connections', 1;
GO
RECONFIGURE
GO
Microsoft provides since SQL Server 2005 the so-called Dedicated Admin Connection (DAC). With this
connection you are able to log into SQL Server even when you have worker thread starvation or high
memory pressure, because the DAC has its own
 Scheduler
 Memory Node
 TCP Port
inside SQLOS. Therefore SQL Server is able to accept and serve the DAC connection – even in high
sophisticated troubleshooting scenarios like this one. But there is only one available DAC for the whole SQL
Server instance. So let’s start up a new instance of SQL Server Management Studio and log into SQL Server
through the DAC. Please be aware that you don’t connect the Object Explorer through the DAC, because
the DAC isn’t supported for the Object Explorer (but still it works well). You can only use a simple query
window that connects through the DAC
Syntax: admin:<servername> where <servername>

4.
Other way to connect DAC using SQLCMD
Command Parameters:
-A = Specifies DAC connection.
-d = Specifies database name.
-E = Windows Authentication.
-U = SQL Authentication.
-S = Instance Name.
Note
"Make sure that SQL Browser is running..."

5.
Reading Default trace file for SQL Server
What is the default trace? The default trace is enabled by default in SQL Server and is a minimum weight
trace which consists by default of five trace files ( .trc) located in the SQL Server installation directory. The
files are rolled over as time passes.
If it is not enabled, how do we enable it? We can run this script in order to enable the default trace:
select * from sys.traces
What is logged in the Default Trace?
If we open the Default trace file in Profiler and look at the trace definition we will see that events in 6
categories are captured:
 Database,
 Errors and Warnings,
 Full-Text,
 Objects,
 Security Audit and Server.
 Also, all available columns are selected for every sub-event
Import Trace flag into Table
SELECT * INTO trace_table FROM ::fn_trace_gettable('c:my_trace.trc', default)
Go
Select * from trace_table

6.
 Data file auto grow
 Data file auto shrink
 Database mirroring status change
 Log file auto grow
 Log file auto shrink
Database Events
 Errorlog
 Hash warning
 Missing Column Statistics
 Missing Join Predicate
 Sort Warning
Errors and Warnings The Full Text Events
 FT Crawl Aborted
 FT Crawl Started
 FT Crawl Stopped
Object events
 Object Altered
 Object Created
 Object Deleted
Security Audit Events
 Audit Add DB user event
 Audit Add login to server role event
 Audit Add Member to DB role event
 Audit Add Role event
 Audit Add login event
 Audit Backup/Restore event
 Audit Change Database owner
 Audit DBCC event
 Audit Database Scope GDR event (Grant, Deny, Revoke)
 Audit Login Change Property event
 Audit Login Failed
 Audit Login GDR event
 Audit Schema Object GDR event
 Audit Schema Object Take Ownership
 Audit Server Starts and Stops
 create a SQL Server login
 assign read permissions to this user in one of our databases.
https://www.simple-talk.com/sql/performance/the-default-trace-in-sql-server-the-power-of-performance-and-security-
auditing/

7.
The databases undergo recovery phases in two scenarios
 When the SQL server or service is restarted
 When the database is being restored.
There are 3 Phases of Recovery and are based on the last checkpoint in the transaction log.
Phases of Database recovery
Pages in the main memory that have been modified during writing data to disk are marked as "dirty" and
have to be flushed to disk before they can be freed. When a file write occurs, the page backing the
particular block is looked up

8.
Most important SQL Server transaction log myths
 Having multiple online SQL Server transaction log files will increase performance
 The SQL Server transaction log won’t grow if the database is in the Simple recovery model
 A SQL Server transaction log backup will be the same size as the online transaction log itself
 A full or differential database backup clears the online transaction log
 The TRUNCATE TABLE and DROP TABLE commands are not logged into the online transaction log
 My SQL Server is too busy, I don’t want to make SQL Server transaction log backups
 A SQL Server transaction log backup isn’t needed for a point in time restore. A full database backup
is enough
 SQL Server transaction log backups are not needed for successful disaster recovery if the full
database backup is taken daily
 The SQL Server transaction log shrinking will make free space in the online transaction log so I don’t
need to create transaction log backups
SQL Server running DBCC CHECKDB against my databases at Server Startup
When looking at the below screenshot, it’s easy to see why you might be tempted to think that SQL Server
is, indeed, checking your databases as part of the recovery process when it starts up – because SQL Server
is pushing CHECKDB-related output into the logs as part of the startup process. However, SQL Server isn’t
actually running DBCC CHECKDB at startup. Instead, it’s just echoing out information about the last time
the database was successfully checked. Which, in turn, means that there are a couple of lessons to be
learned from this kind of scenario.

9.
Each time that DBCC CHECKDB successfully completes (i.e., detects no errors) against a database, SQL
Server writes the outcome/timestamp of that operation into the database header page of the database in
question. Specifically, it logs this information to page 9, into a value called dbi_dbccLastKnownGood – that
you can query yourself by running DBCC PAGE() as shown below (after switching output to your local
console):
It’s easy to see why you might THINK that SQL Server is running DBCC CHECKDB at startup.
Background / Explanation
Peeking at how SQL Server stores information about the last successful execution of DBCC CHECKDB().
When this information has been written to page 9, SQL Server will ‘echo’ it out when the server starts up –
and as part of the process that SQL Server goes through to spin-up your database. The key thing to note,
however, is that SQL Server is just spitting out the ‘last known good’ timestamp as recorded in page 9.
SQL Server is not, therefore, executing DBCC CHECKDB() – even though that might look like the case at first glance
when reviewing SQL Server Logs.
Executing the CheckDB on the master database will cause
the execution on the mssqlsystemresource database as well.

10.
What happen when I run DBCC CHECKDB
The DBCC CHECKDB create a not user-accessible database snapshot, it must be hidden. This hidden
database snapshot with conventional database snapshots are some small differences. Regular snapshot
corresponds to each data file in the source database is just a snapshot of files, each file must be explicitly
named in the database snapshot is created. DBCC CHECKDB does not allow any user to hide database
snapshot file name specified by the input data files for each database that already exists, but to create an
NTFS alternate streams. You can put this snapshot as a file system hidden files.
Sometimes run in a hidden database snapshot
runs out of space to produce a conflict.
Because the use of existing alternative flow of
data files, database snapshots in the same
location as the data file space. If the database
is checked when there is a heavy work load,
more and more pages are being pushed
snapshot of the database, making rapid
growth. In this case, the database where the
volume, if there is not enough space, then
snapshot space is available, DBCC CHECKDB
error and stop.
In this case, the solution is to create your own
database snapshot. In a sufficient space
volume, and then run DBCC CHECKDB, the
DBCC CHECKDB identify already running
database snapshot, and does not attempt to
create a new snapshot.
If a snapshot created by DBCC CHECKED Once the
consistency check operation is completed, it will be
automatically discarded. Snapshot of the database at
the same time (if necessary), run DBCC CHECKDB the
Filestream the garbage collection process is suspended,
which allows a consistency check operation lasting view
to see any File the Stram data container a FileStream
transaction-level data.

11.
In the above case, the database must be complete, because there is no other active connection changes
to make the destruction of consistency check
 defined database is stored in a non-NTFS file system (in this case, the database snapshot can not
be created because it relies on NTFS sparse file technology)
 Define database is tempdb (tempdb can not create a database snapshot)
 TABLOCK option is defined
If for any reason a database snapshot can not be created the DBCC CHECKDB trying to role lock to get a
transaction-level database persistence view
NOTE:- From SQL Server 2014 onward, alternate streams are not used, although the database snapshot is
created in the same location as the existing database
Database snapshot can not be created under the following conditions:
 create a complete transaction-level, static database view.
 the implementation of the critical systems classification of low-level consistency check.
 the implementation of the distribution database consistency check.
 the implementation of each table in the database consistency check.
The DBCC CHECKDB main steps are as follows:
 the previous steps did not find the error, the following
cross-table consistency check is performed:
 implementation of the service broker metadata
consistency checks.
 perform consistency checks between the various
system categories (catalog).
 Perform consistency check of the index view.
 perform consistency checks of the XML index.
 perform spatial index consistency check.

12.
It’s like Doctor examine your body, but not run bloodwork
TABLERESULTS returns the information in a neat, easy-to-read grid format rather than free-form text.
Database snapshot is not required under the following conditions:
 Define database is a database snapshot
 Define the database is read-only, single-user mode or combined mode
 Service-m command-line options in single-user mode

13.
DBCC CHECKDB ('msdb', REPAIR_ALLOW_DATA_LOSS)
DBCC CHECKDB ('msdb', 'repair_rebuild')
DBCC CHECKDB ('msdb, REPAIR_FAST)
DBCC CHECKTABLE ("backupmediafamily") WITH REPAIR_REBUILD;
DBCC CHECKTABLE ("backupmediafamily") WITH REPAIR_ALLOW_DATA_LOSS;

14.
The first 8 pages of a file are
ways to reduce the database size
 Reducing Index Fragmentation
 Implementing Data Compression
 Removing unused indexes
 Removing Redundant Indexes
 Implementing Filtered Indexes
 Using Appropriate Data Types
 Storing LOB data outside of the database
 Compressing LOB data in the database
 Storing Data in Clustered Columnstore Indexes
 Reducing amount of free space in the database

15.
In the 64-Bit windows each process gets up to 8 TB of address space, Hence there was no need for SQL
Server to leave certain amount of addressable memory for Non-Bpool allocations.
SQL Server calculates the size of RAM during the startup and reserve it , minimum of (reserved space, “Max
server memory”) is used as Bpool.
Similar to 32-Bit SQL Server, there will be memory allocations outside Bpool in 64-Bit SQL Server , which is
called as Non-Bpool allocations.
 Conventional – Normal physical page size (4 / 8KB),memory can be paged, dynamic
 Locked – Normal physical page size (4 / 8KB), Bpool can not be paged, dynamic, Requires
startup account of SQL Server to have “Lock pages in memory” privilege,Memory is
allocated by using Address Windowing Extensions (AWE) API’s
 Large – Large physical page size ( > = 2MB), Non-pageable, static, Memory is committed
at startup,”Max server memory” is recommended, requires startup account of SQL
Server to have “Lock pages in memory” privilege
There are three types of memory model’s in 64-Bit SQL Server.
64-Bit SQL Server memory architecture- till SQL server 2008 R2
Memory calculations in 64-Bit SQL Server are straight forward.
 COM Objects
 SQL Server CLR
 Memory allocated by Linked Server OLEDB Providers and third party DLL’s loaded in SQL Server process
 Extended Stored Procedures:
 Network Packets
 Memory consumed by memory managers. If the memory request is greater than 8 KB and needs
contiguous allocation.
 Backup
 Memory for threads (stack size is 2 MB in 64-BIT SQL )
Who allocates memory outside Bpool?

16.
Max server memory controls only the Bpool, it doesn’t control Non-Bpool allocations, this is the reason for
SQL Server’s memory usage being greater than “Max Server memory”.
Key points:
 When “Lock pages in memory is used” operating system can not page out Bpool, Non-Bpool allocations
can still be paged.
 SP_configure “awe enabled” option doesn’t have any use in 64-Bit SQL Server.
 “Max Server Memory” limits only Bpool, hence SQL Server memory usage will be greater than “Max
server memory”
 If your operating system is windows2003 (Windows2008 is your call) make sure you cap the SQL Server
MAX Server Memory after considering the memory required by other applications, Operating system,
Drivers , SQL Server Non- Bpool allocations etc
64-Bit SQL Server memory architecture- SQL server 2012
SQL Server 2012 memory manager has now clubbed single page allocator and multipage allocator
together as any-size page allocator . As a result, the any-size page allocator now manages allocations
categorized in the past as single page and Multi-Page allocations.
 "max server memory" now controls and includes “Multi pages allocations”.
 In earlier versions of SQL Server CLR allocated memory was outside BPOOL (Max server memory) .
SQL Server 2012 includes SQL CLR allocated memory in "max server memory".
 SQL Server 2012 "max server memory" configuration does not include only the following allocations:
 Memory allocations for thread stacks within SQL Server process
 Memory allocation requests made directly to Windows [Ex: Allocations (Heap,Virtualalloc calls ) from
3rd party Dll’s loaded in SQL Server process , objects created using OLE Automation procedures
(sp_oa) etc]
These changes allow DBA’s to configure and control SQL Server more accurately in accordance with the
memory requirements and using resource governor.

17.
Primary memory consumers in SQL Server
 Buffer pool (BPool) – number 1 consumer
 Plan cache – traditionally number 2 consumer
 Other (log pool, token perm)
 Hosted memory (CLR)
 Fixed memory (fundamental operations of SQL Server, such as connections)
 In-Memory OLTP
 Columnstore
Internals of Checkpoint
Checkpoint is a process that writes current in-memory dirty pages (modified pages) and transaction log
records to physical disk. In SQL Server checkpoints are used to reduce the time required for recovery in
the event of system failure. Checkpoint is regularly issued for each database.
 Log records from log buffer (including the last log record) are written to the disk.
 All dirty data file pages (pages that have been modified since the last checkpoint or since they were
read from disk) are written into the data file from the buffer cache.
 Checkpoint LSN is recorded in the database boot page.
The following set of operations
starts when checkpoint occurs:

18.
 Shutdown initiates a Checkpoint operation on all databases except when Shutdown is not clean
(Shutdown with no wait)
 If the recovery model gets changed from FullBulk-logged to Simple.
 While taking Backup of the Database.
 If your DB is in Simple Recovery model, checkpoint process executes automatically either when the
log becomes 70% full, or based on Server option-Recovery Interval.
 Alter Database command to add or remove a datalog file also initiates a checkpoint.
 Checkpoint also takes place when the recovery model of the DB is Bulk-Logged and a minimally
logged operation is performed.
 DB Snapshot creation
Automatic checkpoint

19.
IT’S QUESTION(S) TIME