Showing posts with label indexes. Show all posts
Showing posts with label indexes. Show all posts

Thursday, March 29, 2012

Dropping indexes before bulk insert

Hi all,

I have a huge table 170 Gb of size. On that table we have 10 indexes
of around 12 GB in size.

The application is designed such that it bulk inserts the file in to
sql server. But , often we are getting time outs and some latching
isssues ( as can be seen in activity monitor).

So, will this be a good idea of dropping those indexes and then
recreating them again for better performance.

1) Its SQL 2005 Standard Edition SP1

2) Databases are in SIMPLE Recovery mode.

3) Database is not OLTP.

Thanks.

//N

Hi Naj,

Do you see any blocking on the server while the bulk insert is running?

How do you mean latches issues ?

Could you please look for waittime and waitypes in the following view and let us know what is there.

select * from sys.dm_os_waiting_tasks where session_id > 50

Jag

|||

you should be better off by dropping indexes and after bulk insert creating them off line. indexes created offline have very small footprint on log and much faster then indexes created online. as a trade off your table will be offline for a while. how long it depends on clustered key as with large table clustered key plays very vital role when rebuilding indexes.

another point is to consider switching off AUTO_UPDATE_STATISTICS while inserting rows into your table. this will kill the performance while inserting data and updating staticstics at the same time. also there is a new option AUTO_UPDATE_STATISTICS_ASYNC which provide background statistics update. use with extra care as they can hinder performance significatly.

see article http://www.mssqltips.com/tip.asp?tip=1193

Dropping Indexes

I'm doing some bulk inserting into various tables, and I'm dropping all the
indexes first, and rebuilding them after the data load. One of the tables
has several nonclustered indexes + a clustered index. My question is
simple: does the order I drop the indexes make a difference in the speed
with which they are dropped? My thought is that the clustered index should
be dropped last. Any suggestions?
ThanksFrom the Books Online topic "Dropping Indexes"
Dropping a clustered index can take time because in addition to dropping the
clustered index, all nonclustered indexes on the table must be rebuilt to
replace the clustered index keys with row pointers to the heap. When you
drop all indexes on a table, drop the nonclustered indexes first and the
clustered index last. That way, no indexes have to be rebuilt.
Gail Erickson [MS]
SQL Server Documentation Team
This posting is provided "AS IS" with no warranties, and confers no rights
Download the latest version of Books Online from
http://www.microsoft.com/technet/pr...oads/books.mspx
"Mike C#" <xyz@.xyz.com> wrote in message
news:OvpqShbhGHA.1276@.TK2MSFTNGP03.phx.gbl...
> I'm doing some bulk inserting into various tables, and I'm dropping all
> the indexes first, and rebuilding them after the data load. One of the
> tables has several nonclustered indexes + a clustered index. My question
> is simple: does the order I drop the indexes make a difference in the
> speed with which they are dropped? My thought is that the clustered index
> should be dropped last. Any suggestions?
> Thanks
>|||That's what I figured, just wanted to make sure. Thanks Gail.
"Gail Erickson [MS]" <gaile@.online.microsoft.com> wrote in message
news:Odo3RpbhGHA.4864@.TK2MSFTNGP03.phx.gbl...
> From the Books Online topic "Dropping Indexes"
> Dropping a clustered index can take time because in addition to dropping
> the clustered index, all nonclustered indexes on the table must be rebuilt
> to replace the clustered index keys with row pointers to the heap. When
> you drop all indexes on a table, drop the nonclustered indexes first and
> the clustered index last. That way, no indexes have to be rebuilt.
> --
> Gail Erickson [MS]
> SQL Server Documentation Team
> This posting is provided "AS IS" with no warranties, and confers no rights
> Download the latest version of Books Online from
> http://www.microsoft.com/technet/pr...oads/books.mspx
> "Mike C#" <xyz@.xyz.com> wrote in message
> news:OvpqShbhGHA.1276@.TK2MSFTNGP03.phx.gbl...
>sql

Tuesday, March 27, 2012

dropping and recreating a table

I recall reading somewhere that there are benefits to dropping and
recreating the table, then recreating it's indexes. This is as opposed to
just dropping and recreating the indexes.
Thanks
Regards
JTC ^..^I don't know that there are any advantages to this that you couldn't get via
DBCC statements... Maybe some defragmentation benefits, but you should be
able to get those via DBCC w/o dropping the table...
"JTC ^..^" <dave@.(nospam)JazzTheCat.co.uk> wrote in message
news:Xns9620E1385E1A7daveJTC@.217.32.252.50...
>I recall reading somewhere that there are benefits to dropping and
> recreating the table, then recreating it's indexes. This is as opposed to
> just dropping and recreating the indexes.
> Thanks
> --
> Regards
> JTC ^..^

dropping and recreating a table

I recall reading somewhere that there are benefits to dropping and
recreating the table, then recreating it's indexes. This is as opposed to
just dropping and recreating the indexes.
Thanks
--
Regards
JTC ^..^I don't know that there are any advantages to this that you couldn't get via
DBCC statements... Maybe some defragmentation benefits, but you should be
able to get those via DBCC w/o dropping the table...
"JTC ^..^" <dave@.(nospam)JazzTheCat.co.uk> wrote in message
news:Xns9620E1385E1A7daveJTC@.217.32.252.50...
>I recall reading somewhere that there are benefits to dropping and
> recreating the table, then recreating it's indexes. This is as opposed to
> just dropping and recreating the indexes.
> Thanks
> --
> Regards
> JTC ^..^

dropping and recreating a table

I recall reading somewhere that there are benefits to dropping and
recreating the table, then recreating it's indexes. This is as opposed to
just dropping and recreating the indexes.
Thanks
Regards
JTC ^..^
I don't know that there are any advantages to this that you couldn't get via
DBCC statements... Maybe some defragmentation benefits, but you should be
able to get those via DBCC w/o dropping the table...
"JTC ^..^" <dave@.(nospam)JazzTheCat.co.uk> wrote in message
news:Xns9620E1385E1A7daveJTC@.217.32.252.50...
>I recall reading somewhere that there are benefits to dropping and
> recreating the table, then recreating it's indexes. This is as opposed to
> just dropping and recreating the indexes.
> Thanks
> --
> Regards
> JTC ^..^
sql

Dropping all indexes with a single query?

Would that it were so simple! I tried that method, no go because
there are constraints that have to be deleted first. So, I figure OK,
I'll just kill the constraints first, then the indexes will go away
with ease. NOT! Since there are two ways to do things, using
standard SQL and using the SQLDMO object, I tried both. Here
is where I am with the code right now:
'******************************
Dim server
Dim tbcnt
Dim idcnt
Dim kecnt
Dim i, j, k
Dim tblname
Dim keyname
Dim sql
Set server = CreateObject("SQLDMO.SQLServer")
server.Connect "Server", "sa", ""
i = "Northwind"
tbcnt = server.Databases(i).Tables.Count
For j = 1 to tbcnt
If server.Databases(i).Tables(j).TypeOf = 8 Then
tblname = server.Databases(i).Tables(j).Name
kecnt = server.Databases(i).Tables(j).Keys.Count
idcnt = server.Databases(i).Tables(j).Indexes.Count
For k = 1 to kecnt
keyname = server.Databases(i).Tables(j).Keys(k).Name
' was: server.Databases(i).Tables(j).Keys(k).Remove
sql = "USE " & i & vbCrLf & _
"ALTER TABLE " & tblname & vbCrLf & _
"DROP CONSTRAINT " & keyname
server.ExecuteImmediate(sql)
Next
For k = 1 to idcnt
server.Databases(i).Tables(j).Indexes(k).Remove
Next
End If
Next
'******************************
Now, Keys here are really constraints, so I tried this, using a
mixture of SQL and VB code, and I also tried it with all VB,
and all SQL as well. No matter what I try, I keep getting
'Constrain xxxx is being referenced by Foreign Key uuuu...etc.
and
'Could not drop constraint xxxx'
Does anyone know if this can be automated like this? If so,
How? I'm already past tearing my hair out, I hate to think
what happens next...
"Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
news:%23d0XGCbQEHA.2132@.TK2MSFTNGP11.phx.gbl...
> So, run the first query, bring back the "DROP INDEX ...; GO; DROP INDEX;
> GO;" statements into a variable, and then execute that just like you
> executed the initial query.
> A
>
How about drop the database and re-create it?
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"Gary Morris" <gwmorris1@.hotpop.com> wrote in message
news:O8YoOieQEHA.3748@.TK2MSFTNGP09.phx.gbl...
> Would that it were so simple! I tried that method, no go because
> there are constraints that have to be deleted first. So, I figure OK,
> I'll just kill the constraints first, then the indexes will go away
> with ease. NOT! Since there are two ways to do things, using
> standard SQL and using the SQLDMO object, I tried both. Here
> is where I am with the code right now:
> '******************************
> Dim server
> Dim tbcnt
> Dim idcnt
> Dim kecnt
> Dim i, j, k
> Dim tblname
> Dim keyname
> Dim sql
> Set server = CreateObject("SQLDMO.SQLServer")
> server.Connect "Server", "sa", ""
> i = "Northwind"
> tbcnt = server.Databases(i).Tables.Count
> For j = 1 to tbcnt
> If server.Databases(i).Tables(j).TypeOf = 8 Then
> tblname = server.Databases(i).Tables(j).Name
> kecnt = server.Databases(i).Tables(j).Keys.Count
> idcnt = server.Databases(i).Tables(j).Indexes.Count
> For k = 1 to kecnt
> keyname = server.Databases(i).Tables(j).Keys(k).Name
> ' was: server.Databases(i).Tables(j).Keys(k).Remove
> sql = "USE " & i & vbCrLf & _
> "ALTER TABLE " & tblname & vbCrLf & _
> "DROP CONSTRAINT " & keyname
> server.ExecuteImmediate(sql)
> Next
> For k = 1 to idcnt
> server.Databases(i).Tables(j).Indexes(k).Remove
> Next
> End If
> Next
> '******************************
> Now, Keys here are really constraints, so I tried this, using a
> mixture of SQL and VB code, and I also tried it with all VB,
> and all SQL as well. No matter what I try, I keep getting
> 'Constrain xxxx is being referenced by Foreign Key uuuu...etc.
> and
> 'Could not drop constraint xxxx'
> Does anyone know if this can be automated like this? If so,
> How? I'm already past tearing my hair out, I hate to think
> what happens next...
> "Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
> news:%23d0XGCbQEHA.2132@.TK2MSFTNGP11.phx.gbl...
>
|||How did I know you would say that
Actually I had thought of that, but was dearly hoping
that I wouldn't have to resort to it. I just cannot
believe that SQL Server will not allow this in an easier
way. It's no problem manually, but programmatically
it just won't work. Eight hours working on this one
problem today..not very productive. Why can't it just
work like the Sybase version?
Well, I'll hunt around some just to satisfy myself that
some nerdy guru hasn't found a way around this
already, then I'll look into the alternative. What I'm
trying to accomplish is a script that will drop just the
indexes of ALL the user tables, OR just the indexes
on specified tables. I won't go into the reasons, that's
just the way it has to work. Now, I have considered
just writing the sql out for each table, parsing it to
remove the constraint/index parts, and then reimport
the table(s) back into the db, which would work, I
just consider it to be a dirty hack, and I should have
a nice clean, acceptable way to do it. This sucks...
"Aaron Bertrand [MVP]" <aaron@.TRASHaspfaq.com> wrote in message
news:e%23lGhGgQEHA.252@.TK2MSFTNGP10.phx.gbl...[vbcol=seagreen]
> How about drop the database and re-create it?
> --
> Aaron Bertrand
> SQL Server MVP
> http://www.aspfaq.com/
>
> "Gary Morris" <gwmorris1@.hotpop.com> wrote in message
> news:O8YoOieQEHA.3748@.TK2MSFTNGP09.phx.gbl...
INDEX;
>
sql

Dropping all Data but keeping constraints and Structure Intact!

Hi All -
I have a SQL 2000 database of 60 some tables, with constraints, indexes, PK-
FK, and other relationships on them. I would like to drop all data in all
tables, knowing that a lot of the tables have full PK-FK-PK-FK ...
relationships cascading, and indexes and such. I want to keep intact all
that is not data. So basically truncate or delete all data and leave all
table structures with all their constraints etc ..
I wonder if such a script exists? that would be a great help.
Thank You In Advance.
Wise -
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200704/1On Apr 11, 7:20 pm, "wiseteufel via SQLMonster.com" <u4067@.uwe> wrote:
> Hi All -
> I have a SQL 2000 database of 60 some tables, with constraints, indexes, PK-
> FK, and other relationships on them. I would like to drop all data in all
> tables, knowing that a lot of the tables have full PK-FK-PK-FK ...
> relationships cascading, and indexes and such. I want to keep intact all
> that is not data. So basically truncate or delete all data and leave all
> table structures with all their constraints etc ..
> I wonder if such a script exists? that would be a great help.
> Thank You In Advance.
> Wise -
> --
> Message posted via SQLMonster.comhttp://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200704/1
You can script out the entire database ( with PK,FK, INDEX ,
Constraint options) and create a new database from the script .

Dropping all Data but keeping constraints and Structure Intact!

Hi All -
I have a SQL 2000 database of 60 some tables, with constraints, indexes, PK-
FK, and other relationships on them. I would like to drop all data in all
tables, knowing that a lot of the tables have full PK-FK-PK-FK ...
relationships cascading, and indexes and such. I want to keep intact all
that is not data. So basically truncate or delete all data and leave all
table structures with all their constraints etc ..
I wonder if such a script exists? that would be a great help.
Thank You In Advance.
Wise -
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200704/1On Apr 11, 7:20 pm, "wiseteufel via droptable.com" <u4067@.uwe> wrote:
> Hi All -
> I have a SQL 2000 database of 60 some tables, with constraints, indexes, P
K-
> FK, and other relationships on them. I would like to drop all data in all
> tables, knowing that a lot of the tables have full PK-FK-PK-FK ...
> relationships cascading, and indexes and such. I want to keep intact all
> that is not data. So basically truncate or delete all data and leave all
> table structures with all their constraints etc ..
> I wonder if such a script exists? that would be a great help.
> Thank You In Advance.
> Wise -
> --
> Message posted via droptable.comhttp://www.droptable.com/Uwe/Forums.aspx/sql-ser
ver/200704/1
You can script out the entire database ( with PK,FK, INDEX ,
Constraint options) and create a new database from the script .

Dropping all Data but keeping constraints and Structure Intact!

Hi All -
I have a SQL 2000 database of 60 some tables, with constraints, indexes, PK-
FK, and other relationships on them. I would like to drop all data in all
tables, knowing that a lot of the tables have full PK-FK-PK-FK ...
relationships cascading, and indexes and such. I want to keep intact all
that is not data. So basically truncate or delete all data and leave all
table structures with all their constraints etc ..
I wonder if such a script exists? that would be a great help.
Thank You In Advance.
Wise -
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200704/1
On Apr 11, 7:20 pm, "wiseteufel via droptable.com" <u4067@.uwe> wrote:
> Hi All -
> I have a SQL 2000 database of 60 some tables, with constraints, indexes, PK-
> FK, and other relationships on them. I would like to drop all data in all
> tables, knowing that a lot of the tables have full PK-FK-PK-FK ...
> relationships cascading, and indexes and such. I want to keep intact all
> that is not data. So basically truncate or delete all data and leave all
> table structures with all their constraints etc ..
> I wonder if such a script exists? that would be a great help.
> Thank You In Advance.
> Wise -
> --
> Message posted via droptable.comhttp://www.droptable.com/Uwe/Forums.aspx/sql-server/200704/1
You can script out the entire database ( with PK,FK, INDEX ,
Constraint options) and create a new database from the script .

Sunday, March 25, 2012

Dropping / Recreating Indexes

All -
You know when you generate the SQL script for a stored procedure, you get
that initial script at the top that first checks for the procedure in
sysobjects and drops it if it is found?
I want to do the same thing with indexes. I want to create a script that
will first delete a given index if its found and then create a new one.
How would you go about do this?
Thanks,
- Mattif exists (select * from dbo.sysindexes where name = 'IX_index_01' and id =object_id('dbo.tableA'))
drop index dbo.tableA.IX_index_01
GO
"Matthew Sajdera" <sajdera@.pcts.com> wrote in message
news:eeA8tWpkDHA.360@.TK2MSFTNGP12.phx.gbl...
> All -
> You know when you generate the SQL script for a stored procedure, you get
> that initial script at the top that first checks for the procedure in
> sysobjects and drops it if it is found?
> I want to do the same thing with indexes. I want to create a script that
> will first delete a given index if its found and then create a new one.
> How would you go about do this?
> Thanks,
> - Matt
>
>|||All -
Sorry about that. I found the DROP INDEX syntax.
Now it looks like the only problem is that if the index is a primary index,
you can't drop it. You have to drop the table, create the table, and then
re-create the index.
Does this sound right?
Thanks,
- Matt
"Matthew Sajdera" <sajdera@.pcts.com> wrote in message
news:eeA8tWpkDHA.360@.TK2MSFTNGP12.phx.gbl...
> All -
> You know when you generate the SQL script for a stored procedure, you get
> that initial script at the top that first checks for the procedure in
> sysobjects and drops it if it is found?
> I want to do the same thing with indexes. I want to create a script that
> will first delete a given index if its found and then create a new one.
> How would you go about do this?
> Thanks,
> - Matt
>
>|||Primary Key indexes are created as part of the Primary Key
Constraint. You cannot directly drop the index, but
instead you drop it by dropping the Primary Key
Constraint. So you don't have to drop the table. You must,
however, first drop any Foreign Key Constraints that
reference the PK.
HTH
Vern
>--Original Message--
>All -
>Sorry about that. I found the DROP INDEX syntax.
>Now it looks like the only problem is that if the index
is a primary index,
>you can't drop it. You have to drop the table, create
the table, and then
>re-create the index.
>Does this sound right?
>Thanks,
>- Matt
>
>"Matthew Sajdera" <sajdera@.pcts.com> wrote in message
>news:eeA8tWpkDHA.360@.TK2MSFTNGP12.phx.gbl...
>> All -
>> You know when you generate the SQL script for a stored
procedure, you get
>> that initial script at the top that first checks for
the procedure in
>> sysobjects and drops it if it is found?
>> I want to do the same thing with indexes. I want to
create a script that
>> will first delete a given index if its found and then
create a new one.
>> How would you go about do this?
>> Thanks,
>> - Matt
>>
>
>.
>|||Hi Matt
No, you certainly don't have to drop the whole table just to drop an index!
If an index supports a primary key constraint, you have to drop the
constraint, and that will automatically drop the index that supports the
constraint.
You can then readd the constraint.
sp_helpconstraint will show you the constraint names
to drop and re-add the constraint use:
ALTER TABLE ... DROP CONSTRAINT
ALTER TABLE ... ADD CONSTRAINT
Full details are in Books Online
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Matthew Sajdera" <sajdera@.pcts.com> wrote in message
news:e2aLycpkDHA.2432@.TK2MSFTNGP10.phx.gbl...
> All -
> Sorry about that. I found the DROP INDEX syntax.
> Now it looks like the only problem is that if the index is a primary
index,
> you can't drop it. You have to drop the table, create the table, and then
> re-create the index.
> Does this sound right?
> Thanks,
> - Matt
>
> "Matthew Sajdera" <sajdera@.pcts.com> wrote in message
> news:eeA8tWpkDHA.360@.TK2MSFTNGP12.phx.gbl...
> > All -
> >
> > You know when you generate the SQL script for a stored procedure, you
get
> > that initial script at the top that first checks for the procedure in
> > sysobjects and drops it if it is found?
> >
> > I want to do the same thing with indexes. I want to create a script
that
> > will first delete a given index if its found and then create a new one.
> >
> > How would you go about do this?
> >
> > Thanks,
> >
> > - Matt
> >
> >
> >
>|||What's the reason behind dropping and recreating the index? If the reason
is to rebuild it (remove fragmentation), then use DBCC DBREINDEX. This will
rebuild your index and you don't need to deal with dropping constraints.
Gail Erickson [MSFT]
SQL Server User Education
This posting is provided "AS IS" with no warranties, and confers no rights.
"Matthew Sajdera" <sajdera@.pcts.com> wrote in message
news:e2aLycpkDHA.2432@.TK2MSFTNGP10.phx.gbl...
> All -
> Sorry about that. I found the DROP INDEX syntax.
> Now it looks like the only problem is that if the index is a primary
index,
> you can't drop it. You have to drop the table, create the table, and then
> re-create the index.
> Does this sound right?
> Thanks,
> - Matt
>
> "Matthew Sajdera" <sajdera@.pcts.com> wrote in message
> news:eeA8tWpkDHA.360@.TK2MSFTNGP12.phx.gbl...
> > All -
> >
> > You know when you generate the SQL script for a stored procedure, you
get
> > that initial script at the top that first checks for the procedure in
> > sysobjects and drops it if it is found?
> >
> > I want to do the same thing with indexes. I want to create a script
that
> > will first delete a given index if its found and then create a new one.
> >
> > How would you go about do this?
> >
> > Thanks,
> >
> > - Matt
> >
> >
> >
>

Thursday, March 22, 2012

DROP_EXISTING

Im recreating some clustered indexes on my database tables, and i'm
planning use DROP_EXISTING like this:

CREATE
CLUSTERED INDEX [idx-clusteredindex]
ON
[dbo].[TABLE_NAME]([COLOUMN_NANE])
WITH
DROP_EXISTING,
FILLFACTOR = 90
ON
[PRIMARY]

As I understand this will also cause all non-clustered index
on the table to be rebuilt/recalculated as well.
Is this infact the case of do I have to
do i have to do it explicitly afterwards like:

DBCC DBREINDEX ([dbo].[TABLE_NAME],[idx-nonclustered],90)Sort of, but this would happen anyway if you rebuilt the clustered
index. Using the DROP_EXISTING clause makes it more efficient ...

If you have NC indexes on a table without a CL index, each row in each
NC index has a pointer to the corresponding record in the main table.
Every time a new record is inserted into the main table, or an existing
record is modified in such a way that its RecordID changes, the NC
indexes also have to be updated.

If you have NC indexes on a table with a CL index, all the NC indexes
contain the CL key as well as their own key columns. This is because
the clustered key points to individual pages in the main table, rather
than individual records, and so the NC indexes do not have to be
updated unless a record actually has its PK value updated which greatly
reduces the NC index maintenance overhead.

If you drop the CL index, there is now no longer a CL key for the NC
indexes to use, so they also have to be rebuilt in order to replace
the CL keys with RecordID pointers. When you rebuild the CL index,
the reverse happens again. So , rebuilding a CL index in the simplest
manner causes all NC indexes to be rebuilt twice.

If you use the DROP_EXISTING clause, the initial drop of the NC
indexes is not done, because the re-creation of the CL index is assumed
to be imminent. Furthermore, assuming the CL index name and key
column list stays the same, the data is NOT re-sorted, which also
saves a good deal of time on large tables.sql

Sunday, March 11, 2012

Drop indexes for data import

We need to import lots of data into some tables. To speed
up the import, we deside to drop the indexes related to
the tables that will receive the data before the import
and then recreate the index after the import. What's the
best practice for the senarios below? When to drop/keep
indexes? What kind of indexes(clustered/non-
clustered/unique)to drop? Many thanks.
1. The import scripts do select first and then insert.
2. The import scripts do insert first and then delete.
3. The import scripts do select first and then update.
It depends on what kind of indexes you have on the tables; sometimes,
indexes can help with data imports (e.g. seqential clustered indexes tend to
speed up data import). For a better answer, post DDL (CREATE TABLE
statements) for your tables. Include all indexes and constraints. Also
describe in more detail what the import will be doing. There are no best
practices; it all depends on the situation.
"Bill" <fei0405@.yahoo.com> wrote in message
news:276601c49cf6$c45725b0$a401280a@.phx.gbl...
> We need to import lots of data into some tables. To speed
> up the import, we deside to drop the indexes related to
> the tables that will receive the data before the import
> and then recreate the index after the import. What's the
> best practice for the senarios below? When to drop/keep
> indexes? What kind of indexes(clustered/non-
> clustered/unique)to drop? Many thanks.
> 1. The import scripts do select first and then insert.
> 2. The import scripts do insert first and then delete.
> 3. The import scripts do select first and then update.
>
|||Thank you very much for the reply.
eg.There is a table we will insert about 150,000 records.
Here is the scripts I got from gernerate scripts utility:
CREATE TABLE [dbo].[PS_RF_ATTR_INSP] (
[SETID] [char] (5) COLLATE Latin1_General_BIN NOT
NULL ,
[INST_PROD_ID] [char] (20) COLLATE
Latin1_General_BIN NOT NULL ,
[MARKET] [char] (3) COLLATE Latin1_General_BIN NOT
NULL ,
[ATTRIBUTE_ID] [char] (15) COLLATE
Latin1_General_BIN NOT NULL ,
[ATTR_ITEM_ID] [char] (15) COLLATE
Latin1_General_BIN NOT NULL ,
[ATTRIBUTE_VALUE] [char] (254) COLLATE
Latin1_General_BIN NOT NULL ,
[ATTR_DATE] [PSDATE] NULL ,
[ATTR_NUMBER] [decimal](28, 6) NOT NULL ,
[ROW_ADDED_DTTM] [PSDATETIME] NULL ,
[ROW_ADDED_OPRID] [char] (30) COLLATE
Latin1_General_BIN NOT NULL ,
[ROW_LASTMANT_DTTM] [PSDATETIME] NULL ,
[ROW_LASTMANT_OPRID] [char] (30) COLLATE
Latin1_General_BIN NOT NULL ,
[SYNCID] [int] NOT NULL ,
[SYNCDTTM] [PSDATETIME] NULL
) ON [PRIMARY]
GO
CREATE UNIQUE CLUSTERED INDEX [PS_RF_ATTR_INSP] ON
[dbo].[PS_RF_ATTR_INSP]([SETID], [INST_PROD_ID], [MARKET],
[ATTRIBUTE_ID]) WITH FILLFACTOR = 90 ON [PRIMARY]
GO
But when I issue command "sp_helpindex PS_RF_ATTR_INSP
go" I got more nonclustered index names as below:
index_name index_description
index_keys
PS_RF_ATTR_INSP clustered, unique located on PRIMARY
SETID, INST_PROD_ID, MARKET,ATTRIBUTE_ID
index_name index_description
index_keys
PS0RF_INST_PROD nonclustered located on PRIMARY
BO_ID_CUST, SETID, INST_PROD_ID
PS1RF_INST_PROD nonclustered located on PRIMARY
BO_ID_CONTACT, SETID, INST_PROD_ID
.... ...
Please advise. Many thanks.

>--Original Message--
>It depends on what kind of indexes you have on the
tables; sometimes,
>indexes can help with data imports (e.g. seqential
clustered indexes tend to
>speed up data import). For a better answer, post DDL
(CREATE TABLE
>statements) for your tables. Include all indexes and
constraints. Also
>describe in more detail what the import will be doing.
There are no best[vbcol=seagreen]
>practices; it all depends on the situation.
>
>"Bill" <fei0405@.yahoo.com> wrote in message
>news:276601c49cf6$c45725b0$a401280a@.phx.gbl...
speed
>
>.
>
|||Bill,
I am a bit confused about those nonclustered indexes; they contain columns
that don't appear to be in the table (BO_ID_CUST, etc).
Anyway, with no knowledge of your data it is still quite difficult to answer
this question; 150,000 rows is not a very large insert and if you already
have millions of rows in the table dropping and re-creating the indexes may
take more time than the insert itself, even if there are a lot of page
splits taking place. I think you really need to run a test batch with each
method to determine what's right for you.
"Bill" <fei0405@.yahoo.com> wrote in message
news:3a9301c49f17$d664c910$a401280a@.phx.gbl...
> Thank you very much for the reply.
> eg.There is a table we will insert about 150,000 records.
> Here is the scripts I got from gernerate scripts utility:
> CREATE TABLE [dbo].[PS_RF_ATTR_INSP] (
> [SETID] [char] (5) COLLATE Latin1_General_BIN NOT
> NULL ,
> [INST_PROD_ID] [char] (20) COLLATE
> Latin1_General_BIN NOT NULL ,
> [MARKET] [char] (3) COLLATE Latin1_General_BIN NOT
> NULL ,
> [ATTRIBUTE_ID] [char] (15) COLLATE
> Latin1_General_BIN NOT NULL ,
> [ATTR_ITEM_ID] [char] (15) COLLATE
> Latin1_General_BIN NOT NULL ,
> [ATTRIBUTE_VALUE] [char] (254) COLLATE
> Latin1_General_BIN NOT NULL ,
> [ATTR_DATE] [PSDATE] NULL ,
> [ATTR_NUMBER] [decimal](28, 6) NOT NULL ,
> [ROW_ADDED_DTTM] [PSDATETIME] NULL ,
> [ROW_ADDED_OPRID] [char] (30) COLLATE
> Latin1_General_BIN NOT NULL ,
> [ROW_LASTMANT_DTTM] [PSDATETIME] NULL ,
> [ROW_LASTMANT_OPRID] [char] (30) COLLATE
> Latin1_General_BIN NOT NULL ,
> [SYNCID] [int] NOT NULL ,
> [SYNCDTTM] [PSDATETIME] NULL
> ) ON [PRIMARY]
> GO
> CREATE UNIQUE CLUSTERED INDEX [PS_RF_ATTR_INSP] ON
> [dbo].[PS_RF_ATTR_INSP]([SETID], [INST_PROD_ID], [MARKET],
> [ATTRIBUTE_ID]) WITH FILLFACTOR = 90 ON [PRIMARY]
> GO
>
> But when I issue command "sp_helpindex PS_RF_ATTR_INSP
> go" I got more nonclustered index names as below:
> index_name index_description
> index_keys
> PS_RF_ATTR_INSP clustered, unique located on PRIMARY
> SETID, INST_PROD_ID, MARKET,ATTRIBUTE_ID
> index_name index_description
> index_keys
> PS0RF_INST_PROD nonclustered located on PRIMARY
> BO_ID_CUST, SETID, INST_PROD_ID
> PS1RF_INST_PROD nonclustered located on PRIMARY
> BO_ID_CONTACT, SETID, INST_PROD_ID
> ... ...
>
> Please advise. Many thanks.

Drop indexes for data import

We need to import lots of data into some tables. To speed
up the import, we deside to drop the indexes related to
the tables that will receive the data before the import
and then recreate the index after the import. What's the
best practice for the senarios below? When to drop/keep
indexes? What kind of indexes(clustered/non-
clustered/unique)to drop? Many thanks.
1. The import scripts do select first and then insert.
2. The import scripts do insert first and then delete.
3. The import scripts do select first and then update.It depends on what kind of indexes you have on the tables; sometimes,
indexes can help with data imports (e.g. seqential clustered indexes tend to
speed up data import). For a better answer, post DDL (CREATE TABLE
statements) for your tables. Include all indexes and constraints. Also
describe in more detail what the import will be doing. There are no best
practices; it all depends on the situation.
"Bill" <fei0405@.yahoo.com> wrote in message
news:276601c49cf6$c45725b0$a401280a@.phx.gbl...
> We need to import lots of data into some tables. To speed
> up the import, we deside to drop the indexes related to
> the tables that will receive the data before the import
> and then recreate the index after the import. What's the
> best practice for the senarios below? When to drop/keep
> indexes? What kind of indexes(clustered/non-
> clustered/unique)to drop? Many thanks.
> 1. The import scripts do select first and then insert.
> 2. The import scripts do insert first and then delete.
> 3. The import scripts do select first and then update.
>|||Thank you very much for the reply.
eg.There is a table we will insert about 150,000 records.
Here is the scripts I got from gernerate scripts utility:
CREATE TABLE [dbo].[PS_RF_ATTR_INSP] (
[SETID] [char] (5) COLLATE Latin1_General_BIN NOT
NULL ,
[INST_PROD_ID] [char] (20) COLLATE
Latin1_General_BIN NOT NULL ,
[MARKET] [char] (3) COLLATE Latin1_General_BIN NOT
NULL ,
[ATTRIBUTE_ID] [char] (15) COLLATE
Latin1_General_BIN NOT NULL ,
[ATTR_ITEM_ID] [char] (15) COLLATE
Latin1_General_BIN NOT NULL ,
[ATTRIBUTE_VALUE] [char] (254) COLLATE
Latin1_General_BIN NOT NULL ,
[ATTR_DATE] [PSDATE] NULL ,
[ATTR_NUMBER] [decimal](28, 6) NOT NULL ,
[ROW_ADDED_DTTM] [PSDATETIME] NULL ,
[ROW_ADDED_OPRID] [char] (30) COLLATE
Latin1_General_BIN NOT NULL ,
[ROW_LASTMANT_DTTM] [PSDATETIME] NULL ,
[ROW_LASTMANT_OPRID] [char] (30) COLLATE
Latin1_General_BIN NOT NULL ,
[SYNCID] [int] NOT NULL ,
[SYNCDTTM] [PSDATETIME] NULL
) ON [PRIMARY]
GO
CREATE UNIQUE CLUSTERED INDEX [PS_RF_ATTR_INSP] ON
[dbo].[PS_RF_ATTR_INSP]([SETID], [INST_PROD_ID], [MARKET],
[ATTRIBUTE_ID]) WITH FILLFACTOR = 90 ON [PRIMARY]
GO
But when I issue command "sp_helpindex PS_RF_ATTR_INSP
go" I got more nonclustered index names as below:
index_name index_description
index_keys
PS_RF_ATTR_INSP clustered, unique located on PRIMARY
SETID, INST_PROD_ID, MARKET,ATTRIBUTE_ID
index_name index_description
index_keys
PS0RF_INST_PROD nonclustered located on PRIMARY
BO_ID_CUST, SETID, INST_PROD_ID
PS1RF_INST_PROD nonclustered located on PRIMARY
BO_ID_CONTACT, SETID, INST_PROD_ID
... ...
Please advise. Many thanks.
>--Original Message--
>It depends on what kind of indexes you have on the
tables; sometimes,
>indexes can help with data imports (e.g. seqential
clustered indexes tend to
>speed up data import). For a better answer, post DDL
(CREATE TABLE
>statements) for your tables. Include all indexes and
constraints. Also
>describe in more detail what the import will be doing.
There are no best
>practices; it all depends on the situation.
>
>"Bill" <fei0405@.yahoo.com> wrote in message
>news:276601c49cf6$c45725b0$a401280a@.phx.gbl...
>> We need to import lots of data into some tables. To
speed
>> up the import, we deside to drop the indexes related to
>> the tables that will receive the data before the import
>> and then recreate the index after the import. What's the
>> best practice for the senarios below? When to drop/keep
>> indexes? What kind of indexes(clustered/non-
>> clustered/unique)to drop? Many thanks.
>> 1. The import scripts do select first and then insert.
>> 2. The import scripts do insert first and then delete.
>> 3. The import scripts do select first and then update.
>>
>
>.
>|||Bill,
I am a bit confused about those nonclustered indexes; they contain columns
that don't appear to be in the table (BO_ID_CUST, etc).
Anyway, with no knowledge of your data it is still quite difficult to answer
this question; 150,000 rows is not a very large insert and if you already
have millions of rows in the table dropping and re-creating the indexes may
take more time than the insert itself, even if there are a lot of page
splits taking place. I think you really need to run a test batch with each
method to determine what's right for you.
"Bill" <fei0405@.yahoo.com> wrote in message
news:3a9301c49f17$d664c910$a401280a@.phx.gbl...
> Thank you very much for the reply.
> eg.There is a table we will insert about 150,000 records.
> Here is the scripts I got from gernerate scripts utility:
> CREATE TABLE [dbo].[PS_RF_ATTR_INSP] (
> [SETID] [char] (5) COLLATE Latin1_General_BIN NOT
> NULL ,
> [INST_PROD_ID] [char] (20) COLLATE
> Latin1_General_BIN NOT NULL ,
> [MARKET] [char] (3) COLLATE Latin1_General_BIN NOT
> NULL ,
> [ATTRIBUTE_ID] [char] (15) COLLATE
> Latin1_General_BIN NOT NULL ,
> [ATTR_ITEM_ID] [char] (15) COLLATE
> Latin1_General_BIN NOT NULL ,
> [ATTRIBUTE_VALUE] [char] (254) COLLATE
> Latin1_General_BIN NOT NULL ,
> [ATTR_DATE] [PSDATE] NULL ,
> [ATTR_NUMBER] [decimal](28, 6) NOT NULL ,
> [ROW_ADDED_DTTM] [PSDATETIME] NULL ,
> [ROW_ADDED_OPRID] [char] (30) COLLATE
> Latin1_General_BIN NOT NULL ,
> [ROW_LASTMANT_DTTM] [PSDATETIME] NULL ,
> [ROW_LASTMANT_OPRID] [char] (30) COLLATE
> Latin1_General_BIN NOT NULL ,
> [SYNCID] [int] NOT NULL ,
> [SYNCDTTM] [PSDATETIME] NULL
> ) ON [PRIMARY]
> GO
> CREATE UNIQUE CLUSTERED INDEX [PS_RF_ATTR_INSP] ON
> [dbo].[PS_RF_ATTR_INSP]([SETID], [INST_PROD_ID], [MARKET],
> [ATTRIBUTE_ID]) WITH FILLFACTOR = 90 ON [PRIMARY]
> GO
>
> But when I issue command "sp_helpindex PS_RF_ATTR_INSP
> go" I got more nonclustered index names as below:
> index_name index_description
> index_keys
> PS_RF_ATTR_INSP clustered, unique located on PRIMARY
> SETID, INST_PROD_ID, MARKET,ATTRIBUTE_ID
> index_name index_description
> index_keys
> PS0RF_INST_PROD nonclustered located on PRIMARY
> BO_ID_CUST, SETID, INST_PROD_ID
> PS1RF_INST_PROD nonclustered located on PRIMARY
> BO_ID_CONTACT, SETID, INST_PROD_ID
> ... ...
>
> Please advise. Many thanks.

Drop indexes

I have a database with many PK and FK constraints. Is there any script I can use to drop all indexes and rebuild them taking care of PK and dependencies? I am unable to drop them by tablename order. This is on MSSQLServer-2000 SP3. Any help is appreciated.why drop and recreate when you can defrag or reindex? have you looked at DBCC SHOWCONTIG to make you sure need to do this.

btw, you only have to do the clustered ones. the nonclustered get rebuilt when you do this.

here is some code...

SELECT 'DBCC DBREINDEX(' + CAST(o.[name] as varchar(200)) + ',' + CAST(i.[name] as varchar) + ')
GO'
FROM sysindexes i
JOIN sysobjects o
ON i.id = o.id
WHERE o.xtype = 'U'
AND i.indid = 1|||is I have primary clustered indexes on 812 tables and do not know a lot of dependencies if I go by tablename order to drop and recreate indexes. Does DBCC REINDEX drops and recreates PK indexes too? We have run DBCC showcontig and saw fragmentation quite a bit.|||DBCC DBREINDEX does not drop and recreate to knowledge but I would confirm in BOL. It does however lock up tables.

DBCC INDEXDEFRAG is slower but does not lock up the tables so much and the users can work more easily while this goes on.|||DBCC DBREINDEX does not drop and recreate to knowledge but I would confirm in BOL.
It doesn't - in fact, when last I read about all this stuff it was presented as DBREINDEX's USP :D

Drop Index on System Tables

SQL SERVER 2000

System let's you alter the system tables and add indexes. However, it won't
let you drop the index afterward.

Anybody know how to drop an index on a system table?

Thanks,

Kevin"Kevin Haugen" <khaugen@.pacbell.net> wrote in message
news:3sgTc.6297$Ux.622@.newssvr29.news.prodigy.com. ..
> SQL SERVER 2000
> System let's you alter the system tables and add indexes. However, it
> won't
> let you drop the index afterward.
> Anybody know how to drop an index on a system table?
> Thanks,
> Kevin

You don't say which table or what error you get, but in any case Microsoft
does not support any modifications to system tables, so the best option is
probably to restore from a backup. If you can post more detailed
information, then someone may have a better suggestion, but in general you
shouldn't touch system tables at all.

Simon|||"Simon Hayes" <sql@.hayes.ch> wrote in message
news:411dc8f8$1_2@.news.bluewin.ch...
> "Kevin Haugen" <khaugen@.pacbell.net> wrote in message
> news:3sgTc.6297$Ux.622@.newssvr29.news.prodigy.com. ..
> > SQL SERVER 2000
> > System let's you alter the system tables and add indexes. However, it
> > won't
> > let you drop the index afterward.
> > Anybody know how to drop an index on a system table?
> > Thanks,
> > Kevin
> You don't say which table or what error you get, but in any case Microsoft
> does not support any modifications to system tables, so the best option is
> probably to restore from a backup. If you can post more detailed
> information, then someone may have a better suggestion, but in general you
> shouldn't touch system tables at all.

And further more, with some of the tables, it may appear you've succeeded,
but in reality nothing has changed, or upon a restart things were the way
they started. sysjobs I believe is one such derived table.

> Simon|||"Simon Hayes" <sql@.hayes.ch> wrote in message
news:411dc8f8$1_2@.news.bluewin.ch...
> "Kevin Haugen" <khaugen@.pacbell.net> wrote in message
> news:3sgTc.6297$Ux.622@.newssvr29.news.prodigy.com. ..
> > SQL SERVER 2000
> > System let's you alter the system tables and add indexes. However, it
> > won't
> > let you drop the index afterward.
> > Anybody know how to drop an index on a system table?
> > Thanks,
> > Kevin
> You don't say which table or what error you get, but in any case Microsoft
> does not support any modifications to system tables, so the best option is
> probably to restore from a backup. If you can post more detailed
> information, then someone may have a better suggestion, but in general you
> shouldn't touch system tables at all.
> Simon
>
I have an ERP application which constantly scans the sysobjects table for
xtype ''U'. I was attempting to speed up this particular SELECT statement
by adding an index to the xtype column (which seemed like a good idea at the
time). I ran a DBCC CHECKDB and it threw msg's 8951 and 8955. I actually
came across the problem when I tried to apply the script referenced in KB
293177 when it failed to complete.

I'm currently working on restoring the database into a new schema to resolve
the issue.

Kevin|||Kevin Haugen (khaugen@.pacbell.net) writes:
> I have an ERP application which constantly scans the sysobjects table
> for xtype ''U'. I was attempting to speed up this particular SELECT
> statement by adding an index to the xtype column (which seemed like a
> good idea at the time). I ran a DBCC CHECKDB and it threw msg's 8951
> and 8955.

It is dubious that even if sysobjects would be a normal table that this
would be a good thing to do. The column may not be selective enough.

In any case, in the next version of SQL Server, SQL 2005 which currently
is in beta, there is no longer any sysobjects table. There is a sysobjects
view which is built on top of the new catalog views, which in their turn
are built on tables that are not exposed at all.

> I actually came across the problem when I tried to apply the
> script referenced in KB 293177 when it failed to complete.

I have no tried that script, but it may be that you should throw in an
INSENSITIVE before CURSOR.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Friday, March 9, 2012

drop constraint hanging.

I'm trying to fix a corrupt database, complains about indexes. I've been
waiting for drop constraint to come back, its been running for 1.5 hrs and
the drive activity is at 100%. Is this normal?
Everything is possible once you have a corrupt database. Check your system
event log for errors as well. It is possible for disk I/O to slow down
significantly if there are hardware problems.
Going forward, your course of action should be to identify what caused
corruption and restore your database from the last good backup.
Adrian
"michael" <michael@.discussions.microsoft.com> wrote in message
news:D044278A-7F75-43E9-A1F4-C5D0CE807397@.microsoft.com...
> I'm trying to fix a corrupt database, complains about indexes. I've been
> waiting for drop constraint to come back, its been running for 1.5 hrs and
> the drive activity is at 100%. Is this normal?

drop constraint hanging.

I'm trying to fix a corrupt database, complains about indexes. I've been
waiting for drop constraint to come back, its been running for 1.5 hrs and
the drive activity is at 100%. Is this normal?Everything is possible once you have a corrupt database. Check your system
event log for errors as well. It is possible for disk I/O to slow down
significantly if there are hardware problems.
Going forward, your course of action should be to identify what caused
corruption and restore your database from the last good backup.
Adrian
"michael" <michael@.discussions.microsoft.com> wrote in message
news:D044278A-7F75-43E9-A1F4-C5D0CE807397@.microsoft.com...
> I'm trying to fix a corrupt database, complains about indexes. I've been
> waiting for drop constraint to come back, its been running for 1.5 hrs and
> the drive activity is at 100%. Is this normal?

drop constraint hanging.

I'm trying to fix a corrupt database, complains about indexes. I've been
waiting for drop constraint to come back, its been running for 1.5 hrs and
the drive activity is at 100%. Is this normal?Everything is possible once you have a corrupt database. Check your system
event log for errors as well. It is possible for disk I/O to slow down
significantly if there are hardware problems.
Going forward, your course of action should be to identify what caused
corruption and restore your database from the last good backup.
Adrian
"michael" <michael@.discussions.microsoft.com> wrote in message
news:D044278A-7F75-43E9-A1F4-C5D0CE807397@.microsoft.com...
> I'm trying to fix a corrupt database, complains about indexes. I've been
> waiting for drop constraint to come back, its been running for 1.5 hrs and
> the drive activity is at 100%. Is this normal?

Drop automatically-created indexes

Hi
We have a SQL Server 2000 database. On three of the tables (used by an
ERP-system) there are a huge number of automatically-created indexes (we are
hitting the maximum limit). These indexes slow down inserts and updates, and
prevent us from create other (more meaningful) indexes. We have tried to drop
these indexes, but we can’t.
Is there a way to drop/delete automatically-created indexes, or to turn this
functionality off?
Or to you have other suggestions?
Here is some more information about automatically-created indexes:
http://www.microsoft.com/sql/techinf...utoindexes.asp
--JeyLey
Jey
There are called Statistics. SQL Server creates statistics on columns in
order to
retrieve the data in more efficient way. This article makes it clear how
does it work.You can run sp_updatestatistics system stored procedure to
update automatically reated statistics.For more details please refer to BOL.
eyLey" <JeyLey@.nospam.nospam> wrote in message
news:D288B8DC-2E00-4E68-ADAC-7DBD3DF16837@.microsoft.com...
> Hi
> We have a SQL Server 2000 database. On three of the tables (used by an
> ERP-system) there are a huge number of automatically-created indexes (we
are
> hitting the maximum limit). These indexes slow down inserts and updates,
and
> prevent us from create other (more meaningful) indexes. We have tried to
drop
> these indexes, but we cant.
> Is there a way to drop/delete automatically-created indexes, or to turn
this
> functionality off?
> Or to you have other suggestions?
> Here is some more information about automatically-created indexes:
> http://www.microsoft.com/sql/techinf...utoindexes.asp
> --JeyLey
|||In addition to Uri's post:
You can drop these auto-created statistics using the DROP STATISTICS command. But note that
auto-created statistics can benefit performance.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"JeyLey" <JeyLey@.nospam.nospam> wrote in message
news:D288B8DC-2E00-4E68-ADAC-7DBD3DF16837@.microsoft.com...
> Hi
> We have a SQL Server 2000 database. On three of the tables (used by an
> ERP-system) there are a huge number of automatically-created indexes (we are
> hitting the maximum limit). These indexes slow down inserts and updates, and
> prevent us from create other (more meaningful) indexes. We have tried to drop
> these indexes, but we can't.
> Is there a way to drop/delete automatically-created indexes, or to turn this
> functionality off?
> Or to you have other suggestions?
> Here is some more information about automatically-created indexes:
> http://www.microsoft.com/sql/techinf...utoindexes.asp
> --JeyLey

Drop automatically-created indexes

Hi
We have a SQL Server 2000 database. On three of the tables (used by an
ERP-system) there are a huge number of automatically-created indexes (we are
hitting the maximum limit). These indexes slow down inserts and updates, and
prevent us from create other (more meaningful) indexes. We have tried to dro
p
these indexes, but we can’t.
Is there a way to drop/delete automatically-created indexes, or to turn this
functionality off?
Or to you have other suggestions?
Here is some more information about automatically-created indexes:
http://www.microsoft.com/sql/techin...autoindexes.asp
--JeyLeyJey
There are called Statistics. SQL Server creates statistics on columns in
order to
retrieve the data in more efficient way. This article makes it clear how
does it work.You can run sp_updatestatistics system stored procedure to
update automatically reated statistics.For more details please refer to BOL.
eyLey" <JeyLey@.nospam.nospam> wrote in message
news:D288B8DC-2E00-4E68-ADAC-7DBD3DF16837@.microsoft.com...
> Hi
> We have a SQL Server 2000 database. On three of the tables (used by an
> ERP-system) there are a huge number of automatically-created indexes (we
are
> hitting the maximum limit). These indexes slow down inserts and updates,
and
> prevent us from create other (more meaningful) indexes. We have tried to
drop
> these indexes, but we cant.
> Is there a way to drop/delete automatically-created indexes, or to turn
this
> functionality off?
> Or to you have other suggestions?
> Here is some more information about automatically-created indexes:
> http://www.microsoft.com/sql/techin...autoindexes.asp
> --JeyLey|||In addition to Uri's post:
You can drop these auto-created statistics using the DROP STATISTICS command
. But note that
auto-created statistics can benefit performance.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"JeyLey" <JeyLey@.nospam.nospam> wrote in message
news:D288B8DC-2E00-4E68-ADAC-7DBD3DF16837@.microsoft.com...
> Hi
> We have a SQL Server 2000 database. On three of the tables (used by an
> ERP-system) there are a huge number of automatically-created indexes (we a
re
> hitting the maximum limit). These indexes slow down inserts and updates, a
nd
> prevent us from create other (more meaningful) indexes. We have tried to d
rop
> these indexes, but we can't.
> Is there a way to drop/delete automatically-created indexes, or to turn th
is
> functionality off?
> Or to you have other suggestions?
> Here is some more information about automatically-created indexes:
> http://www.microsoft.com/sql/techin...autoindexes.asp
> --JeyLey