Right - I just heard what the problem was, and have to say that it was in
fact the first thing that I though of - when they upgrade to the new version
of the application, somebody forgot to create one of the indexes on the
table!
Problem solved!
Cheers
Mark
-Original Message-
Sent: 29
Not necessarily.
You could rebuild and then analyze and delete the statistics.
-Original Message-
Sent: 29 November 2001 14:25
To: Multiple recipients of list ORACLE-L
Does this mean that if you are running in RULE, you shouldn't REBUILD
indexes, but drop and recreate them?
You lear
Hi Mark,
It actually shouldn't matter if you are really in RULE, but in Choose, where
you expect to have and NO STATS performing using RBO by default, you
should issue the command
analyze index delete statistics
After rebuilding the index.
Hope this helps,
John
[EMAIL PROTECTED] wrote:
Does this mean that if you are running in RULE, you shouldn't REBUILD
indexes, but drop and recreate them?
You learn something new every day..
Cheers
Mark
-Original Message-
Mengler
Sent: 29 November 2001 12:41
To: Multiple recipients of list ORACLE-L
Be aware that at least for V7.3.
Be aware that at least for V7.3.4.5 the SQL
ALTER INDEX Hi all,
>
> Thanks for your responses on this - I had most of them in mind - but there
> were a couple out there (PCTUSED/PCTFREE and child table FK/indexes) that I
> hadn't thought of.
>
> To give you a little more info on this - and let yo
Hi all,
Thanks for your responses on this - I had most of them in mind - but there
were a couple out there (PCTUSED/PCTFREE and child table FK/indexes) that I
hadn't thought of.
To give you a little more info on this - and let you know what I know so
far:
This is on an 8.0.6 database running in
I think the condition used to delete the records for table is not matching
with the indexes of that table. check the indexes properly and the delete
statement also accordingly and make sure that the condition/column which is
given to delete is present in the index.
-Original Message-
Faro
Title: RE: Delete slowing..
Hi,
Perhaps you check the Indexes against that table, you can drop the index
first,
you
may consider a TRUNCATE TABLE command if you not need the rollback
option.
Sinardy
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Title: RE: Delete slowing..
Mark, something else to add to your list of things to check
Does a FTS of the table take a long time as well?
If so I would try re-creating the table to remove the space left by previously deleted rows.
John
-Original Message-
From: Stephane Faroult
EMAIL PROTECTED]
[EMAIL PROTECTED]
tate.ny.usTo: [EMAIL PROTECTED]
Sent by: cc:
[EMAIL PROTECTED]Subject: RE: Delete slowing..
om
11/
Title: RE: Delete slowing..
Mark, how many indexes are on the table? Are there any unindexed foreign keys?
Lisa Koivu
Oracle Database Monkey Mama.
Fairfield Resorts, Inc.
954-935-4117
-Original Message-
From: Mark Leith [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, November 27
: Delete slowing..
om
Mark Leith wrote:
>
> Hi list people :)
>
> We have a customer who has been running a particular delete statement
> against a table for a while now, which usually ran within minutes. All of a
> sudden this table has suddenly gone from a few minutes right up to 50! He
> wants to diagnose why..
>
Mark,
check for foreign key/missing index combinations. If the table is a parent
table, and it's child's foreign key's column is not indexed, the delete can
take *forever* if the child is a large table.
Tom Mercadante
Oracle Certified Professional
-Original Message-
Sent: Tuesday, Nov
Hi list people :)
We have a customer who has been running a particular delete statement
against a table for a while now, which usually ran within minutes. All of a
sudden this table has suddenly gone from a few minutes right up to 50! He
wants to diagnose why..
Where would you start?
I have a f
15 matches
Mail list logo
