Hello,
I encounter serious performance degradation and what's more important -
strange SQL server behaviour after removing and adding again indexes on few
(6-8) tables.
Let me explain - I have original database, which performs well. Database
size is about 400-600 MB on disk. Then I remove few indexes from few tables
and add it again. Now database performs drastically slower. More than that,
the query schema has changed after removal/adding indexes, but database
schema is the same! So it looks strange.
Please help me and explain why query schema has changed, while database
schema is unchanged? Why database performs slower?
I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
scenarios, also with Windows Server 2003.
Adam.
What do you mean the query schema has changed? What is occurring slower?
(Selects? Updates? etc..)
"aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com >
wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com...
> Hello,
> I encounter serious performance degradation and what's more important -
> strange SQL server behaviour after removing and adding again indexes on
> few
> (6-8) tables.
> Let me explain - I have original database, which performs well. Database
> size is about 400-600 MB on disk. Then I remove few indexes from few
> tables
> and add it again. Now database performs drastically slower. More than
> that,
> the query schema has changed after removal/adding indexes, but database
> schema is the same! So it looks strange.
> Please help me and explain why query schema has changed, while database
> schema is unchanged? Why database performs slower?
> I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
> scenarios, also with Windows Server 2003.
> Adam.
>
|||Selects are much slower. Also sql execution plan shown by query analyser is
different than on a original database.
So I have 2 databases, they have identical schema but SQL execution plan are
different and performance degraded on 2nd db.
Adam
"Jeff Fiegel" wrote:
> What do you mean the query schema has changed? What is occurring slower?
> (Selects? Updates? etc..)
>
> "aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com >
> wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com...
>
>
|||Adam,
Are you *sure* the indexes are the same as before? After rebuilding your
indexes run sp_updatestats.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
aheczko@.nospam.nospam wrote:[vbcol=seagreen]
> Selects are much slower. Also sql execution plan shown by query analyser is
> different than on a original database.
> So I have 2 databases, they have identical schema but SQL execution plan are
> different and performance degraded on 2nd db.
> Adam
> "Jeff Fiegel" wrote:
>
Showing posts with label degradation. Show all posts
Showing posts with label degradation. Show all posts
Wednesday, March 21, 2012
Performance problems (strange)
Hello,
I encounter serious performance degradation and what's more important -
strange SQL server behaviour after removing and adding again indexes on few
(6-8) tables.
Let me explain - I have original database, which performs well. Database
size is about 400-600 MB on disk. Then I remove few indexes from few tables
and add it again. Now database performs drastically slower. More than that,
the query schema has changed after removal/adding indexes, but database
schema is the same! So it looks strange.
Please help me and explain why query schema has changed, while database
schema is unchanged? Why database performs slower?
I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
scenarios, also with Windows Server 2003.
Adam.What do you mean the query schema has changed? What is occurring slower?
(Selects? Updates? etc..)
"aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com>
wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com...
> Hello,
> I encounter serious performance degradation and what's more important -
> strange SQL server behaviour after removing and adding again indexes on
> few
> (6-8) tables.
> Let me explain - I have original database, which performs well. Database
> size is about 400-600 MB on disk. Then I remove few indexes from few
> tables
> and add it again. Now database performs drastically slower. More than
> that,
> the query schema has changed after removal/adding indexes, but database
> schema is the same! So it looks strange.
> Please help me and explain why query schema has changed, while database
> schema is unchanged? Why database performs slower?
> I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
> scenarios, also with Windows Server 2003.
> Adam.
>|||Selects are much slower. Also sql execution plan shown by query analyser is
different than on a original database.
So I have 2 databases, they have identical schema but SQL execution plan are
different and performance degraded on 2nd db.
Adam
"Jeff Fiegel" wrote:
> What do you mean the query schema has changed? What is occurring slower?
> (Selects? Updates? etc..)
>
> "aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com>
> wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com...
> > Hello,
> > I encounter serious performance degradation and what's more important -
> > strange SQL server behaviour after removing and adding again indexes on
> > few
> > (6-8) tables.
> > Let me explain - I have original database, which performs well. Database
> > size is about 400-600 MB on disk. Then I remove few indexes from few
> > tables
> > and add it again. Now database performs drastically slower. More than
> > that,
> > the query schema has changed after removal/adding indexes, but database
> > schema is the same! So it looks strange.
> > Please help me and explain why query schema has changed, while database
> > schema is unchanged? Why database performs slower?
> > I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
> > scenarios, also with Windows Server 2003.
> > Adam.
> >
>
>|||Adam,
Are you *sure* the indexes are the same as before? After rebuilding your
indexes run sp_updatestats.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
aheczko@.nospam.nospam wrote:
> Selects are much slower. Also sql execution plan shown by query analyser is
> different than on a original database.
> So I have 2 databases, they have identical schema but SQL execution plan are
> different and performance degraded on 2nd db.
> Adam
> "Jeff Fiegel" wrote:
>
>>What do you mean the query schema has changed? What is occurring slower?
>>(Selects? Updates? etc..)
>>
>>"aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com>
>>wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com...
>>Hello,
>>I encounter serious performance degradation and what's more important -
>>strange SQL server behaviour after removing and adding again indexes on
>>few
>>(6-8) tables.
>>Let me explain - I have original database, which performs well. Database
>>size is about 400-600 MB on disk. Then I remove few indexes from few
>>tables
>>and add it again. Now database performs drastically slower. More than
>>that,
>>the query schema has changed after removal/adding indexes, but database
>>schema is the same! So it looks strange.
>>Please help me and explain why query schema has changed, while database
>>schema is unchanged? Why database performs slower?
>>I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
>>scenarios, also with Windows Server 2003.
>>Adam.
>>
>>sql
I encounter serious performance degradation and what's more important -
strange SQL server behaviour after removing and adding again indexes on few
(6-8) tables.
Let me explain - I have original database, which performs well. Database
size is about 400-600 MB on disk. Then I remove few indexes from few tables
and add it again. Now database performs drastically slower. More than that,
the query schema has changed after removal/adding indexes, but database
schema is the same! So it looks strange.
Please help me and explain why query schema has changed, while database
schema is unchanged? Why database performs slower?
I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
scenarios, also with Windows Server 2003.
Adam.What do you mean the query schema has changed? What is occurring slower?
(Selects? Updates? etc..)
"aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com>
wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com...
> Hello,
> I encounter serious performance degradation and what's more important -
> strange SQL server behaviour after removing and adding again indexes on
> few
> (6-8) tables.
> Let me explain - I have original database, which performs well. Database
> size is about 400-600 MB on disk. Then I remove few indexes from few
> tables
> and add it again. Now database performs drastically slower. More than
> that,
> the query schema has changed after removal/adding indexes, but database
> schema is the same! So it looks strange.
> Please help me and explain why query schema has changed, while database
> schema is unchanged? Why database performs slower?
> I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
> scenarios, also with Windows Server 2003.
> Adam.
>|||Selects are much slower. Also sql execution plan shown by query analyser is
different than on a original database.
So I have 2 databases, they have identical schema but SQL execution plan are
different and performance degraded on 2nd db.
Adam
"Jeff Fiegel" wrote:
> What do you mean the query schema has changed? What is occurring slower?
> (Selects? Updates? etc..)
>
> "aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com>
> wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com...
> > Hello,
> > I encounter serious performance degradation and what's more important -
> > strange SQL server behaviour after removing and adding again indexes on
> > few
> > (6-8) tables.
> > Let me explain - I have original database, which performs well. Database
> > size is about 400-600 MB on disk. Then I remove few indexes from few
> > tables
> > and add it again. Now database performs drastically slower. More than
> > that,
> > the query schema has changed after removal/adding indexes, but database
> > schema is the same! So it looks strange.
> > Please help me and explain why query schema has changed, while database
> > schema is unchanged? Why database performs slower?
> > I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
> > scenarios, also with Windows Server 2003.
> > Adam.
> >
>
>|||Adam,
Are you *sure* the indexes are the same as before? After rebuilding your
indexes run sp_updatestats.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
aheczko@.nospam.nospam wrote:
> Selects are much slower. Also sql execution plan shown by query analyser is
> different than on a original database.
> So I have 2 databases, they have identical schema but SQL execution plan are
> different and performance degraded on 2nd db.
> Adam
> "Jeff Fiegel" wrote:
>
>>What do you mean the query schema has changed? What is occurring slower?
>>(Selects? Updates? etc..)
>>
>>"aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com>
>>wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com...
>>Hello,
>>I encounter serious performance degradation and what's more important -
>>strange SQL server behaviour after removing and adding again indexes on
>>few
>>(6-8) tables.
>>Let me explain - I have original database, which performs well. Database
>>size is about 400-600 MB on disk. Then I remove few indexes from few
>>tables
>>and add it again. Now database performs drastically slower. More than
>>that,
>>the query schema has changed after removal/adding indexes, but database
>>schema is the same! So it looks strange.
>>Please help me and explain why query schema has changed, while database
>>schema is unchanged? Why database performs slower?
>>I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
>>scenarios, also with Windows Server 2003.
>>Adam.
>>
>>sql
Performance problems (strange)
Hello,
I encounter serious performance degradation and what's more important -
strange SQL server behaviour after removing and adding again indexes on few
(6-8) tables.
Let me explain - I have original database, which performs well. Database
size is about 400-600 MB on disk. Then I remove few indexes from few tables
and add it again. Now database performs drastically slower. More than that,
the query schema has changed after removal/adding indexes, but database
schema is the same! So it looks strange.
Please help me and explain why query schema has changed, while database
schema is unchanged? Why database performs slower?
I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
scenarios, also with Windows Server 2003.
Adam.What do you mean the query schema has changed? What is occurring slower?
(Selects? Updates? etc..)
"aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com>
wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com...
> Hello,
> I encounter serious performance degradation and what's more important -
> strange SQL server behaviour after removing and adding again indexes on
> few
> (6-8) tables.
> Let me explain - I have original database, which performs well. Database
> size is about 400-600 MB on disk. Then I remove few indexes from few
> tables
> and add it again. Now database performs drastically slower. More than
> that,
> the query schema has changed after removal/adding indexes, but database
> schema is the same! So it looks strange.
> Please help me and explain why query schema has changed, while database
> schema is unchanged? Why database performs slower?
> I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
> scenarios, also with Windows Server 2003.
> Adam.
>|||Selects are much slower. Also sql execution plan shown by query analyser is
different than on a original database.
So I have 2 databases, they have identical schema but SQL execution plan are
different and performance degraded on 2nd db.
Adam
"Jeff Fiegel" wrote:
> What do you mean the query schema has changed? What is occurring slower?
> (Selects? Updates? etc..)
>
> "aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com>
> wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com..
.
>
>|||Adam,
Are you *sure* the indexes are the same as before? After rebuilding your
indexes run sp_updatestats.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
aheczko@.nospam.nospam wrote:[vbcol=seagreen]
> Selects are much slower. Also sql execution plan shown by query analyser i
s
> different than on a original database.
> So I have 2 databases, they have identical schema but SQL execution plan a
re
> different and performance degraded on 2nd db.
> Adam
> "Jeff Fiegel" wrote:
>
I encounter serious performance degradation and what's more important -
strange SQL server behaviour after removing and adding again indexes on few
(6-8) tables.
Let me explain - I have original database, which performs well. Database
size is about 400-600 MB on disk. Then I remove few indexes from few tables
and add it again. Now database performs drastically slower. More than that,
the query schema has changed after removal/adding indexes, but database
schema is the same! So it looks strange.
Please help me and explain why query schema has changed, while database
schema is unchanged? Why database performs slower?
I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
scenarios, also with Windows Server 2003.
Adam.What do you mean the query schema has changed? What is occurring slower?
(Selects? Updates? etc..)
"aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com>
wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com...
> Hello,
> I encounter serious performance degradation and what's more important -
> strange SQL server behaviour after removing and adding again indexes on
> few
> (6-8) tables.
> Let me explain - I have original database, which performs well. Database
> size is about 400-600 MB on disk. Then I remove few indexes from few
> tables
> and add it again. Now database performs drastically slower. More than
> that,
> the query schema has changed after removal/adding indexes, but database
> schema is the same! So it looks strange.
> Please help me and explain why query schema has changed, while database
> schema is unchanged? Why database performs slower?
> I use SQL Srv 2000 SP3a, Win 2000Srv, 1 GB RAM. Tested in many hardware
> scenarios, also with Windows Server 2003.
> Adam.
>|||Selects are much slower. Also sql execution plan shown by query analyser is
different than on a original database.
So I have 2 databases, they have identical schema but SQL execution plan are
different and performance degraded on 2nd db.
Adam
"Jeff Fiegel" wrote:
> What do you mean the query schema has changed? What is occurring slower?
> (Selects? Updates? etc..)
>
> "aheczko@.nospam.nospam" <aheczko@.nospam.nospam@.discussions.microsoft.com>
> wrote in message news:D6E52964-B847-4DB7-BACD-CEA5A8BECB97@.microsoft.com..
.
>
>|||Adam,
Are you *sure* the indexes are the same as before? After rebuilding your
indexes run sp_updatestats.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
aheczko@.nospam.nospam wrote:[vbcol=seagreen]
> Selects are much slower. Also sql execution plan shown by query analyser i
s
> different than on a original database.
> So I have 2 databases, they have identical schema but SQL execution plan a
re
> different and performance degraded on 2nd db.
> Adam
> "Jeff Fiegel" wrote:
>
Monday, March 12, 2012
Performance pointer and export...
Hi,
Can anyone give me a clue where to start - I have quite a large database
that suffers from performance degradation over a few weeks. A select
statement with 5 joins that runs in 5 seconds can start to take a couple of
minutes.
The only thing that clears it, is to export all the data and objects to a
new database, then its ok but starts degrading again afer a few days.
Obviously, exporting is a pain so I'd rather find out what it is the export
does, and find a better way of doing it.
Any pointers please ?
JaneDo you update statistics regularly?
"Jane Sharpe" <JS51@.hotmail.com> wrote in message
news:bu8rvn$651$1@.hercules.btinternet.com...
> Hi,
> Can anyone give me a clue where to start - I have quite a large database
> that suffers from performance degradation over a few weeks. A select
> statement with 5 joins that runs in 5 seconds can start to take a couple
of
> minutes.
> The only thing that clears it, is to export all the data and objects to a
> new database, then its ok but starts degrading again afer a few days.
> Obviously, exporting is a pain so I'd rather find out what it is the
export
> does, and find a better way of doing it.
> Any pointers please ?
> Jane
>|||I'm sorry, I dont know what that means (so I guess the answer is no !)
Jane
"Quentin Ran" <ab@.who.com> wrote in message
news:#LK1gaE3DHA.3436@.tk2msftngp13.phx.gbl...
> Do you update statistics regularly?
> "Jane Sharpe" <JS51@.hotmail.com> wrote in message
> news:bu8rvn$651$1@.hercules.btinternet.com...
> > Hi,
> >
> > Can anyone give me a clue where to start - I have quite a large database
> > that suffers from performance degradation over a few weeks. A select
> > statement with 5 joins that runs in 5 seconds can start to take a couple
> of
> > minutes.
> >
> > The only thing that clears it, is to export all the data and objects to
a
> > new database, then its ok but starts degrading again afer a few days.
> >
> > Obviously, exporting is a pain so I'd rather find out what it is the
> export
> > does, and find a better way of doing it.
> >
> > Any pointers please ?
> >
> > Jane
> >
> >
>|||Look for "update statistics" in BOL and see whether doing that helps.
"Jane Sharpe" <JS51@.hotmail.com> wrote in message
news:bu981q$m92$1@.titan.btinternet.com...
> I'm sorry, I dont know what that means (so I guess the answer is no !)
> Jane
> "Quentin Ran" <ab@.who.com> wrote in message
> news:#LK1gaE3DHA.3436@.tk2msftngp13.phx.gbl...
> > Do you update statistics regularly?
> >
> > "Jane Sharpe" <JS51@.hotmail.com> wrote in message
> > news:bu8rvn$651$1@.hercules.btinternet.com...
> > > Hi,
> > >
> > > Can anyone give me a clue where to start - I have quite a large
database
> > > that suffers from performance degradation over a few weeks. A select
> > > statement with 5 joins that runs in 5 seconds can start to take a
couple
> > of
> > > minutes.
> > >
> > > The only thing that clears it, is to export all the data and objects
to
> a
> > > new database, then its ok but starts degrading again afer a few days.
> > >
> > > Obviously, exporting is a pain so I'd rather find out what it is the
> > export
> > > does, and find a better way of doing it.
> > >
> > > Any pointers please ?
> > >
> > > Jane
> > >
> > >
> >
> >
>
Can anyone give me a clue where to start - I have quite a large database
that suffers from performance degradation over a few weeks. A select
statement with 5 joins that runs in 5 seconds can start to take a couple of
minutes.
The only thing that clears it, is to export all the data and objects to a
new database, then its ok but starts degrading again afer a few days.
Obviously, exporting is a pain so I'd rather find out what it is the export
does, and find a better way of doing it.
Any pointers please ?
JaneDo you update statistics regularly?
"Jane Sharpe" <JS51@.hotmail.com> wrote in message
news:bu8rvn$651$1@.hercules.btinternet.com...
> Hi,
> Can anyone give me a clue where to start - I have quite a large database
> that suffers from performance degradation over a few weeks. A select
> statement with 5 joins that runs in 5 seconds can start to take a couple
of
> minutes.
> The only thing that clears it, is to export all the data and objects to a
> new database, then its ok but starts degrading again afer a few days.
> Obviously, exporting is a pain so I'd rather find out what it is the
export
> does, and find a better way of doing it.
> Any pointers please ?
> Jane
>|||I'm sorry, I dont know what that means (so I guess the answer is no !)
Jane
"Quentin Ran" <ab@.who.com> wrote in message
news:#LK1gaE3DHA.3436@.tk2msftngp13.phx.gbl...
> Do you update statistics regularly?
> "Jane Sharpe" <JS51@.hotmail.com> wrote in message
> news:bu8rvn$651$1@.hercules.btinternet.com...
> > Hi,
> >
> > Can anyone give me a clue where to start - I have quite a large database
> > that suffers from performance degradation over a few weeks. A select
> > statement with 5 joins that runs in 5 seconds can start to take a couple
> of
> > minutes.
> >
> > The only thing that clears it, is to export all the data and objects to
a
> > new database, then its ok but starts degrading again afer a few days.
> >
> > Obviously, exporting is a pain so I'd rather find out what it is the
> export
> > does, and find a better way of doing it.
> >
> > Any pointers please ?
> >
> > Jane
> >
> >
>|||Look for "update statistics" in BOL and see whether doing that helps.
"Jane Sharpe" <JS51@.hotmail.com> wrote in message
news:bu981q$m92$1@.titan.btinternet.com...
> I'm sorry, I dont know what that means (so I guess the answer is no !)
> Jane
> "Quentin Ran" <ab@.who.com> wrote in message
> news:#LK1gaE3DHA.3436@.tk2msftngp13.phx.gbl...
> > Do you update statistics regularly?
> >
> > "Jane Sharpe" <JS51@.hotmail.com> wrote in message
> > news:bu8rvn$651$1@.hercules.btinternet.com...
> > > Hi,
> > >
> > > Can anyone give me a clue where to start - I have quite a large
database
> > > that suffers from performance degradation over a few weeks. A select
> > > statement with 5 joins that runs in 5 seconds can start to take a
couple
> > of
> > > minutes.
> > >
> > > The only thing that clears it, is to export all the data and objects
to
> a
> > > new database, then its ok but starts degrading again afer a few days.
> > >
> > > Obviously, exporting is a pain so I'd rather find out what it is the
> > export
> > > does, and find a better way of doing it.
> > >
> > > Any pointers please ?
> > >
> > > Jane
> > >
> > >
> >
> >
>
Performance pointer and export...
Hi,
Can anyone give me a clue where to start - I have quite a large database
that suffers from performance degradation over a few weeks. A select
statement with 5 joins that runs in 5 seconds can start to take a couple of
minutes.
The only thing that clears it, is to export all the data and objects to a
new database, then its ok but starts degrading again afer a few days.
Obviously, exporting is a pain so I'd rather find out what it is the export
does, and find a better way of doing it.
Any pointers please ?
JaneDo you update statistics regularly?
"Jane Sharpe" <JS51@.hotmail.com> wrote in message
news:bu8rvn$651$1@.hercules.btinternet.com...
of
export
Jane
"Quentin Ran" <ab@.who.com> wrote in message
news:#LK1gaE3DHA.3436@.tk2msftngp13.phx.gbl...
"Jane Sharpe" <JS51@.hotmail.com> wrote in message
news:bu981q$m92$1@.titan.btinternet.com...
Can anyone give me a clue where to start - I have quite a large database
that suffers from performance degradation over a few weeks. A select
statement with 5 joins that runs in 5 seconds can start to take a couple of
minutes.
The only thing that clears it, is to export all the data and objects to a
new database, then its ok but starts degrading again afer a few days.
Obviously, exporting is a pain so I'd rather find out what it is the export
does, and find a better way of doing it.
Any pointers please ?
JaneDo you update statistics regularly?
"Jane Sharpe" <JS51@.hotmail.com> wrote in message
news:bu8rvn$651$1@.hercules.btinternet.com...
quote:
> Hi,
> Can anyone give me a clue where to start - I have quite a large database
> that suffers from performance degradation over a few weeks. A select
> statement with 5 joins that runs in 5 seconds can start to take a couple
of
quote:
> minutes.
> The only thing that clears it, is to export all the data and objects to a
> new database, then its ok but starts degrading again afer a few days.
> Obviously, exporting is a pain so I'd rather find out what it is the
export
quote:|||I'm sorry, I dont know what that means (so I guess the answer is no !)
> does, and find a better way of doing it.
> Any pointers please ?
> Jane
>
Jane
"Quentin Ran" <ab@.who.com> wrote in message
news:#LK1gaE3DHA.3436@.tk2msftngp13.phx.gbl...
quote:|||Look for "update statistics" in BOL and see whether doing that helps.
> Do you update statistics regularly?
> "Jane Sharpe" <JS51@.hotmail.com> wrote in message
> news:bu8rvn$651$1@.hercules.btinternet.com...
> of
a[QUOTE]
> export
>
"Jane Sharpe" <JS51@.hotmail.com> wrote in message
news:bu981q$m92$1@.titan.btinternet.com...
quote:
> I'm sorry, I dont know what that means (so I guess the answer is no !)
> Jane
> "Quentin Ran" <ab@.who.com> wrote in message
> news:#LK1gaE3DHA.3436@.tk2msftngp13.phx.gbl...
database[QUOTE]
couple[QUOTE]
to[QUOTE]
> a
>
Subscribe to:
Comments (Atom)