Chances are, you are here because you have googled for the above mentioned error from SQL Server.

In case you did not understand what it means, I’ve found a simple yet effective explanation in this link

I quote

CREATE TABLE foo (
fooid int IDENTITY,
foovalue varchar(47)
)

CREATE TABLE bar (
barid int IDENTITY,
barvalue varchar(47),
fooid int
CONSTRAINT fk_bar_foo FOREIGN KEY(fooid)
REFERENCES foo(fooid)
ON UPDATE
CASCADE
ON DELETE
CASCADE
)

CREATE TABLE baz (
bazid int IDENTITY,
bazvalue varchar(47),
barid int
CONSTRAINT fk_baz_bar FOREIGN KEY(barid)
REFERENCES bar(barid)
ON UPDATE
CASCADE
ON DELETE
CASCADE
)

SQL Server will say, hey, if we delete a row from foo, well, we could delete
multiple rows from bar, and then we’ll have to delete multiple rows from
baz, and that could go on forever! So let’s issue a warning about “cycles or
multiple cascade paths” and disallow it.

Siempre es curioso encontrarse con funcionalidades no documentadas en SQL Server. Aunque uno no pueda fiarse mucho de ellas (al no estar documentadas, el equipo de desarrollo podría cambiarlas o directamente eliminarlas sin tener que rendir cuentas a nadie), en alguna ocasión te puede sacar de un apuro.

El caso es que hoy me he encontrado con una forma fácil de conocer la ruta del log de errores de nuestra instancia. Sí, igual alguno puede conocer la forma por la cual podemos obtener algo similar leyendo del registro, mediante el procedimiento almacenado extendido xp_instance_regread (el cual tampoco está documentado) y filtrando por la clave correcta. Algo como:

DECLARE @DirLog nvarchar(512)

EXEC master.dbo.xp_instance_regread N’HKEY_LOCAL_MACHINE’ , N’SOFTWARE\Microsoft\MSSQLServer\CPE’ , N’ErrorDumpDir’ , @DirLog OUTPUT

PRINT @DirLog

Teniendo en cuenta que lo anterior nos muestra la ruta de la carpeta LOG de nuestra instancia, no habría mayor problema en usar este método si conocemos la clave del registro donde buscar. Lo cual en algunas ocasiones puede ser bastante complicado.

Sin embargo, con este nuevo método que he encontrado, simplemente ejecutando

SELECT SERVERPROPERTY(‘ErrorLogFileName’)

Tenemos no sólo la ruta completa, sino también el nombre del archivo de log de nuestra instancia.

CREATE TABLE #temp1 (longtextwithspace VARCHAR(8000))
INSERT #temp1
SELECT ‘THIS IS TO SHOW HOW TO REPLACE MULTIPLE SPACE WITH A SINGLE SPACE WHICH MAKES IT A MEANING FULL STATEMENT, USING A SINGLE QUERY ‘
SELECT * FROM #temp1
SELECT REPLACE(REPLACE(REPLACE(LTRIM(RTRIM(longtextwithspace)),’ ‘,’ ‘+char(3)),char(3)+’ ‘,”),char(3),”) from #temp1

This is the only way we can handle the very large tables in sql 2000. The basic is splitting the huge table into different small idential tables based on date of any column value.
We have to put the check condition while creating the table itself.

CREATE TABLE [dbo].[sample_tab1](
[MsgId] [int] NOT NULL ,
[PtId] [tinyint] NOT NULL CHECK ([PtId] = 1),
[TimeCreated] [datetime] NOT NULL ,
CONSTRAINT [PK_sample_tab] PRIMARY KEY CLUSTERED
(
[MsgId],
[PtId]
) ON [Primary] ,

) ON [Primary]
GO

CREATE TABLE [dbo].[sample_tab2](
[MsgId] [int] NOT NULL ,
[PtId] [tinyint] NOT NULL CHECK ([PtId] = 2),
[TimeCreated] [datetime] NOT NULL ,
CONSTRAINT [PK_sample_tab] PRIMARY KEY CLUSTERED
(
[MsgId],
[PtId]
) ON [Primary] ,

) ON [Primary]
GO

Remember its always put the constraint while you create the table itself (aviod using alter table to add constraint).

Now Create a View with Union all.

create view VW_sample_tab
as
select * from sample_tab1
union all
select * from sample_tab2
GO

Now do the query with partition key as condition. it will be always index seek.

SELECT O.NAME AS TableName, i.name as IndexName, STATS_DATE(i.id,i.indid)as StatsDate FROM sysindexes i
INNER JOIN sysobjects O
ON i.id=O.id
AND i.rows>0 AND O.XTYPE=’U’ AND O.NAME =’table name’
ORDER BY O.NAME

This will give when was the last statistics updated on the table for all the indexes.

Tutorial passo a passo de como fazer conexão JDBC no SQL Server 2000 no Linux com o SQuirreL SQL Client.

Instalação Java 2

Primeiramente você precisa ser instalado Java 2 JRE, caso não tenha, siga o tutorial: http://www.jsk.com.br/java-linux.htmlT se estiver usando Debian ou alguma distribuição baseada no Debian como o Ubuntu, logue como superusuário e digite apt-get install sun-java5-jre

Baixe os drives do JDBC para o SQL Server 2000 no endereço:

http://www.microsoft.com/downloads/details.aspx?FamilyID=4f8f2f01-1ed7-4c4d-8f7b-3d47969e66ae&displaylang=en

ou diretamente em

http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/jorm/jorm/externals/jdbc/msbase.jar

http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/jorm/jorm/externals/jdbc/mssqlserver.jar

http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/jorm/jorm/externals/jdbc/msutil.jar

salve os arquivos msbase, mssqlserver e msutil em diretorio, no meu caso crie um diretório em /lib/sqlserver

Torne-se Root, digite na linha de comando:

su

informe a senha do super-usuário.

Dê permissão de leitura e execução dos arquivos jars  (logado com o super-usuário):

chmod +rx /lib/sqlserver/*.jar

Adicionando repositórios no source list

Ainda como super-usuário abra o arquivo de source list:

gedit /etc/apt/sources.list

adicione no source list os seguintes repositórios:

deb http://www.repositorios.pr.gov.br/celepar/ lenny main contrib non-free

deb http://www.repositorios.pr.gov.br/celepar-backports/ lenny main contrib non-free

deb http://www.repositorios.pr.gov.br/debian lenny main/ contrib non-free

deb http://www.repositorios.pr.gov.br/debian-security/ lenny/updates main contrib non-free

deb http://www.repositorios.pr.gov.br/debian-multimedia/ lenny main

deb http://www.repositorios.pr.gov.br/debian-backports/ lenny-backports main contrib non-free

salve o arquivo.

Instalando SQuirrel SQL Client

atualize sua lista de repositórios com o comando:

apt-get update

Procure pelo nome o pacote do cliente sql squirrel-xxx

apt-cache search squirrel

No meu caso retornou o seguinte nome:  squirrel-sql-client – SQuirreL SQL Client

instale o pacote squirrel-sql-client com o comando:

apt-get install squirrel-sql-client

Se necessário, confirme a instalação com  “y” ou “s” dependendo do idioma.

Se tudo correu bem até aqui, você estará o seu cliente sql devidamente instalado.

Configurando o SQuirrel cliente para acessar o banco SQL Server 2000

No Gnome entre “Aplicações”, “Programação”,  “SQuirrel SQL Client”

Entre na aba de Alias, crie uma nova conexão, informe a string de conexão do mssqlserver jdbc:microsoft:sqlserver://nomeServidorBD:1433

Informe o usuário e  senha do banco de dados, clique em connect

O seu cliente sql está configurado e pronto par a uso.

Links:

Squirrel SQL Client http://squirrel-sql.sourceforge.net/

JDBC SQL Server 2000 http://www.microsoft.com/downloads/details.aspx?FamilyID=4f8f2f01-1ed7-4c4d-8f7b-3d47969e66ae&displaylang=en

Java J2SE http://www.sun.com

SQL 2005 version

SQL 2000 version

DECLARE @counter tinyint
SET @counter=1
WHILE @counter
BEGIN
SET ROWCOUNT 5000
DELETE FROM TABLE NAME WHERE CONDITION
SELECT @counter= count(*) FROM TABLE NAME WHERE CONDITION
WAITFOR DELAY ‘000:00:02′ — Delay will be 2 sec between each execution
END

I recently had to copy a large number of databases to a development environment. There was several hundred gigabytes of files, so I went with stop sql services, copy, restart services and attach new databases route.

Before copying the files, I migrated the users. After attaching the database files to the new instance, I ran the orphaned user scripts. Everything seemed to have swimmingly.

A couple of hours later, a developer called me up and said that they were running into permission errors executing stored procedures. There were a lot of scripts out there for user permissions, but none of them seemed to fit my specific needs, especially since this was SQL 2000. So, on that note, here is my addition to that myriad of scripts for SQL Server permissions.

/* SQL 2005/2008 */
DECLARE
 @Login varchar(50),
 @Role varchar(50);

SET @Login = NULL;
SET @Role = NULL;

SELECT
 perm.state_desc
 + SPACE(1)
 + perm.permission_name
 + ' on ['
 + s.name
 + '].['
 + o.name
 + '] to ['
 + prin.name
 + '];'
 + CHAR(10)
 + 'GO'
 + CHAR(10)
 COLLATE LATIN1_General_CI_AS
FROM
 sys.database_permissions perm
INNER JOIN
 sys.objects o ON
 perm.major_id = o.OBJECT_ID
INNER JOIN
 sys.schemas s ON
 o.SCHEMA_ID = s.SCHEMA_ID
INNER JOIN sys.database_principals prin ON
 perm.grantee_principal_id = prin.principal_id
WHERE
 ((prin.type = 'U' AND prin.name = @Login) OR @Login IS NULL) AND
 ((prin.type = 'R' AND prin.name = @Role) OR @Role IS NULL);

/* SQL 2000 */
DECLARE
 @Login varchar(50),
 @Role varchar(50),
 @ObjectName varchar(50);

SET @Login = NULL;
SET @Role = NULL;
SET @ObjectName = '[admin_getStoreOrderTimes]';

SELECT
 CASE ProtectType
 WHEN 204 THEN 'GRANT_W_GRANT'
 WHEN 205 THEN 'GRANT'
 WHEN 206 THEN 'DENY' END
 + SPACE(1)
 + CASE Action
 WHEN 26 THEN 'REFERENCES'
 WHEN 178 THEN 'CREATE FUNCTION'
 WHEN 193 THEN 'SELECT'
 WHEN 195 THEN 'INSERT'
 WHEN 196 THEN 'DELETE'
 WHEN 197 THEN 'UPDATE'
 WHEN 198 THEN 'CREATE TABLE'
 WHEN 203 THEN 'CREATE DATABASE'
 WHEN 207 THEN 'CREATE VIEW'
 WHEN 222 THEN 'CREATE PROCEDURE'
 WHEN 224 THEN 'EXECUTE'
 WHEN 228 THEN 'BACKUP DATABASE'
 WHEN 233 THEN 'CREATE DEFAULT'
 WHEN 235 THEN 'BACKUP LOG'
 WHEN 236 THEN 'CREATE RULE' END
 + SPACE(1)
 + 'ON'
 + SPACE(1)
 + '['
 + USER_NAME(o.uid)
 + '].['
 + OBJECT_NAME(o.id)
 + ']'
 + SPACE(1)
 + 'TO'
 + SPACE(1)
 + '['
 + u.name
 + '];'
 + CHAR(10)
 + 'GO'
 + CHAR(10)
FROM
 sysusers u
INNER JOIN
 sysprotects p ON
 u.uid = p.uid
INNER JOIN
 sysobjects o ON
 p.id = o.id
WHERE
 ((IsLogin = 1 AND u.name = @Login) OR @Login IS NULL) AND
 (((u.IsSQLRole = 1 OR u.IsAppRole = 1) AND u.name = @Role) OR @Role IS NULL) AND
 (OBJECT_NAME(o.id) = @ObjectName OR @ObjectName IS NULL) AND
 u.name NOT IN ('public','db_owner','db_accessadmin','db_securityadmin','db_ddladmin',
 'db_backupoperator','db_datareader','db_datawriter','db_denydatareader',
 'db_denydatawriter','guest');

~Ron

Another database developer had copied several database from our model office back to our development environment. When we started to wire up out applications I noticed that there were no indexes, defaults, keys, or constraints of any kind. Just heaps.

Adding these constraints is fairly straigtforward, and there are many tools out there to do that. But I could not find a tool that would script just the default constraints without also dropping and/or creating the table. It took a couple of days to get the databases moved over in the first place, but there were over a thousand default constraints, which could also take several days if done manually.

I was sure that there was a way to script this, but after over an hour of searching I decided that I burned enough time and that I would write one myself. I don’t know how often anyone would come across this issue, but here it is anyways.

SELECT
    'ALTER TABLE dbo.' + OBJECT_NAME(s.id) + ' ADD CONSTRAINT DF_' + OBJECT_NAME(s.id) + '_' + sc.name + ' DEFAULT ' + c.text + ' FOR ' + sc.name
FROM
    dbo.sysconstraints s
INNER JOIN syscolumns sc
	ON s.id = sc.id AND
	   s.colid = sc.colid
INNER JOIN dbo.syscomments c
    ON s.constid = c.id
WHERE
    s.status & 5 = 5

On Old Server Database is configured for custom User & has DB Owner rights You export the database & import it on New Server Create the same DB username & configure this DBuser to be a DB Owner

You receive following error:

 Microsoft SQL Server Management Studio

Create failed for User ‘DB User’.  (Microsoft.SqlServer.Smo)

User, group, or role ‘ DB User ‘ already exists in the current database. (Microsoft SQL Server, Error: 15023)

Solution :

EXEC sp_change_users_login ‘Auto_Fix’, ‘DB User’

Other info :

First, make sure that this is the problem. This will lists the orphaned users:

EXEC sp_change_users_login ‘Report’

If you already have a login id and password for this user, fix it by doing:

EXEC sp_change_users_login ‘Auto_Fix’, ‘user’

If you want to create a new login id and password for this user, fix it by doing:

EXEC sp_change_users_login ‘Auto_Fix’, ‘user’, ‘login’, ‘password

 Source :

http://stupidprogrammer.com/2009/02/20/user-already-exists-in-the-current-database/

Before I forget this again … if you are not a member of the sysadmin role you need to run this to debug SQL 2000 stored procedures in Visual Studio.

USE [master];
GO

GRANT EXECUTE ON sp_sdidebug TO [User\Group\Role];

Clustered Index

1. Leaf node contains the actual data pages.
2. The data row of the table are sorted and stored in the table based on their clustered index key (i.e. based on the index column(s)).
3. You can have only one clustered index per table.
4. The RowLocator in Clustered Index is the clustered Index key.

Non Clustered Index

1. Leaf node contains index pages instead of data pages.
2. You can have up to 249 Non Clustered Index per table.
3. The data row of the table are not sorted and stored in the table based on their clustered index key (i.e. based on the index column(s)).
4. The row locator in Non Clustered Index is a pointer to the row. Row locator is built based on the following.
   ROW ID (RowLocator)= file identifier + page number + row number on the page
5. You can have the functionality of Non key Columns (Included Columns) in case of Non Clustered Index.
6. Non key columns are stored only at the leaf level whereas Key columns (Non Clustered Index Key columns) are stored at all the levels of non clustered index.

What are Heaps?

1. Heaps are tables without clustered index.
2. Data Rows are not stored in a particular order.
3. Sequences of the Data pages are not ordered as well as they are not linked in a linked list.

Examples

Clustered Index Example

Clustered can be created in the following ways

1. Create Table with Primary key – this will by default create clustered index based on the primary key defined.
2. Create clustered Index using the CREATE CLUSTERED INDEX command.

–create table with primary key
CREATE TABLE Employee (empno NUMERIC (10) PRIMARY KEY, EmpName Varchar(10));

–check the existence of Index for the table

SELECT * FROM SYS.INDEXES WHERE OBJECT_ID = (SELECT OBJECT_ID FROM SYS.OBJECTS WHERE NAME=‘EMPLOYEE’);

–create table without primary key

CREATE TABLE Employee2 (empno NUMERIC (10), EmpName Varchar(10));

–Create Clustered Index using Clustered Index  Command

CREATE CLUSTERED INDEX IDX_CLUST_EMP ON Employee2 (empno);

–check the existence of Index for the table

SELECT * FROM SYS.INDEXES WHERE OBJECT_ID = (SELECT OBJECT_ID FROM SYS.OBJECTS WHERE NAME=‘Employee2′);

Non Clustered Index Example

– Adding a column the existing employee table

ALTER TABLE EMPLOYEE
ADD TAX_ID NUMERIC(10);

–create non clustered index on TAX_ID column
CREATE INDEX IDX_NON_CLUST ON EMPLOYEE (TAX_ID);

–check the existence of Index for the table
SELECT * FROM SYS.INDEXES WHERE OBJECT_ID = (SELECT OBJECT_ID FROM SYS.OBJECTS WHERE NAME=‘EMPLOYEE’);

This is a very basic and a quick information on the differences between Clustered and Non Clustered Indexes in SQL Server.

Part I: Non-Clustered Index

Creating a Table

To better explain SQL Server non-clustered indexes; let’s start by creating a new table and populating it with some sample data using the following scripts. I assume you have a database you can use for this. If not, you will want to create one for these examples.

Create Table DummyTable1
(
EmpId Int,
EmpName Varchar(8000)
)

When you first create a new table, there is no index created by default. In technical terms, a table without an index is called a “heap”. We can confirm the fact that this new table doesn’t have an index by taking a look at the sysindexes system table, which contains one for this table with an of indid = 0. The sysindexes table, which exists in every database, tracks table and index information. “Indid” refers to Index ID, and is used to identify indexes. An indid of 0 means that a table does not have an index, and is stored by SQL Server as a heap.

Now let’s add a few records in this table using this script:

Insert Into DummyTable1 Values (4, Replicate (‘d’,2000))
GO

Insert Into DummyTable1 Values (6, Replicate (‘f’,2000))
GO

Insert Into DummyTable1 Values (1, Replicate (‘a’,2000))
GO

Insert Into DummyTable1 Values (3, Replicate (‘c’,2000))
GO

Now, let’s view the contests of the table by executing the following command in Query Analyzer for our new table.

Select EmpID From DummyTable1
GO

As you would expect, the data we inserted earlier has been displayed. Note that the order of the results is in the same order that I inserted them in, which is in no order at all.

Now, let’s execute the following commands to display the actual page information for the table we created and is now stored in SQL Server.

dbcc ind(dbid, tabid, -1) – This is an undocumented command.

DBCC TRACEON (3604)
GO

Declare @DBID Int, @TableID Int
Select @DBID = db_id(), @TableID = object_id(‘DummyTable1′)

DBCC ind(@DBID, @TableID, -1)
GO

This script will display many columns, but we are only interested in three of them, as shown below.

Here’s what the information displayed means:

PagePID is the physical page numbers used to store the table. In this case, three pages are currently used to store the data.

IndexID is the type of index,

Where:

0 – Datapage

1 – Clustered Index

2 – Greater and equal to 2 is an Index page (Non-Clustered Index and ordinary index),

PageType tells you what kind of data is stored in each database,

Where:

10 – IAM (Index Allocation MAP)

1 – Datapage

2 – Index page

Now, let us execute DBCC PAGE command. This is an undocumented command.

DBCC page(dbid, fileno, pageno, option)

Where:

dbid = database id.

Fileno = fileno of the page.  Usually it will be 1, unless we use more than one file for a database.

Pageno = we can take the output of the dbcc ind page no.

Option = it can be 0, 1, 2, 3. I use 3 to get a display of the data.  You can try yourself for the other options.

Run this script to execute the command:

DBCC TRACEON (3604)
GO

DBCC page(@DBID, 1, 26408, 3)
GO

The output will be page allocation details.

DBCC TRACEON (3604)
GO

dbcc page(@DBID, 1, 26255, 3)
GO

The data will be displayed in the order it was entered in the table. This is how SQL stores the data in pages.  Actually, 26255 & 26409 both display the data page.

I have displayed the data page information for page 26255 only. This is how MS SQL stores the contents in data pages as such column name with its respective value.

Record Type = PRIMARY_RECORD

EmpId          = 4

EmpName    = ddddddddddddddddddddddddddddddddddddddddddddddddddd
ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd

Record Type = PRIMARY_RECORD

EmpId            = 6

EmpName      = ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Record Type = PRIMARY_RECORD

EmpId           = 1

EmpName     = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

This displays the exact data storage in SQL, without any index on table. Now, let’s go and create a unique non-clustered index on the EmpID column.

Creating a Non-Clustered Index

Now, we will create a unique non-clustered index on the empid column to see how it affects the data, and how the data is stored in SQL Server.

CREATE UNIQUE NONCLUSTERED INDEX DummyTable1_empid
ON DummyTable1 (empid)
GO

Now, execute the DBCC ind (dbid, tabid, -1)

DBCC TRACEON (3604)
GO

Declare @DBID Int, @TableID Int
Select @DBID = db_id(), @TableID = object_id(‘DummyTable1′)
DBCC ind(@DBID, @TableID, -1)
GO

Here are the results:

Now, we see two more rows than before, which now contains index page details. Page 26408 displays the page allocation details, and pages 26255 and 26409 display the data page details, as before.

In regard to the new pages, page 26411 displays the page allocation details of an index page and page 26410 displays the index page details.

MS SQL generates a page (pagetype = 10) for an index and explains the page allocation details for an index. It shows the number of index page have been occupied for an index.

Let us see what would be the output for page 26411, that is page type = 10

IAM: Single Page Allocations @0×308A608E

—————————————–

Slot 0 = (1:26410)

Let us view page 26410 to see the index page details.

DBCC TRACEON (3604)
GO

DBCC page(10, 1, 26410, 3)
GO

SQL populates the index column data in order. The last column (?) is pointed to the row locator.

Here are the results, using two different methods:

Method I

The row location display in one of two ways:

• If the table does not have a clustered index, the row locator will be combination of fileno, pageno and the no of rows in a page.
• If the table does have clustered index, the row location will be clustered index key value.

Non-clustered indexes are particularly handy when we want to return a single row from a table.

For example, to search for employee ID (empid = 3) in a table that has a non-clustered index on the empid column, SQL Server looks through the index to find an entry that lists the exact page and row in the table where the matching empid can be found, and then goes directly to that page and row. This greatly speeds up accessing the record in question.

Select EmpID, EmpName From DummyTable1 WHERE EMPID = 3

Now, let’s insert some more rows in our table and view the data page storage of our non-clustered index.

Insert Into DummyTable1 Values (10, Replicate (‘j’,2000))
GO

Insert Into DummyTable1 Values (2, Replicate (‘b’,2000))
GO

Insert Into DummyTable1 Values (5, Replicate (‘e’,2000))
GO

Insert Into DummyTable1 Values (8, Replicate (‘h’,2000))
GO

Insert Into DummyTable1 Values (9, Replicate (‘i’,2000))
GO

Insert Into DummyTable1 Values (7, Replicate (‘g’,2000))
GO

Now, let’s view the data in our table.

Execute:

Select EmpID From DummyTable1

Here are the results:

As you may notice above, the data is still in the order we entered it, and not in any particular order. This is because adding the non-clustered index didn’t change how the data was stored and ordered on the data pages.

Now, let’s view the results of the DBCC IND command. In order to find out what happened when the new data was added to the table.

DBCC TRACEON (3604)
GO

Declare @DBID Int, @TableID Int
Select @DBID = db_id(), @TableID = object_id(‘DummyTable1′)
DBCC ind(@DBID, @TableID, -1)
GO

Here are the results:

Let us execute the page 26410 again and get the index page details.

DBCC TRACEON (3604)
GO

dbcc page(10, 1, 26410, 3)
GO

SQL Server populates the index column data in order.  The last column (?) is pointed to the row locator.

Here are the results:

Method I

As I explained earlier, there are two types of row locations. We have seen Method I.  Now, let’s try Method II with the help of a clustered and non-clustered index in a table. DummyTable1 already has a non-clustered index. Let’s now add a new column to the DummyTabl1 table and add a clustered index on that column.

Alter Table DummyTable1 Add EmpIndex Int IDENTITY(1,1)
GO

This will link the clustered index key value, instead of the row locator, and be will the combination of fileno, pageno and no of rows in a page.

This adds the Empindex column to DummyTable1. I have used an identity column so that we will not have null values on that column.

You can execute the DBCC ind and DBCC page to check if there any change after the new column is added to the table. If you don’t want to check this yourself, I can tell you that adding the new column did not affect the total number of pages currently allocated to the table by SQL Server.

Now, let’s add a unique clustered index on the empindex column and then view the differences in page 26410.

First, we execute the DBCC ind command.  This displays a new set of pages for dummytable1.

DBCC TRACEON (3604)
GO

Declare @DBID Int, @TableID Int
Select @DBID = db_id(), @TableID = object_id(‘DummyTable1′)
DBCC ind(@DBID, @TableID, -1)
GO

Here are the results:

Pages 26415 and 26420 have page allocation details.  Pages 26414, 26417 and 26418 have data page details.

Now, let’s view pages 26416 and 26419 and see the output.

DBCC TRACEON (3604)
GO

DBCC page(10, 1, 26416, 3)
GO

Here are the results:

This displays the output of the clustered index page, which has got a link to data page (ChildPageID).  EMPID is an index column that contains the starting row of the page.

DBCC TRACEON (3604)
GO

DBCC page(10, 1, 26419, 3)
GO

Here are the results:

Method II

It is interesting to see the differences now. There is a difference between Method I andMethod II.  Method II is now linked to a clustered index key.

The main difference between Method I and Method II is the link to a row in a data page.

Part II: Clustered Index

Creating a Table

To better explain how SQL Server creates clustered indexes; let’s start by creating a new table and populating it with some sample data using the following scripts. You can use the same sample database as before.

Create Table DummyTable2

(
EmpId Int,
EmpName Varchar(8000)
)

As in the previous example, when you first create a new table, there is no index created by default, and a heap is created. As before, we can confirm the fact that this new table doesn’t have an index by taking a look at the sysindexes system table, which contains one for this table with an of indid = 0. The sysindexes table, which exists in every database, tracks table and index information. “Indid” refers to Index ID, and is used to identify indexes. An indid of 0 means that a table does not have an index, and is stored by SQL Server as a heap.

Now let’s add a few records in this table using this script:

Insert Into DummyTable2 Values (4, Replicate (‘d’,2000))
GO

Insert Into DummyTable2 Values (6, Replicate (‘f’,2000))
GO

Insert Into DummyTable2 Values (1, Replicate (‘a’,2000))
GO

Insert Into DummyTable2 Values (3, Replicate (‘c’,2000))
GO

Now, let’s view the contents of the table by executing the following command in Query Analyzer for our new table.

Select EmpID From DummyTable2
GO

As you would expect, the data we inserted has been displayed. Note that the order of the results is in the same order that I inserted them in, which is in no order at all.

Now, let’s execute the following commands to display the actual page information for the table we created and is now stored in SQL Server.

DBCC ind(dbid, tabid, -1) – It is an undocumented command.

DBCC TRACEON (3604)
GO

Declare @DBID Int, @TableID Int
Select @DBID = db_id(), @TableID = object_id(‘DummyTable2′)
DBCC ind(@DBID, @TableID, -1)
GO

This script will display many columns, but we are only interested in three of them, as shown below.

Here are the results:

Here’s what the information displayed means:

PagePID is the physical page numbers used to store the table. In this case, three pages are currently used to store the data.

IndexID is the type of index,

Where:

0 – Datapage

1 – Clustered Index

2 – Greater and equal to 2 is an Index page (Non-Clustered Index and ordinary index)

PageType tells you what kind of data is stored in each database

Where:

10 – IAM (Index Allocation MAP)

1 – Datapage

2 – Index page

Now, let us execute DBCC PAGE command.

DBCC page(dbid, fileno, pageno, option)

Where:

dbid = database id.

Fileno = fileno of the page.  Usually it will be 1, unless we use more than one file for a database.

Pageno = we can take the output of the dbcc ind page no.

Option = it can be 0, 1, 2, 3. I use 3 to get a display of the data.  You can try yourself for the other options.

Run this script to execute the command:

DBCC TRACEON (3604)
GO

DBCC page(@DBID, 1, 26408, 3)
GO

The output will be page allocation details.

DBCC TRACEON (3604)
GO

DBCC page(@DBID, 1, 26255, 3)
GO

The output will display the data however it was entered in the table. This is how SQL stores the data in pages. Actually, 26255 & 26409 will display the data page.

I have displayed the data page information for page 26255 only. This is how MS-SQL stores the contents in data pages as such column name with its respective value.

Record Type = PRIMARY_RECORD

EmpId          = 4

EmpName    = dddddddddddddddddddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd

Record Type = PRIMARY_RECORD

EmpId           = 6

EmpName     = ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Record Type = PRIMARY_RECORD

EmpId           = 1

EmpName     = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

This displays the exact data storage in SQL without any index on table. Now, let’s go and create a Unique Clustered Index on EmpID column.

Create a Clustered Index

Now, let us create a unique clustered index on empid column to see how it affects the data that is stored in SQL Server.

CREATE UNIQUE CLUSTERED INDEX DummyTable2_EmpIndex
ON DummyTable2 (EmpID)
GO

Execute:

Select EmpID From DummyTable2

Here are the results:

Now, execute the DBCC ind (dbid, tabid, -1)

DBCC TRACEON (3604)
GO

Declare @DBID Int, @TableID Int

Select @DBID = db_id(), @TableID = object_id(‘DummyTable2′)

DBCC ind(@DBID, @TableID, -1)
GO

Here are the results:

MS SQL generates a page (pagetype = 10) for an index and explains the page allocation details for an index. It shows the number of index page have been occupied for an index.

Now, let us view the page 26410 and 26412 and see the page details.

DBCC TRACEON (3604)
GO

DBCC page(10, 1, 26412, 3)
GO

Here are the results:

The output display many columns, but we are only interested in four of them as shown above.

This will display the output of the index page, which has got link to data page (ChildPageID).  EMPID is an index column will contain the starting row of the page.

Now, let us view the page 26410 and see the page details.

DBCC TRACEON (3604)
GO

DBCC page (10, 1, 26410, 3)
GO

Here are the results:

Record Type = PRIMARY_RECORD

EmpId            = 1

EmpName          = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Record Type = PRIMARY_RECORD

EmpId            = 2

EmpName          = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

Record Type = PRIMARY_RECORD

EmpId            = 3

EmpName          = cccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

Though I have added disorder records, SQL has displayed the data page in sequence because we have got a clustered index on empid. This is absolutely great!  Adding a clustered index to the table has physically reordered the data pages, putting them in physical order based on the indexed column.

Now, let’s insert some more rows in our table and view the data and index page storage of our clustered index.

Insert Into DummyTable2 Values (10, Replicate (‘j’,2000))
GO

Insert Into DummyTable2 Values (2, Replicate (‘b’,2000))
GO

Insert Into DummyTable2 Values (5, Replicate (‘e’,2000))
GO

Insert Into DummyTable2 Values (8, Replicate (‘h’,2000))
GO

Insert Into DummyTable2 Values (9, Replicate (‘i’,2000))
GO

Insert Into DummyTable2 Values (7, Replicate (‘g’,2000))
GO

Now, execute the DBCC ind (dbid, tabid, -1)

DBCC TRACEON (3604)
GO

Declare @DBID Int, @TableID Int

Select @DBID = db_id(), @TableID = object_id(‘DummyTable2′)

DBCC ind(@DBID, @TableID, -1)
GO

Here are the results:

Now, we see few more rows than before. Page 26411 displays the page allocation details, and pages 26408, 26409, 26410 and 26255 display the data page details, as before.

In regard to the new pages, page 26411 displays the page allocation details of an index page and 26412 displays the index page details.

MS-SQL generates a page (pagetype = 10) for an index and explains the page allocation details for an index.  It shows the number of index page have been occupied for an index.

Let us see what would be the output for page 26411, that is page type = 10.

DBCC TRACEON (3604)
GO

dbcc page(10, 1, 26411, 3)
GO

Here are the results:

IAM: Single Page Allocations @0×30A5C08E

—————————————–

Slot 0 = (1:26410)

Slot 1 = (1:26412)

Slot 2 = (1:26255)

Slot 3 = (1:26408)

Slot 4 = (1:26409)

Let us view page 26412 to see the index page details.

DBCC TRACEON (3604)
GO

DBCC page(10, 1, 26412, 3)
GO

Here are the results:

This helps us to get an idea to decide the need of clustered index. It is really useful to have a clustered index when retrieve many rows of data, ranges of data, and when BETWEEN is used in the WHERE clause. Because, the leaf level of the clustered index is the data. It should be used to save many I/Os. So, it is better to use clustered indexes to solve queries asking for ranges of data, not one row.

For example, to search for an employee ID (empid between 3 and 9) in a table that has a clustered index on the empid column.

Select EmpID, EmpName From DummyTable1 WHEREEMPID Between 3 And 9

The writing of stored procedures is a very common task in todays database world. Not only by database developers, but also application developers are writing the procedures. DBA’s also need to write procedures. In fact, I have faced a very common question in my interviews: ” How many stored procedures have you written?”

Since the world is going for fat servers (a server which runs an application where most of the program code resides on it rather than on the client computers), stored procedures are gaining more and more importance. Here is my humble try to give some tips to write good procedures. I hope this will add value for novice as well as experienced programmers.

1. Keywords – Use SQL keywords in capital letters to increase readability. Also use proper indentation to increase readability.

2. SQL-92 – Always try to use ANSI 92 syntax. Till now the old syntax is working the old syntax will be deprecated in the next release of MS SQL server.
As an example, for joining, use

Instead of

3. Variables – Use as few as possible variables. It frees spaces in cache.

4. Dynamic Queries – Try to minimize the usage of dynamic queries. If you are using a dynamic query like: SELECT * FROM mydb.dbo.emp where empid = @eid then there is no problem. You can supply a value for the @eid parameter and there is no recompilation of the execution plan in the database cache. But if you are using a SQL query like SELECT * FROM emp where empid = ” + @eid and supply a parameter (say 100), then the cache will keep the execution plan for the value of 100 only. If the id changes (to say 101), it will recompile the statement. Hence, this approach is slower than the previous one. (You can get the exact value of the SQL statement from Profiler)

5. Fully Qualified Names – Always use the fully qualified name when calling stored procedures. This would be the format database_name.schema_name.table_name. For example, use EXEC master.dbo.Your_Proc_name instead of EXEC Your_Proc_name This is a very common mistake, which causes an extra trip to the procedure cache to get the execution plan for execution. Also try to use the schema name while creating a procedure. Like: CREATE PROCEDURE dbo.Your_Proc_name instead of CREATE PROCEDURE Your_Proc_name

6.SET NOCOUNT OFF – This returns the message that shows number of rows affected by SQL statement. This can cause extra network traffic and can have some serious impact on performance when the procedure is called frequently.

7. The sp_ prefix – Don’t use the “sp_” prefix in a stored procedure name as the “sp_” prefix is reserved for system stored procedures. Any stored procedure that has the “sp_” prefix will cause an extra lookup in the MASTER database If a stored procedure uses same name in both the user database and a system database, the stored procedure in the user database will never get executed.

8. sp_executeSQL and the KEEPFIXED PLAN options – Both sp_executesql and the KEEPFIXED PLAN option avoid the recompilation of a stored procedure. If you want to provide parameterized dynamic SQL, then go for sp_executesql instead of EXEC(proc_name). Here the execution plan for the procedure is stored with the variable name in cache memory. When the variable values are supplied, then the values are simply mapped to the query, hence no need for a recompilation.

Use the OPTION KEEPFIXED PLAN hint while selecting records from temporary tables. If the query contains this hint, then its plan is not recompiled. For more information about procedure recompilation, please go through the following article:http://technet.microsoft.com/en-us/library/cc966425.aspx

As an example of sp_executesql, we can write:

9. SELECT vs SET – A single SELECT statement can assign values to different variables and is much faster than multiple SET statements assigning values to multiple different variables.

instead of

10. WHERE clauses – In a WHERE clause, the various operators used directly affect how fast a query can run. Here are the conditional operators used in the WHERE clause, ordered by their performance.

=, >, <, >=, <=, <>, !=, !>, !<

for details, refer to the article: http://msdn.microsoft.com/en-us/library/ms190276.aspx

11. More WHERE clause hints – Avoid unnecessary conditions in the WHERE Clause. You can easily use the first example instead of the second one. The second example uses one extra OR condition which can be avoided using the first example.

Also, try to avoid IN. While checking the existence of some values, then use EXISTS instead of IN. Because IN counts the NULL values also, hence slower than EXISTS. Since EXISTS returns Boolean(Yes/No) but IN returns all values hence result set for IN is heavier than EXISTS.

12. CAST and CONVERT – Try to use CAST instead of CONVERT. CAST is ANSI-92 standard but CONVERT works in MS SQL server only. Also, Convert may be deprecated in future MS SQL releases. It is better to use CONVERT only when you need to format the DATETIME datatype with the style option. CAST cannot do this.

13. Avoid DISTINCT and ORDER BY – If you don’t need the DISTINCT/ORDER BY clause, then try to avoid so. Unnecessary DISTINCT or ORDER BY clauses cause extra work for the database engine. Hence making performance slower.

14. Avoid using cursors – Try to use temporary table/table variables with identity column and then iterate all the tables using WHILE loop and a looping counter, which will map with the identity column. For details, refer my previous article.http://www.sqlservercentral.com/articles/Stored+Procedures/64523/

15.SELECT statements – Try to use only the required number of columns in the SELECT clause instead of using *. Using * returns all columns, which unnecessarily create a fat recordset.

16.Subquery vs JOINs – This is a famous debate in many online forums. In fact most sub queries can be expressed as an equivalent form of JOIN. I have a good rule of thumb: subquery is faster when we have to retrieve data from large number of tables because it becomes tedious to join more tables. JOIN is faster to retrieve data from database when we have less number of tables. But try to avoid correlated sub queries because it makes the query much slower.

17. CREATE TABLE vs. SELECT INTO – Select * INTO works fine for small tables, but when dealing with large record sets or long-running queries, it creates locks on the system objects within the tempdb database. As a result, other queries and procedures that need to create objects within the tempdb database will have to wait for the long-running query to complete. This is because when an object is created, an exclusive lock is taken against the sysobjects, syscolumns, sysindexes tables.

Also, SELECT INTO not only copies data but also it copies the table structure, hence it performs slower.

18. Try to use table variables instead of Temporary Tables – Temp tables can cause stored procedures to recompile. But table variables were designed specifically to guard against stored procedure recompiles during execution.

If the result set is not containing a huge number of records then you should stick to table variable, otherwise temp table has its advantages. There is a misconception that temp tables always use the tembdb database but table variable do not. Table variables also use tempdb after a certain size. For more information refer to the following article : http://www.sqlservercentral.com/articles/Temporary+Tables/66720/

19.Use proper indexes – You can use the help of the data tuning advisor, but it does not gives the proper result all the time. Index scans are much faster than table scans. So identify the table scans from the execution plans. But when a table returns smaller rows, then it is better to use a table scan. You can see an excellent article on execution plans by G Vijayakumara at the following link:http://www.sqlservercentral.com/articles/Administration/executionplans/1345/

20. Use Profiler – The cachemiss event class indicates that the stored procedure is not in the cache. If the SP:Cachemiss class occurs frequently, it can indicate that more memory should be available to MS SQL server, thereby increasing the size of procedure cache. The cachehit event class indicates that a stored procedure is in the cache.

Last but not the least, again I am repeating the same advice from my previous article. Keep these guidelines in your mind, but don’t hesitate to break them if needed. After all, performance is the ultimate goal. If violating the general rule gives you good performance (it may happen based on your database) then don’t stick with the guidelines.

Using Index
================
select *from ZIPCodes where StateName = ‘New York’

– Create Index
create nonclustered index idxStateName on ZIPCodes(StateName)
create nonclustered index idxZIPType on ZIPCodes(ZIPType)

– Use Index
select *from ZIPCodes with(INDEX(idxZIPType)) where ZIPType = ‘S’

– List of Indexes on Perticular Table
exec sp_helpindex ‘ps_client_master’

– Drop Index
drop index ps_client_master.ps_client_master_Index_1

Using Cursors
===============

DECLARE @ClientID char(11)

declare cl CURSOR FOR
select int_id from ps_client_master

open cl

FETCH NEXT FROM cl into @ClientID
while @@FETCH_STATUS = 0
begin
print @ClientID
fetch next from cl into @ClientID
end

close cl
DEALLOCATE cl

Using Index
================
select *from ZIPCodes where StateName = ‘New York’

– Create Index
create nonclustered index idxStateName on ZIPCodes(StateName)
create nonclustered index idxZIPType on ZIPCodes(ZIPType)

– Use Index
select *from ZIPCodes with(INDEX(idxZIPType)) where ZIPType = ‘S’

– List of Indexes on Perticular Table
exec sp_helpindex ‘ps_client_master’

– Drop Index
drop index ps_client_master.ps_client_master_Index_1

Using Cursors
===============

DECLARE @ClientID char(11)

declare cl CURSOR FOR
select int_id from ps_client_master

open cl

FETCH NEXT FROM cl into @ClientID
while @@FETCH_STATUS = 0
begin
print @ClientID
fetch next from cl into @ClientID
end

close cl
DEALLOCATE cl