Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!pd2nf1so.cg.shawcable.net!residential.shaw.ca!sjc70.webusenet.com!news.webusenet.com!sn-xit-02!sn-xit-04!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: Sybrand Bakker Newsgroups: comp.databases.oracle.server Subject: Re: sqllder hangs at 99-100% CPU on select of fet$ Date: Wed, 10 Sep 2003 00:39:19 +0200 Organization: Posted via Supernews, http://www.supernews.com Message-ID: Sender: Sybrand Bakker Reply-To: postbus@sybrandb.demon.nl References: <3F5E4F9B.3040503@seiler.us> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@supernews.com Lines: 51 Xref: newssvr20.news.prodigy.com comp.databases.oracle.server:242736 On Tue, 09 Sep 2003 22:08:48 GMT, Don Seiler wrote: >> SELECT length >> FROM fet$ >> WHERE file# = :1 >> AND block# = :2 >> AND ts# = :3 >> >> I'm assuming that sqlldr does that on it's own because my developers >> have no idea what fet$ is. This process locks fet$ and eventually will >> block SMON from accessing the table. This whole mess makes the database >> unusable until I kill the sqlldr's oraclesid process. This is not a function of sqlldr but a function of Oracle when it needs to extend a table. The used extents are being maintained in uet$, the free extents are maintained in fet$. It means in a few words, you probably have excessive free space fragmentation, and the query needs to run repeatedly to find an appropiate free extent. In short, what you see now are the dire consequences of years of neglect. (I won't even mention that you wouldn't have had the issue when you would have upgraded to 8i, and would have set up locally managed tablespaces) You need to reorganize that tablespace, and there is no way you can escape from that. Your problems have NOTHING at all to do with sqlldr, if you would INSERT a few thousand rows, you would probably face the same problem. You need to investigate the fragmentation of that tablespace, the number of extents of the affected table in relation to it's size. You can't also escape from export/import for that table, as it is the only method in 7.3 to get rid of the chaining issue. You can issue the command analyze table list chained rows into provided you run $ORACLE_HOME/rdbms/admin/utlchain.sql to set up a chain table prior to analyzing it. You can also ANALYZE table compute statistics to determine the size of the average record, in comparison to the database block size. These statistics will end up in user_|dba_tables. Finally you'll need to convince your boss to send you to an administrators course. You seem to be completely clueless, and you are just lucky you have survived so far. Regards Sybrand Bakker, Senior Oracle DBA To reply remove -verwijderdit from my e-mail address