SQL server – 5 things SQL Server developers should

know about SQL Server

27 August,2012 by Jack Vamvas

SQL Server developers and SQL Server DBAs meet somewhere in the middle of the
development life cycle. That’s the theory. In reality , with time and cost pressures , the
DBA sometimes can be the last to know code is about to go live. There is a
responsibility for the Developer to develop code with some understanding of the SQL
Database Engine.

The way in which Developers approach coding has a big impact on the success of the
project. Scalable code should be a central principle in coding. The code may work
efficiently with a controlled set of data – but how does it scale with 10x the amount of
users, or how does it deal with adding a new column a after the go-live date. This is
where a good DBA advises and works with Developers to apply tactics for performant
SQL Server.

SQL Tuning Advisor

The SQL Tuning Advisor promises much but can also lead to problems. No in-depth
expertise is required, therefore tempting for non DBAs to run a sample workload. The
Advisor typically recommends indexes and statistics. Do not just add them without
considering the consequences , for example, a) Adding new indexes has an extra
storage space requirement b) Extra maintenance is required . How will this impact the
maintenance window?

SQL Server TempDB – Does not retain permanent data

Tempdb is cleared out everytime there is a SQL Server restart. Think of Tempdb as a
temporary data store, for Application data and Internal operations. There is only one
TempDB per SQL Server Instance – it is possible a query hitting one database
supporting one application can adversely impact another application using another
database on the same Instance.

TempDB performance and strategy checklist

Temporary Tables versus Table Variables

SQL Query Optimizer is cost based
The SQL Query Optimizer works on a cost-based model . There doesn’t appear to be
any obvious measure of acceptance , apart from a comparison to other potential
Execution Plans. From a developers perspective , the key to maximising the process is
to write efficient code. This means not only focusing on Set- Based principles , but also
working with a DBA to study the Execution Plan . Ensure Statistics are kept up to date
– as Statistics remain a fundamental part of Optimization.

Query Hints are a powerful tool, but be wary of using them. Generally , if the SQL
Server is maintained properly , it will choose a suitable Execution Plan. Generally , I
don’t recommend them as there is always potential to create new problems.

SQL Server Query Optimizer and Statistics

Transact-SQL and the xQuery language

Transact-SQL (T-SQL) is fundamental in using SQL Server. All types of applications
use SQL server , but they all use T-SQL to communicate.

Querying xml data requires using the XQuery language. XQuery is used for Structured
and semi structured xml data.

Avoid using XML for storing and retrieving data. Based on experience the XML data
type is very slow.

Love your DBA

A good DBA will work hard to monitor and maintain the Database Server. In the
background , they will usually be fixing many small bugs and issues that can topple the
server . Database Servers are part of a large IT ecosystem – when you consider SAN
storage, backups, high availability, monitoring, networks etc , many things can go
wrong.

As the developer cultivate a good relationship with the DBA , for example , set up a
review process of new code going into Production. Try not to rush code into Production
because a manager is shouting . It’s in everyones interest to maintained optimized
code. Contact me for any questions

SQL Index Usage

25 June,2007 by Jack Vamvas
Use this T-SQL Script to retrieve SQL indexes that haven't been used. For a wider view
on table and index usage read SQL Server – Find last time of update on a table

view source
print?
01.select object_name(object_id), index_id, user_seeks, user_scans,
user_lookups
02.from sys.dm_db_index_usage_stats
03.order by object_id, index_id
04.
05.---All indexes which haven’t been used yet can be retrieved with the
following statement:
06.
07.select object_name(object_id), i.name
08.from sys.indexes i
09.where i.index_id NOT IN (select s.index_id
10.from sys.dm_db_index_usage_stats s
11.where s.object_id=i.object_id and
12.i.index_id=s.index_id and
13.database_id = DB_id(db_name()))
14.order by object_name(object_id) asc

SQL Server - List all indexes of all tables

29 December,2010 by Jack Vamvas

If you require a list of every SQL index on every table on a SQL Server database
use the query below

view source
print?
01.SELECT
02.
03.T.[name] AS [table_name], I.[name] AS [index_name]
04.
05.FROM sys.[tables] AS T
06.
07.INNER JOIN sys.[indexes] I ON T.[object_id] = I.[object_id]
08.
09.WHERE I.[type_desc] <> 'HEAP'
10.
11.ORDER BY T.[name], I.[index_id]

A few details of the query , which will allow customising – depending on requirements.

The “type_desc” column - gives a description of the index type. In SQL Server 2005 –
possible types are: Heap, Clustered,NonClustered,XML

As a table is either a clustered table or a heap – I’m not interested in heaps – for the
purpose of this query