Beruflich Dokumente
Kultur Dokumente
Ans. Query Optimization is the process of writing the query in a way so that it could execute
quickly. It is a significant step for any standard application.
Q:-2. What are some tips to improve the performance of SQL queries?
Ans. Optimizing SQL queries can bring substantial positive impact on the performance. It also
depends on the level of RDBMS knowledge you have. Lets now go over some of the tips for
tuning SQL queries.
1. Prefer to use views and stored procedures in spite of writing long queries. Itll also help in
minimizing network load.
2. Its better to introduce constraints instead of triggers. They are more efficient than triggers and
can increase performance.
4. The UNION ALL clause responds faster than UNION. It doesnt look for duplicate rows
whereas the UNION statement does that regardless of whether they exist or not.
7. Make use of SET NOCOUNT ON clause while building stored procedures. It represents the
rows affected by a T-SQL statement. It would lead to reduced network traffic.
8. Its a good practice to return the required column instead of all the columns of a table.
9. Prefer not to use complex joins and avoid disproportionate use of triggers.
Q:-3. What are the bottlenecks that affect the performance of a Database?
Ans. In a web application, the database tier can prove to be a critical bottleneck in achieving the
last mile of scalability. If a database has performance leakage, that can become a bottleneck and
likely to cause the issue. Some of the common performance issues are as follows.
1. Abnormal CPU usage is the most obvious performance bottleneck. However, you can fix it by
extending CPU units or replacing with an advanced CPU. It may look like a simple issue but
abnormal CPU usage can lead to other problems.
2. Low memory is the next most common bottleneck. If the server isnt able to manage the peak
load, then it poses a big question mark on the performance. For any application, memory is very
critical to perform as its way faster than the persistent memory. Also, when the RAM goes down
to a specific threshold, then the OS turns to utilize the swap memory. But it makes the application
to run very slow.
You can resolve it by expanding the physical RAM, but it wont solve memory leaks if there is
any. In such a case, you need to profile the application to identify the potential leaks within its
code.
3. Too much dependency on external storage like SATA disk could also come as a bottleneck. Its
impact gets visible while writing large data to the disk. If output operations are very slow, then it
is a clear indication an issue becoming the bottleneck.
In such cases, you need to do scaling. Replace the existing drive with a faster one. Try upgrading
to an SSD hard drive or something similar.
Q:-4. What are the steps involved in improving the SQL performance?
Ans.
Discover First of all, find out the areas of improvement. Explore tools like Profiler, Query
execution plans, SQL tuning advisor, dynamic views, and custom stored procedures.
Propose Here is a standard approach one can adapt to boost the performance. However, you
can customize it further to maximize the benefits.
Validate Test the SQL performance tuning approach. Monitor the progress at a regular interval.
Also, track if there is any adverse impact on other parts of the application.
Publish Now, its time to share the working solution with everyone in the team. Let them know
all the best practices so that they can use it with ease.
Back to top
Ans. Its a term used in Oracle. And it is a type of SQL clause in Oracle which displays the
execution plan that its optimizer plans for executing the SELECT/UPDATE/INSERT/DELETE
statements.
Q:-6. How do you analyze an explain plan?
Ans. While analyzing the explain plan, check the following areas.
1. Driving Table
2. Join Order
3. Join Method
4. Unintentional cartesian product
5. Nested loops, merge sort, and hash join
6. Full Table Scan
7. Unused indexes
8. Access paths
Ans. The explain plan shows a complete output of the query costs including each subquery. The
cost is directly proportional to the query execution time. The plan also depicts the problem in
queries or sub-queries while fetching data from the query.
Q:-8. What is Summary advisor and what type of information does it provide?
Ans. Summary advisor is a tool for filtering and materializing the views. It can help in elevating
the SQL performance by selecting the proper set of materialized views for a given workload. And
it also provides data about the Materialized view recommendations.
Q:-9. What could most likely cause a SQL query to run as slow as 5 minutes?
Ans. Most probably, a sudden surge in the volume of data in a particular table could slow down
the output of a SQL query. So collect the required stats for the target table. Also, monitor any
change in the DB level or within the underlying object level.
Q:-10. What is a Latch Free Event? And when does it occur? Alos, how does the system
handles it?
Ans. In Oracle, Latch Free wait event occurs when a session requires a latch, attempts to get it
but fails because someone else has it.
So it sleeps with a wait eying for the latch to get free, wakes up and tries again. The time duration
for it was inactive is the wait time for Latch Free. Also, there is no ordered queue for the waiters
on a latch, so the one who comes first gets it.
Back to top
Proactive tuning The architect or the DBA determines which combination of system resources
and available Oracle features fulfill the criteria during Design and Development.
Reactive tuning It is the bottom-up approach to discover and eliminate the bottlenecks. The
objective is to make Oracle respond faster.
Ans. Oracle determines how to get the required data for processing a valid SQL statement. It uses
one of following two methods to take this decision.
Rule-based Optimizer When a server doesnt have internal statistics supporting the objects
referenced by the statement, then the RBO method gets preference. However, Oracle will
deprecate this method in the future releases.
Cost-based Optimizer When there is an abundance of the internal statistics, the CBO gets the
precedence. It verifies several possible execution plans and chooses the one with the lowest cost
based on the system resources.
Ans. The following high-level tuning indicators are available to establish if a database is
experiencing bottlenecks or not:
Action: Advance the DB_CACHE_SIZE (DB_BLOCK_BUFFERS prior to 9i) to improve the hit
ratio.
Q:-15. What do you check first if there are multiple fragments in the SYSTEM tablespace?
Ans. First of all, check if the users dont have the SYSTEM tablespace as their TEMPORARY or
DEFAULT tablespace assignment by verifying the DBA_USERS view.
Back to top
Q:-16. When would you add more Copy Latches? What are the parameters that control the
Copy Latches?
Ans. If there is excessive contention for the Copy Latches, check from the redo copy latch hit
ratio.
In such a case, add more Copy Latches via the initialization parameter
LOG_SIMULTANEOUS_COPIES to double the number of CPUs available.
Ans. You can confirm it by checking the output of SELECT against the dba_free_space table. If
it points that the no. of a tablespaces extents is more than the count of its data files, then it proves
excessive fragmentation.
Ans. First of all, set the optimizer to scan all the entries from the index instead of the table. You
can achieve it by specifying hints.
Please note that crawling the smaller index takes less time than to scan the entire table.
Q:-19. Where does the I/O statistics per table exist in Oracle?
Ans. There is a report known as UTLESTAT which displays the I/O per tablespace. But it
doesnt help to find the table which has the most I/O.
Ans. First of all, select the target index and run the ANALYZE INDEX VALIDATE
STRUCTURE command. Every time you run it, a single row will get created in the
INDEX_STATS view.
But the row gets overwritten the next time you run the ANALYZE INDEX command. So better
move the contents of the view to a local table. Thereafter, analyze the ratio of DEL_LF_ROWS
to LF_ROWS and see if you need to rebuild the index.
Q:-21. What exactly would you do to check the performance issue of SQL queries?
Ans. Mostly the database isnt slow, but its the worker session which drags the performance.
And its the abnormal session accesses which cause the bottlenecks.
Back to top
Q:-22. What is the information you get from the STATSPACK Report?
Ans. We can get the following statistics from the STATSPACK report.
1. WAIT notifiers
2. Load profile
3. Instance Efficiency Hit Ratio
4. Latch Waits
5. Top SQL
6. Instance Action
7. File I/O and Segment Stats
8. Memory allocation
9. Buffer Waits
Q:-23. What are the factors to consider for creating Index on Table? Also, How to select a
column for Index?
If Table size is large and we need a smaller report, then its better to create Index.
Regarding the column to be used for Index, as per the business rule, you should use a primary key
or a unique key for creating a unique index.
Q:-24. What is the main difference between Redo, Rollback, and Undo?
Ans.
Redo Log that records all changes made to data, including both uncommitted and committed
changes.
Rollback Segments to store the previous state of data before the changes.
Undo Helpful in building a read consistent view of data. The data gets stored in the undo
tablespace.
Q:-25. How do you identify the shared memory and semaphores of a particular DB instance
if there are running multiple servers?
Ans. Set the following parameters to distinguish between the in-memory resources of a DB
instance.
1. SETMYPID
2. IPC
3. TRACEFILE_NAME
Memory bottleneck:
Consistently low average page life expectancy. (MSSQL$Instance: Buffer
Manager\Page Life Expectancy:)
(See Average Page Life Expectancy Counter which is in the Perfmon object SQL
Server Buffer Manager (this represents is the average number of seconds a page
stays in cache). For OLTP, an average page life expectancy of 300 is 5 minutes.
Anything less could indicate memory pressure, missing indexes, or a cache flush)
Consistently low SQL Cache hit ratio. (MSSQL$Instance: Plan Cache\Cache Hit
Ratio:)
(OLTP applications (e.g. small transactions) should have a high cache hit ratio.
Since OLTP transactions are small, there should not be (1) big drops in SQL Cache
hit rates or (2) consistently low cache hit rates < 90%. Drops or low cache hit may
indicate memory pressure or missing indexes.)
IO bottleneck:
High average disk seconds per read.
(When the IO subsystem is queued, disk seconds per read increases. See Perfmon
Logical or Physical disk (disk seconds/read counter). Normally it takes 4-8ms to
complete a read when there is no IO pressure. When the IO subsystem is under
pressure due to high IO requests, the average time to complete a read increases,
showing the effect of disk queues. Periodic higher values for disk seconds/read
may be acceptable for many applications. For high performance OLTP applications,
sophisticated SAN subsystems provide greater IO scalability and resiliency in
handling spikes of IO activity. Sustained high values for disk seconds/read (>15ms)
does indicate a disk bottleneck.)
Big IOs such as table and range scans due to missing indexes.
Blocking bottleneck:
High average row lock or latch waits.
(The average row lock or latch waits are computed by dividing lock and latch wait
milliseconds (ms) by lock and latch waits. The average lock wait ms computed
from sys.dm_db_index_operational_stats represents the average time for each
block.)
Network bottleneck:
High network latency coupled with an application that incurs many round trips
to the database.
Network bandwidth is used up.
(See counters packets/sec and current bandwidth counters in the network
interface object of Performance Monitor. For TCP/IP frames actual bandwidth is
computed as packets/sec * 1500 * 8 /1000000 Mbps)
Server Hardware:
Most slow applications are slow because of poor up front design, not because of
slow hardware. Since the applications design cant be changed at the time when
deployed to production, about the only thing you can try to help boost
performance is to throw hardware at it.
CPU: Always purchase a server with the ability to expand its number of CPUs.
Usually it goes for larger servers with four or more CPUs. Always leave room for
growth.
Memory: Try to get enough RAM to hold the largest table you expect to have,
and if you can afford it, get all the RAM your server can handle, which is often
2GB or more.
I/O Subsystem: At the very minimum, purchase hardware-based RAID for your
databases. As a rule of thumb, you will to purchase more smaller drives, not
fewer larger drives in your array. The more disks that are in an array, the
faster I/O will be.
Network Connection: At the server, have at least one 100Mbs network card,
and it should be connected to a switch. Ideally, you should have two network
cards in the server connected to a switch in full-duplex mode.
For best performance on a server, SQL Server should be the only application
running on the server, other than management utilities. Dont try to save a few
bucks by putting your IIS server on the same server as SQL Server.
FROM SYS.DM_OS_RING_BUFFERS
One record is stored every minute up to a maximum of 256 records. Clicking on any
of the XML links will take you to the XML editor and will show an entry similar to
below
<Record id=434 type=RING_BUFFER_SCHEDULER_MONITOR time=22398046>
<SchedulerMonitorEvent>
<SystemHealth>
<ProcessUtilization>55</ProcessUtilization>
<SystemIdle>35</SystemIdle>
<UserModeTime>228180000</UserModeTime>
<KernelModeTime>251812000</KernelModeTime>
<PageFaults>64252</PageFaults>
<WorkingSetDelta>21770240</WorkingSetDelta>
<MemoryUtilization>100</MemoryUtilization>
</SystemHealth>
</SchedulerMonitorEvent>
</Record>
Now find out the query/proc/process that is making CPU utilization High:
SELECT TOP 20
qst.sql_handle,
qst.execution_count,
qst.total_worker_time AS Total_CPU,
(qst.total_worker_time/1000000) / qst.execution_count,
qst.total_elapsed_time,
qst.total_elapsed_time/1000000,
st.text AS Query,
qp.query_plan
from
sys.dm_exec_query_stats as qst
From the above script we can find the commands which are taking the most CPU
time along with the execution plan. By reviewing the execution plan you can see
what additional indexes need to be added to the database which will improve
database performance and decrease the CPU load time.
By adding missing indexes or by using the proper indexes we can decrease the load
on CPU.
Other options:
Sp_monitor: Displays statistics, including CPU usage, I/O usage, and the
amount of time idle since sp_monitor was last executed. We can get the
information about the CPU Time (Sec), I/O Time (Sec), Count of
Input\Output Packets, No of logins attempted, Errors in reading/writing
network packets etc.
@@CPU_BUSY / @@IO_BUSY: Returns the time that SQL Server has spent
working since it was last started. Result is in CPU time increments, or ticks,
and is cumulative for all CPUs, so it may exceed the actual elapsed time.
Multiply by @@TIMETICKS to convert to microseconds. But it may not the
accurate value to be considered.
PerfMon
Profiler
Q. Can you tell me what the Wait Type LAZY WRITTER is?
Ans:
The job of the lazy writer is to find dirty pages in the buffer pool and write them
out to disk and drop those pages from cache.
In general there are three categories of waits that could affect any given request:
Q. What are the main parameters we need to check when you are dealing with
memory performance?
Ans:
There are four significant properties of sql server.
For example we have 24 GB available and the settings can be like this:
Min Memory: 1 GB
Max Memory: 16 GB
Remember total max memory of all instances should not exceeds the actual
physical memory available
Priority boost: By default, the priority boost setting is 0, which causes SQL Server
to run at a normal priority. If you set priority boost to 1, the SQL Server process
runs at a high priority.
Lightweight pooling: Switch on this parameter when you want to make sql server
use the fiber mode facility. Unless there is a real need and environment (Large
multi-processor servers) available we should not use this option at production
servers.
Question 1: Name five different tools which can be used for performance
tuning and their associated purpose.
o Performance Monitor\System Monitor - Tool to capture macro level
performance metrics.
Additional information
Automate Performance Monitor Statistics Collection for SQL
Server and Windows
Windows Reliability and Performance Monitor to troubleshoot
SQL Server
o Profiler - Tool to capture micro level performance metrics based on the
statements issued by a login, against a database or from host name.
Additional information: Tip Category - Profiler and Trace
o Server Side Trace - System objects to write the detailed statement metrics to a
table or file, similar to Profiler.
Additional information: SQL Server Performance Statistics Using a
Server Side Trace
o Dynamic Management Views and Functions - SQL Server objects with low
level metrics to provide insight into a specific portion of SQL Server i.e. the
database engine, query plans, Service Broker, etc.
Additional information: Dynamic Management Views\Functions
o Management Studio's Built-In Performance Reports - Ability to capture point
in time metrics as pre-defined by Microsoft.
Additional information: Built-In Performance Reports in SQL Server
2005
o Custom scripts - Custom scripts can be developed to monitor performance,
determine IO usage, monitor fragmentation, etc. all in an effort to improve
performance.
o Third party applications - Performance monitoring and tuning applications
from vendors in the SQL Server community.
Additional information: SQL Server Performance Monitoring Tools
Question 2: Explain how the hardware running SQL Server can help or
hinder performance.
o Taxed CPUs will queue requests and hinder query performance.
o Insufficient memory could cause paging resulting in slow query performance.
o Incorrectly configured disk drives could exacerbate IO problems.
o Additional information: Hard Drive Configurations for SQL
Server and Hardware 101 for DBAs
Question 4: How is it possible to capture the IO and time statistics for your
queries?
o Use the SET STATISTICS IO and SET STATISTICS TIME settings in your
queries or enable the settings in your Management Studio session.
o Additional information: Getting IO and time stats for your queries
Question 1: How can I/O statistics be gathered and reviewed for individual
database files?
o By using the fn_virtualfilestats function to capture the metrics.
o This process can be automated with a script to determine the file usage with
numerous samples.
o Additional Information: Gathering I/O statistics down to the database file level
Question 2: What is a query plan and what is the value from a performance
tuning perspective?
o A query plan is the physical break down of the code being passed to the SQL
Server optimizer.
o The value from a performance tuning perspective is that each component of
the query can be understood and the percentage of resource utilization can be
determined at a micro level. As query tuning is being conducted, the detailed
metrics can be reviewed to compare the individual coding techniques to
determine the best alternative.
o Additional Information:
Maximizing your view into SQL Query Plans
Capturing Graphical Query Plans with Profiler
Tip Category: Query Plans
Tip Category: Query Optimization
Question 4: Explain the NOLOCK optimizer hint and some pros\cons of using
the hint.
o The NOLOCK query hint allows SQL Server to ignore the normal locks that
are placed and held for a transaction allowing the query to complete without
having to wait for the first transaction to finish and therefore release the locks.
o This is one short term fix to help prevent locking, blocking or deadlocks.
o However, when the NOLOCK hint is used, dirty data is read which can
compromise the results returned to the user.
o Additional information: Getting rid of some blocking issues with NOLOCK
Question 2: Name three different options to capture the input (code) for a
query in SQL Server.
o DBCC INPUTBUFFER
o fn_get_sql
o sys.dm_exec_sql_text
o Additional information:
SQL Server statements currently running with fn_get_sql
SQL Server 2000 to 2005 Crosswalk - Code Identification
Question 5: Please explain why SQL Server does not select the same query
plan every time for the same code (with different parameters) and how SQL
Server can be forced to use a specific query plan.
o The query plan is chosen based on the parameters and code being issued to the
SQL Server optimizer. Unfortunately, a slightly different query plan can
cause the query to execute much longer and use more resources than another
query with exactly the same code and only parameter differences.
o The OPTIMIZE FOR hint can be used to specify what parameter value we
want SQL Server to use when creating the execution plan. This is a SQL
Server 2005 and beyond hint.
o Additional information: Optimize Parameter Driven Queries with the
OPTIMIZE FOR Hint
Indexes help us to find data faster. It can be created on a single column or a combination of columns........
Sql server - Syntax and an example for create, rename and delete index
CREATE INDEX index_name ON table_name (col_1,col_2..);........
Q. If you need to REBUILD a non-clustered index that is 10GB in size and have
5GB of free data-file space available with no room to grow the data file(s), how
can you accomplish the task?
Ans:
When rebuilding an existing non-clustered index, you typically require free space
that is approximately equivalent to 2.2 times the size of the existing index, since
during a rebuild operation, the existing index is kept until the rebuilt structure is
complete and an additional approximately 20% free space for temporary sorting
structures used during the rebuild operation
In this case, you would require at least an additional 10+ GB of free space for
the rebuild operation to succeed, since the index itself is 10GB in size.
Using SORT_IN_TEMPDB would not suffice in this case, since only the temporary
sort tables are stored in tempdb in this case, and at least 10 GB of free space
would still be required in the database data files.
Your possibilities are different for SQL Server2000 vs. SQL Server 2005/2008:
In SQL Server 2000, you only have 1 option in this case. Drop the index and
recreate it.
In SQL Server 2005/2008, you can do the same as you did with SQL Server
2000 (drop, recreate), but you also have another option. If you first disable the
index (via the ALTER INDEXDISABLE statement) the existing space consumed
by the index will be freed. Then running a simple ALTER INDEXREBUILD
command will allow the build operation to use the now 15gb of free space to
build the index.
Q. What is the Covering Index?
Ans:
If you know that your application will be performing the same query over and over
on the same table, consider creating a covering index on the table. A covering
index, which is a form of a composite non clustered index, includes all of the
columns referenced in SELECT, JOIN, and WHERE clauses of a query. Because of
this, the index contains the data you are looking for and SQL Server doesnt have
to look up the actual data in the table, reducing logical and/or physical I/O, and
boosting performance.
On the other hand, if the covering index gets too big (has too many columns), this
could actually increase I/O and degrade performance.
The Online indexing feature is very helpful for environments that run 24 hours a
day, seven days a week. The Online Indexing feature is available only in the
Enterprise Edition of SQL Server 2005/2008.
Preparation
Build
Final
The Build phase is a longest phase of all. It is in this phase where the creation,
dropping, or rebuilding of indexes take place. The duration of the Build phase
depends on the size of the data and the speed of the hardware. Exclusive locks are
not held in this phase, so concurrent DML operations can be performed during this
phase. The Preparation and Final phases are for shorter durations. They are
independent of the size factor of the data. During these two short phases, the
table or the indexed data is not available for concurrent DML operations.
You can include nonkey columns in a nonclustered index to avoid the current index
size limitations of a maximum of 16 key columns and a maximum index key size of
900 bytes. The SQL Server Database Engine does not consider nonkey columns
when calculating the number of index key columns or the total size of the index
key columns. In a nonclustered index with included columns, the total size of the
index key columns is restricted to 900 bytes. The total size of all nonkey columns is
limited only by the size of the columns specified in the INCLUDE clause; for
example, varchar(max) columns are limited to 2 GB. The columns in the INCLUDE
clause can be of all data types, except text, ntext, and image.
UserName varchar(50),
UNIQUE (UserName)
)
The drawback is that the indexes (or constraints) need to be unique. One potential
way to circumvent this however, is to create a composite unique constraint:
UserName varchar(50),
FirstName varchar(50),
UNIQUE (UserName,UserID)
You can also create the equivalent of a clustered index. To do so, just add the
clustered reserved word.
UserName varchar(50),
FirstName varchar(50),
Q. What is fill factor? How to choose the fill factor while creating an index?
Ans:
The Fill Factor specifies the % of fullness of the leaf level pages of an index. When
an index is created or rebuilt the leaf level pages are written to the level where
the pages are filled up to the fill factor value and the remainder of the page is left
blank for future usage. This is the case when a value other than 0 or 100 is
specified. For example, if a fill factor value of 70 is chosen, the index pages are
all written with the pages being 70 % full, leaving 30 % of space for future usage.
On the other hand if you have an index that is constantly changing you would want
to have a lower value to keep some free space available for new index entries.
Otherwise SQL Server would have to constantly do page splits to fit the new values
into the index pages.
CHECKSUM:
Works by calculating a checksum over the contents of the whole page and stores
the value in the page header when a page is written to disk. When the page is read
from disk, the checksum is recomputed and compared to the checksum value
stored in the page header. If the values do not match, error message 824
(indicating a checksum failure) is reported to both the SQL Server error log and the
Windows event log. A checksum failure indicates an I/O path problem. To
determine the root cause requires investigation of the hardware, firmware drivers,
BIOS, filter drivers (such as virus software), and other I/O path components.
Q. How to make forcefully use an index in a query? Or What table hint needs to
be specified to forcefully use an index in a query?
Ans:
We can specify Index table hint in a query to forcefully use an index.
Auto Update Statistics: If there is an incoming query but statistics are stale then
sql server first update the statistics before building the execution plan.
Auto Update Statistics Asynchronous: If there is an incoming query but statistics
are stale then sql servers uses the stale statistics, builds the execution plan and
then update the statistics.
Q. How to update statistics manually?
Ans:
If you want to manually update statistics, you can use either sp_updatestats or
UPDATE STATISTICS <statistics name>
Other factors that influence the optimizer in choosing the execution plan are:
Q. How histogram built?
Ans:
As we all know that when we index a column, SQL Server does two things:
1. Sorts the values of the column in an internal data structure called Index This
data structure contains the sorted value and a pointer to its respective row in
the table.
2. Generates a histogram of values.
The histogram shows the distribution of values for the sorted column. For example:
In general we can find out last statistics updated info from below query
,name as stats_name
from sys.stats
order by last_update
In order to understand the RID look up we need to first understand how non-
clustered indexes work with clustered indexes and heap tables. Below is a simple
figure which describes the working and their relationships.
Non-clustered indexes also use the B-tree structure fundamental to search data. In
non-clustered indexes the leaf node is a Rowid which points to different things
depending on two scenarios:-
Scenario 1:- If the table which is having the primary key in the join has a clustered
index on the join key then the leaf nodes i.e. rowid will point to the index key of
clustered index hence a clustered index seek happens
Scenario 2 :- if the table which is having the primary does not have a clustered
index then the non-clustered index leaf node rowid will point to actual row on
the heap table. As the data is stored in a different heap table, it uses the lookup
(i.e. RID lookup) to get to the actual row hence an Index seek (Non clustered) with
RID lookup happens