From: andrew.nelson@astramerck.com
Subject: Re: Poor perfmance after large delete
Date: 1997/04/22
Message-ID: <861738934.30580@dejanews.com>#1/1
References: <5jftum$igu$1@ocoee.iac.net> <4167cd$a52d.28d@mail.prodv.de>
X-Http-User-Agent: Mozilla/3.01C-NSCP  (Win95; I)  via proxy gateway  CERN-HTTPD/3.0 libwww/2.17
X-Originating-IP-Addr: 204.217.184.42 (gatekeeper.astramerck.com)
Organization: Deja News Usenet Posting Service
X-Article-Creation-Date: Tue Apr 22 19:55:34 1997 GMT
X-Authenticated-Sender: andrew.nelson@astramerck.com
Newsgroups: comp.databases.oracle.server



In article <4167cd$a52d.28d@mail.prodv.de>,
  baumkoetter@prodv.de wrote:
>
>
> mwagoner@iac.net (Mark Wagoner) wrote:
>
> >We had been testing our database setup with sample data and decided to try
> >and go live.  The main table had 1.4 million rows, which I deleted by doing
> >a series of DELETE FROM WHERE statements (I tried to truncate the table,
> >but Oracle said there were constraints even after I disabled them all, but
> >that is another problem).  After about 2 hours the main tables were empty
> >so I went in and did a SELECT COUNT(*) to make sure.  It took almost 3
> >minutes for the result to come back!  It took less than 2 seconds when the
> >table was full!
>
> [some stuff deleted]
>
> Hello Mark,
>
> we have the same problem. Oracle told us that the internal hashing
> tables are cleared but the memory is still in use. That makes the
> things slow down.
>
> The only solution we've found ist to drop the table and then recreate
> it. But to do this you have to drop and recreate all dependent
> constraints and all indices too.
>
> So, as you might believe, we're not very happy with this solution. If
> you find a better one, let us know please.
>
> Ciao, Andreas
> -
> Andreas Baumkötter, PRO DV Software GmbH, Dortmund, Germany
> Email to: baumkoetter@prodv.de

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet