Re: drop user user_name cascade - question

On Sun, 13 Oct 2002 17:00:46 +0200, "Tom Miskiewicz" <miskiewicz2_at_no.spam.yahoo.com> wrote:

>> Depending on the block size of the database (parameter db_block_size,
>> usually 8k)
>Yes, it's 8k
>
>> your setting of db_block_buffers looks way too high (some
>> 560 M) and you also have some 200M shared pool. You must be running
>> out of virtual memory, and this suspicision is underpinned by the core
>> dumps you are getting. The guideline of Oracle is to limit the cache
>> to one third of *physical* RAM, your case some 600M
>> You may also suffer from an insufficient log_buffer parameter, an
>> insufficient sort_area_size parameter (the default is 64k, which is
>> just, ahem, ridiculous), and incorrectly sized online redolog files
>> (in this particular case you need to check for 'checkpoint not
>> complete' and 'cannot allocate log, archival required' messages in
>> your alert.
>It this case, could you pleaes recommend me something, so that I can try:
>
>db_block_buffers = ?

would go for 25000 or 12500
>shared_pool_size = ?

80 M should be sufficient
>sort_area_size = ?

1048576 (1M)
>incorrectly sized online redolog files = set what, where?
>

select * from v$log will show you the size. you'll have to issue alter database drop logfile group alter database add logfile group statements to resolve that, with interspersed alter system switch logfile statements, you can't change the size online.

>
>> Are the affected objects in a locally managed tablespace or a
>> dictionary managed tablespace? In the latter case, you will be getting
>> so-called space transactions (which involves updating sys.uet$ and
>> sys.fet$) using the ST lock, of which there can be only one.
>How do I check that?
>

select * from v$lock will definitely show you (in lock_type) ST transactions
>Thanks in advance!
>
>Tom
>

Hth

Sybrand Bakker, Senior Oracle DBA

To reply remove -verwijderdit from my e-mail address Received on Sun Oct 13 2002 - 15:54:00 CDT