1: What is ACID Property?
ACID Properties
When a transaction processing system creates a transaction,
it will ensure that the transaction will have certain characteristics
ATOMICITY
The atomicity property identifies that the transaction is
atomic. An atomic transaction is either fully completed, or is not begun at
all. Any updates that a transaction might affect on a system are completed in
their entirety. If for any reason an error occurs and the transaction is unable
to complete all of its steps, the then system is returned to the state it was
in before the transaction was started. An example of an atomic transaction is
an account transfer transaction. The money is removed from account A then
placed into account B. If the system fails after removing the money from
account A, then the transaction processing system will put the money back into
account A, thus returning the system to its original state. This is known as a
rollback
CONSISTENCY
Data is either committed or roll back, not “in-between”
case where something has been updated and something hasn’t and it will never
leave your database till transaction finished. If the transaction completes
successfully, then all changes to the system will have been properly made, and
the system will be in a valid state. If any error occurs in a transaction, then
any changes already made will be automatically rolled back. This will return
the system to its state before the transaction was started. Since the system
was in a consistent state when the transaction was started, it will once again
be in a consistent state.
ISOLATION
No transaction sees the intermediate results of the current
transaction. We have two transactions both are performing the same function and
running at the same time, the isolation will ensure that each transaction
separate from other until both are finished.
DURABILITY
Once transaction completed whatever the changes made to the
system will be permanent even if the system crashes right after
2: What is Certificate?
A certificate is a digitally signed security object that
contains a public (and optionally a private) key for SQL Server.
You can use externally generated certificates or SQL Server
can generate certificates.
Certificates can be used to help secure connections, in
database mirroring, to sign packages and other objects, or to encrypt data or
connections.
3: What is checkpoint?
Checkpoint is an internal process that writes all dirty
pages (modified pages) from Buffer Cache to Physical disk, apart from this it
also writes the log records from log buffer to physical file. Writing of Dirty
pages from buffer cache to data file is also known as Hardening of dirty pages.
It is a dedicated process and runs automatically by SQL
Server at specific intervals. SQL Server runs checkpoint process for each
Database individually.
Checkpoint helps to reduce the recovery time for SQL Server
in the event of unexpected shutdown or system crash\Failure.
In SQL Server 2012 there are four types of Checkpoints:
Automatic: This
is the most common checkpoint which runs as a process in the background to make
sure SQL Server Database can be recovered in the time limit defined by the
Recovery Interval – Server Configuration Option.
Indirect: This
is new in SQL Server 2012. This also runs in the background but to meet a
user-specified target recovery time for the specific Database where the option
has been configured. Once the Target_Recovery_Time for a given database has
been selected this will override the Recovery Interval specified for the server
and avoid Automatic Checkpoint on such DB.
Manual: This
one runs just like any other T-SQL statement, once you issue checkpoint command
it will run to its completion. Manual Checkpoint runs for your current Database
Only. You can also specify the Checkpoint_Duration which is optional, this
duration specifies the time in which you want your checkpoint to complete.
Internal: As a
user you can’t control Internal Checkpoint. Issued on specific operations such
as:
1. Shutdown initiates a Checkpoint operation on all
databases except when Shutdown is not clean (Shutdown with nowait)
2. If the recovery model gets changed from Full\Bulk-logged
to Simple.
3. While taking Backup of the Database.
4. 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.
5. Alter Database command to add or remove a data\log file
also initiates a checkpoint.
6. Checkpoint also takes place when the recovery model of
the DB is Bulk-Logged and a minimally logged operation is performed.
7. DB Snapshot creation.
4: What is DAC in SQL Server?
Dedicated Administrator Connection (DAC)
SQL Server’s DAC is a special diagnostic connection that’s
intended for administrators to execute diagnostic queries and troubleshoot
problems even when SQL Server is not responding to standard connection
requests. By default SQL Server listens for DAC on TCP port 1434. However, you
can configure this. If you have changed the default connection port, you can
find the port number the DAC is listening on in the Error log.
You can use the DAC in two different ways. You can use it
via the sqlcmd prompt or you can use it from SQL Server Management Studio
(SSMS).
To use DAC from the sqlcmd prompt, you need to start sqlcmd
using the administrator switch (-A) as you can see in the following example.
sqlcmd -S MySQL Server -U sa -P <xxx> –A
sqlcmd –A –d master
The first example shows how to open a DAC to the server
named MySQLServer. By default, the DAC will open to the default database. The
second example shows how you can open a DAC connection to the master database.
To use DAC from SSMS, select Database Engine Query on the
toolbar. Then, in the Connect to Database Engine dialog box, type the word
ADMIN: followed by the name of the server instance in the Server name prompt.
For example, to connect to a server enter ADMIN:MySQLServer. Then, complete the
Authentication section by entering the login information for a member of the
sysadmin group and then select Connect.
5: What is Fill Factor and what is the best
value for it?
A page is
the basic unit of data storage in SQL server. Its size is 8KB(8192 bytes). Data
is stored in the leaf-level pages of Index. The percentage of space to be
filled with data in a leaf level page is decided by fill factor. The remaining
space left is used for future growth of data in the page. Fill factor is a
number from 1 to 100. Its default value is 0, which is same as 100. So when we
say fill factor is 70 means, 70% of space is filled with data and remaining 30%
is vacant for future use. So higher the fill factor, more data is stored in the
page. Fill factor setting is applied when we create/rebuild index.
6: What is ISOLATION Level in SQL
Server?
There are different types of isolations
available in SQL Server.
- READ COMMITTED
- READ UNCOMMITTED
- REPEATABLE READ
- SERIALIZABLE
- SNAPSHOT
Read Committed
In select query it will take only committed
values of table. If any transaction is opened and incomplete on table in others
sessions then select query will wait till no transactions are pending on same
table.
Read Committed is the default transaction
isolation level.
Read Uncommitted
If any table is updated (insert or update or
delete) under a transaction and same transaction is not completed that is not
committed or roll backed then uncommitted values will display (Dirty Read) in
select query of "Read Uncommitted" isolation transaction sessions.
There won't be any delay in select query execution because this transaction
level does not wait for committed values on table.
Repeatable Read
In select query data of table that is used
under transaction of isolation level "Repeatable Read" cannot be
modified from any other sessions till transaction is completed.
Serializable
Serializable Isolation is similar to
Repeatable Read Isolation but the difference is it prevents Phantom Read. This
works based on range lock. If table has index then it locks records based on
index range used in WHERE clause (like where ID between 1 and 3). If table
doesn't have index then it locks complete table.
Snapshot
Snapshot isolation is similar to Serializable
isolation. The difference is Snapshot does not hold lock on table during the
transaction so table can be modified in other sessions. Snapshot isolation
maintains versioning in Tempdb for old data in case of any data modification
occurs in other sessions then existing transaction displays the old data from
Tempdb.
7: What is ORPHAN Users and how to fix
orphan users issue?
Orphaned
Users
When a
database user for a corresponding SQL Server Login is undefined or incorrectly
defined, SQL Server does not allow the user to log on to that instance. Such a
user is said to be an orphaned user of the database on that server instance. A
database user can become orphaned if the corresponding SQL Server user name is
dropped. Most likely, a database user becomes orphaned after a database is
restored or attached to a different instance of SQL Server. Orphans occur if
the database user is mapped to a SID that is not present in the new server
instance.
Use
SQL Server Management Studio or any other tool that executes SQL statements to
address all orphaned users before you start or upgrade the StarTeam Server
configuration.
Addressing
Orphaned Users in SQL Server 2005 and above
Use
SQL Server Management Studio or any other tool that executes SQL statements to
address all orphaned users before you start or upgrade the StarTeam Server
configuration. Use either the system administrator user name (sa) or windows
authentication (under an administrative user account) to connect to the
database and change the database context for the SQL console to the StarTeam
database.
To
address all orphaned users:
1. Open a
SQL console such as SQL Server Management Studio or Enterprise Manager.
2. Open a
new query.
3. Enter
the following command to display the user names of all orphaned users:
sp_change_users_login
'REPORT'
4. Enter
the following to address the orphaned database owner (dbo). The database
user is always orphaned when changing servers.
sp_addlogin <User
Name> , <Password>
go
sp_changedbowner <User
Name>
go
sp_defaultdb <UserName>
, <Database Name> (database Name is the StarTeam database)
<UserName>
is
the appropriate user name, <Password> is the appropriate password
for the StarTeam Server and <Database
Name> is the StarTeam database
5. For
all other users who are returned as orphans, repeat the following commands for
each of the orphaned users.
a) sp_addlogin
<UserName>, <Password>
b) go
c) EXEC
sp_change_users_login 'Update_One', '<Orphaned UserName>', '<New
UserName> where the first< Orphaned UserName> is the
orphaned user from the previous server and the second <New UserName> is
the new login created in the previous step.
6. Enter
the following command and this command should not return any rows
sp_change_users_login
'REPORT'
8:
What is Resource Database in SQL Server? How can we take backup for resource
database?
The Resource database
is a read-only database that contains all the system objects that are included
with SQL Server. SQL Server system objects, such as sys.objects, are physically
persisted in the Resource database, but they logically appear in the sys schema
of every database. The Resource database does not contain user data or user
metadata.
The Resource database
makes upgrading to a new version of SQL Server an easier and faster procedure.
In earlier versions of SQL Server, upgrading required dropping and creating
system objects. Because the Resource database file contains all system objects,
an upgrade is now accomplished simply by copying the single Resource database
file to the local server.
Physical Properties of Resource
The physical file
names of the Resource database are mssqlsystemresource.mdf and
mssqlsystemresource.ldf. These files are located in <drive>:\Program
Files\Microsoft SQL Server\MSSQL10_50.<instance_name>\MSSQL\Binn\.
Each instance of SQL Server has one and only one associated
mssqlsystemresource.mdf file, and instances do not share this file.
Backing Up and Restoring the Resource Database
SQL Server cannot back
up the Resource database. You can perform your own file-based or a disk-based
backup by treating the mssqlsystemresource.mdf file as if it were a binary
(.EXE) file, rather than a database file, but you cannot use SQL Server to
restore your backups. Restoring a backup copy of mssqlsystemresource.mdf can
only be done manually, and you must be careful not to overwrite the current
Resource database with an out-of-date or potentially insecure version.
9:
What is Slipstreaming?
It is
a term used to describe merging original source media with updates in memory
and then installing the updated files.
Slipstreaming
has been supported by Windows Operating systems for awhile but has just been
added to SQL Server 2008 service pack 1.
Slipstream
allows you to go to the latest and greatest, currently service pack 1 and a CU
for service pack 1.
Prior
to service pack, we supported just update the setup file also referred to as
“Patchable Setup”.
Since
the release of SQL Server 2008 Service Pack 1, it is recommend to use the
slipstream procedures instead as patchable setup since the entire product can
be updated and you will be using the latest and greatest.
Any
scenario (install, upgrade, addnode) that is supported by the original media is
supported when slipstream.
10:
What is Patchable Setup?
Patchable
Setup is a procedure used for updating just the SQL Server 2008 setup files
prior to service pack 1.
Instruction
can be found here. Patchable Setup still requires you to apply the CU after
installing the product.
For
fixes in CU for RTM, you can use patchable setup, but if an issue is only
addressed in service pack 1, you need to use the slipstream procedure.
11:
What is suspect state of database and how will you overcome with this?
Suspect
state of SQL Server database is a state when you are unable to connect to the
database.
In
this state you cannot do anything with your database: no opening, no backup and
no restore.
Possible
cause for this problem can be one of the following:
·
database is corrupted
·
Database files are being "opened" or
held by some process (operating system, other program(s)...)
·
not enough disk space for SQL Server
·
insufficient memory (RAM) for SQL Server
·
unexpected SQL Server shutdown caused by power
failure
For
Overcome with this follow below commands.
EXEC
sp_resetstatus [YourDatabase];
ALTER
DATABASE [YourDatabase] SET EMERGENCY
DBCC
checkdb([YourDatabase])
ALTER
DATABASE [YourDatabase] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC
CheckDB ([YourDatabase], REPAIR_ALLOW_DATA_LOSS)
ALTER
DATABASE [YourDatabase] SET MULTI_USER
12: How do you
troubleshoot slowness with a specific Stored Procedure or a Query?
- First, get more details like, how much time on
an average this query was taking previously (baseline).
- Were there any changes to the stored procedure
or query recently.
- How often this query does runs.
- Does the problem only happen on this server or
other servers too, meaning can this be reproduced on Test or Dev servers.
- Check if this query is being blocked by other
sessions.
- Check if this query is waiting some any resource
using wait stats DMV’s.
- Check if statistics are up to date for the
tables and indexes used in the stored procedure or the query.
- Check fragmentation of the objects in the
stored procedure or the query.
- Collect execution plan of the Stored Procedure
and the statements inside the SP or the query. Also collect Read/Write and
Time execution statistics of the query.
- Check for any missing indexes based on the
execution plan, based on table or clustered index scans.
- Try and suggest to developers if the query
needs to be rewritten in a better way like replacing temp variables with
tempdb tables or usage of functions in where clause.
No comments:
Post a Comment