Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssrv26.news.prodigy.com.POSTED!not-for-mail From: Don Seiler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.databases.oracle.server Subject: sqlldr locks fet$ and uet$, blocks smon, 100% cpu usage Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 30 Message-ID: NNTP-Posting-Host: 67.39.35.90 X-Complaints-To: abuse@prodigy.net X-Trace: newssrv26.news.prodigy.com 1063136485 ST000 67.39.35.90 (Tue, 09 Sep 2003 15:41:25 EDT) NNTP-Posting-Date: Tue, 09 Sep 2003 15:41:25 EDT Organization: SBC http://yahoo.sbc.com X-UserInfo1: [[PAPDCAO@W[S_\YGBHNO_\K@CVDB\XILA]T]_MIJQR@EPIB_VUKAH_[MTX\IS[K[NGYJJFNOFZR_G[BUNTAOQLFE^TEHRPI]PZZRP_BMDSFQFL_]CBHXRWCMDCUZAZN@D_AKMNLEI]MWHCSXL^]NNC__CZFGSGHYYXWPFG@SCAVA]\FT\@B\RDGENSUQS^M Date: Tue, 09 Sep 2003 19:41:25 GMT Xref: newssvr20.news.prodigy.com comp.databases.oracle.server:242728 Using Oracle 7.3.4.5 on HP-UX. The subject pretty much says it all. We have an application that uses sqlldr to post back a lot of rows to a table. This table holds ~ 65 million rows. This application has worked fine until this week. Now it will hang, and there will be a process on the server (HP-UX) that uses 100% of a CPU. This pretty much makes the rest of the database unusable. I can't even view the sessions to see who owns that process. I think it is spawned off by the sqlldr, but the parent pid when I do ps -aef says 1, which usually means it's a remote process but the application in question is run locally. However the time run by the process has matched pretty much exactly the time that the sqlldr application was run. Anyway what we can see is that there will be an extraordinary amount of locks on the system fet$ and uet$ tables by the db user that the sqlldr app runs as. These locks are blocking the SMON process. My developers tell me this happens after 90,000 rows or so have gone in, then they can't do any more with sqlldr. They can still insert data with sql*plus, but that isn't really an option. I can't say if it's related, but it shocked me and will probably shock you that this table has over 10 million chained rows. I've read that the two main causes are that the db_block size is too small or the pctfree is wrong. What would be the best way to diagnose the problem and implement the solution. We are planning an upgrade to Oracle 9i (9.2.0.x) this winter so I can make adjustments then I assume. But the locking problem above is of more urgent need.