RE: ORA-04031
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 14 Jul 2004 12:14:17 -0400
I'm a tad rusty on this due to my tendency to cure this particular problem
with overkill on memory allocation instead of spending time on it. (Okay, I
shouldn't mention the untimely deaths of developers who code monoliths, but
that has a restraining effect on the survivors.)
But I believe they want you to LOWER the number of objects being cached by
INCREASING the minimum chuck of memory that is allowed to be allocated from
the shared pool reserved area. (That probably tends to make garbage
collection a bit easier and fragmentation less of a problem.)
If I have that right, then fewer larger objects will go into the 4M you have
for shared_pool_reserved_size.
As far as tuning this, I'm thinking "what is the cost of down time and your
time." I'd go BIG. Then if it still fails, there is probably something
pathologically wrong with your code. If so, fix the code. If not, and you
insist on saving some memory, cut it in half (standard binary search
protocol)
until you start to get failures. Then revert to the last size that always
seemed to work. Cut what in half?
Well, if you want to keep your 10% of shared is reserved ratio, then do them
together. So, say 400M shared and 40M reserved. If you still get failures
then 800M and 80M (or start checking the code). If the failures end, try
200M and 20M. You get the idea. Machines should do this dynamically, not
people.
(See 10g. All this just give me a target business could really work out
well, especially with saving where you were for a warm start.)
Now that underbar parm - As I said, I'm a bit rusty on that. I hope someone
chimes in if I've got the direction wrong on that, but I think your "next
move" on that one would be 8800, not 2200, if you want to try to live within
the 40M and 4M limits you've set. If I've got the direction wrong, then that
is a metalink doc bug, too, since the note actually is in agreement with me.
Frankly I'd avoid the underbar parm and give it more space.
Good luck.
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of
Paula_Stankus@xxxxxxxxxxxxxxx
Sent: Wednesday, July 14, 2004 10:28 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: ORA-04031
Platform:
Oracle 9.2.0.5
Solaris 2.9
ArcSDE 8.3
I am running a DSS - geodatabase with 30 concurrent users. I am getting =
ORA-04031 errors.
I have verified that last_failure_size > shared_pool_reserved_min_alloc. =
According to Note: 146599.1 it states that I should increase the =
hidden parameter "_shared_pool_reserved_min_alloc" to lower the number =
of objects being cached. =20
It is currently set at 4400 - how much lower would I need to go????
It also states I should consider increasing the =
shared_pool_reserved_size and shared_pool_size but these parameters seem =
adequate to me:
40M for shared_pool_size
4M for shared_pool_reserved_size
I have gone through NOTE: 1012046.6 "Calculating Shared Pool size" and =
based on that my shared_pool_size is more than adequate.
How can I more specifically size the shared pool, shared reserved pool =
as I know that if I size too large then I can start incurring overhead.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Ruth Gramolini
Sent: Wednesday, July 14, 2004 8:41 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: rman nocatalog - point in time recovery
Sometimes I find it is just expedient to use sqlplus to open the =
database.
Sometimes, there is no other way. Rman is still a work in progress and =
it
has been seriously improved since the 8.0.5... days but when you are =
doing
incomplete recovery and it seems to want a redo log instead of an =
archived
log, then I have found, sqlplus recover the way you did it is the =
easiest
way. Even Oracle support has told me this.
HTH,
Ruth
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Schauss, Peter
Sent: Tuesday, July 13, 2004 4:44 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: rman nocatalog - point in time recovery
This may not be the cleanest solution, but it worked:
rman
run {
set until logseq=3D1235 thread =3D1;
allocate channel ch1 type disk;
allocate channel ch2 type disk;
allocate channel ch3 type disk;
restore database;
}
exit;
sqlplus internal
sqlplus> recover database until cancel using backup controlfile;
sqlplus> alter database open resetlogs;
sqlplus> exit;
Is there a better way to do this?
thanks,
Peter Schauss
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Schauss, Peter
Sent: Tuesday, July 13, 2004 4:12 PM
To: Oracle-L (E-mail)
Subject: rman nocatalog - point in time recovery
Enviroment: Oracle 8.1.7.4 / AIX 5.2
Scenario:
- I have an rman backup (nocatalog) and a separate control file backup
done at 11:00 pm.
- The database is in archivelog mode.
- At 11:00 am the next morning I have a failure which causes
loss of the entire database.
- Archivelogs through 10:45 are intact. The last archive log is =
sequence
1234.
- I have the backup files created from the 11:00 pm rman backup in the
directory
to which they were backed up.
- I want to restore the database to the state it was in at 10:45 am by
applying
the redo logs through number 1234.
I restore my control files by copying them to the appropriate =
directories on
the disk (e.g. /ora1/oradata/sid/control01.ctl ... /ora2/... =
/ora3/...).
I run the following commands in rman
run {
set until logseq=3D1234 thread=3D1;
allocate channel ch1 type disk;
allocate channel ch2 type disk;
allocate channel ch3 type disk;
restore database;
recover database;
alter database open resetlogs;
}
Oracle says:
RMAN-03002: failure during compilation of command
RMAN-03013: command type: set
RMAN-06003: ORACLE error from target database: RMAN-20206: log sequence =
not
found in the recovery catalog
What am I missing here?
Thanks,
Peter Schauss
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------
Teach CanIt if this mail (ID 4586007) is spam:
Spam: =
https://dohsmsi01.doh.state.fl.us/canit/b.php?c=3Ds&i=3D4586007&m=3Ddd09e=
d4dec9a
Not spam: =
https://dohsmsi01.doh.state.fl.us/canit/b.php?c=3Dn&i=3D4586007&m=3Ddd09e=
d4dec9a
Forget vote: =
https://dohsmsi01.doh.state.fl.us/canit/b.php?c=3Df&i=3D4586007&m=3Ddd09e=
d4dec9a
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
