DMS aggrespy

In a standalone OC4J installation (e.g. SOA Suite) the dms can be reached with
http://host:port/dmsoc4j/AggreSpy

If the access is not allowed than a config in the $OH/Apache/Apache/conf/dms.conf does exist which states: Deny from all

What you see is not what you expected

Had a nice issue - which demonstrated that looks can be deceiving.

My colleague asked me to increase the size of a certain tablespace as it was full.
I added a datafile in ASM for this tablespace but put it on autoextend = ON .

He complained that it was still on 100 % full.

A second I thought I messed up things (happens to the best :-)

Then another look solved the problem:
The query - which apparently was used in a lot of Nagios installations - checked only the
datafiles which were on autoextend = no .


The following query was used in Nagios.

select d.tablespace_name "TABLESPACE",
sum(d.bytes)/1048576 "SIZE (M)",
100 -(nvl(round((FREESPCE/(sum(d.bytes)/1048576))*100),0)) "USED (%)"
FROM dba_data_files d,
( SELECT round(sum(f.bytes)/1048576,2) FREESPCE,
f.tablespace_name Tablespc
FROM dba_free_space f
GROUP BY f.tablespace_name)
WHERE d.autoextensible IN 'NO' AND d.tablespace_name = Tablespc (+)
group by d.tablespace_name,FREESPCE,d.autoextensible
order by 1 desc



So, never belief a monitoring tool - unless you have double checked the underlying query.

OC4J status URL's

http://localhost:7200/oc4j-service?cmd=Getprocs
Show the processes

http://localhost:7200/oc4j-service?cmd=p
Show the status

Import large amount of data

For a project we needed to import a large amount of data into a RAC database.

A certain partitioned table with some 4 million rows took ages.

Grid Control showed a large value for the log buffer waits.

So I increased the FAST_START_MTTR_TARGET to reduce the number of checkpoints which worked almost immediately.

Another possibility could have been to increase the log_buffer size (14 M to 32 M) as the ADDM suggested. Maybe I do this as a structural change. Right now changing the parameter on the instance where the import happened solved the problem.

RAC is beautiful

More often than once you will encounter the issue that you need to change an init-parameter that cannot be changed during an active state.


SQL> alter system set sessions=500 scope=both;
alter system set sessions=500 scope=both
*
ERROR at line 1:
ORA-02095: specified initialization parameter cannot be modified

Well - the beauty of RAC is of course that you can change init parameters in the spfile and bounce an instance. Your users won't notice - as the database is still available while you accomplish the change of the init parameter.

SQL> alter system set sessions=500 scope=spfile sid='ORCL4';

System altered.

SQL> shutdown immediate

SQL> startup
ORACLE instance started.

Total System Global Area 1862270976 bytes
Fixed Size 2072096 bytes
Variable Size 436208096 bytes

...