This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

Monitoring Index Usage In Oracle 10G Using V$OBJECT_USAGE

Have you got some large indexes creeping around?
Some of my systems have 10GB indexes.
These take valuable resources away from the Oracle database:
– DML time (INSERT, UPDATE etc).
– Stats generation time.
– Segment space (hard disk).
– Structure validation time.
– Recovery time.

Removing the index may not be an option.  But what if it’s not actually used!!

How can we tell if it’s used?
Well you could monitor all SQL in the shared pool using the AWR capture script https://www.remote-dba.net/oracle_10g_tuning/t_oracle_index_usage_tracking.htm, or you could use Jonathan’s script https://jonathanlewis.wordpress.com/segment-scans/ to see if the index segment(s) has been scanned (full scan).  But these don’t comprehensively give you a definitive answer.
There could be holes in your monitoring.

Instead, you could use the V$OBJECT_USAGE view to monitor index usage.
Although a very basic method, if you only want to know definitively if an index has been used or not, then it gives you the answer.
It is described in great detail here: https://wiki.oracle.com/page/Monitor+Index+Usage

Turn on:
alter index <INDEX> monitoring usage;

ALTER INDEX SAPSR3."JCDS~Z01" monitoring usage;

Turn off:
alter index <INDEX> nomonitoring usage;

ALTER INDEX SAPSR3."JCDS~Z01" nomonitoring usage;

Check usage (must be as owner of monitored objects):
select count(1) from v$object_usage;

Or use query below to see all monitored objects:

SELECT
u.name owner ,
io.name index_name ,
t.name table_name ,
DECODE(bitand(i.flags, 65536), 0, 'NO', 'YES') monitoring ,
DECODE(bitand(ou.flags, 1), 0, 'NO', 'YES') used ,
ou.start_monitoring start_monitoring ,
ou.end_monitoring END_MONITORING
FROM
sys.user$ u ,
sys.obj$ io ,
sys.obj$ t ,
sys.ind$ i ,
sys.object_usage ou
WHERE
i.obj# = ou.obj#
AND io.obj# = ou.obj#
AND t.obj# = i.bo#
AND u.user# = io.owner#;

Use EMDIAG REPVFY to fix OEM issues

EMDIAG is a diagnostics utility specifically for the Oracle Enterprise Manager system.
It is useful to diagnose issues with the repository of OEM as it doesn’t need the OMS to be running to use it.

The Oracle document 763072.1 (Oracle Enterprise Manager Grid Control Release Notes for Linux and Windows 10g Release 5) suggests upgrading the EMDIAG kit before performing a general OEM upgrade (it’s in the OEM pre-upgrade tasks list).

Follow the steps in document 421499.1 to install the EMDIAG kit into the C: directory (you should see the old one already installed there).

Follow the process in the document for upgrading the EMDIAG kit and check the Windows environment variable for the EMDIAG_HOME value.

Once installed, use the “repvfy -version” command in the %EMDIAG_HOME%bin directory to verify the current installed OEM software.

To use EMDIAG, set your OracleHome from the command line:

set ORACLE_HOME=C:OracleHomesoms10g

Change to the EMDIAG_HOME bin directory and run repvfy:

Now fix the errors where possible (generic operations that EMDIAG can perform to fix common problems):

repvfy -fix

Some of the problems cannot be fixed automatically.
You can get more details by running verify with greater detail:

repvfy verify TARGETS -level 9 -detail

NOTE: You may want to redirect to a text file in Windows (> c:TARGET_details.txt).

The detailed view may open a can of worms for you.
Good luck!

Optimal Oracle RMAN Backup Command Options


Just a very short post about an optimal Oracle RMAN backup command run block.
Here’s what *I* think provides an optimal backup for a generic setup.

— Check our existing files are available before we do some obsolete deleting.
crosscheck archivelog all;
crosscheck backup;

— Delete any obsolete files before we start so that we have max space available.
— I have “REDUNDANCY 1” set so that I retain the previous backup until the next backup is completed successfully (you need double disk/tape space available for this).
delete noprompt obsolete;

— Do the DB and ARCH log backups but put each datafile into it’s own piece file.
— I prefer this because should I need only a specific datafile restored and I have to go to tape, I only need to get the piece that’s relevant and this piece is only the datafile needed, saving tape restore time.
— For Oracle 9i remove the ‘as compressed backupset’ option.
backup as compressed backupset database filesperset 1 plus archivelog filesperset 1;

— Now only delete archive logs that are in two separate backups.  This is critical.
delete noprompt archivelog all backed up 2 times to disk;

— Delete the previous night’s backup from disk (obviously you need the space to be able to store two backups on disk).
delete noprompt obsolete;

— Finally, always a good idea to keep a list of datafiles and temp files that existed at the time of the backup.
report schema;

Make sure that you always save the RMAN backup logs.
I’ve found that they can be very useful during a restore scenario.

As a tip, you can also run a daily job to list what backups are required to restore a database using the “RESTORE DATABASE PREVIEW SUMMARY;” command.

Detecting & Reducing Space Used For SAP Business Workplace Documents

Within the SAP Netweaver 7.0 system is a complete e-mail tool that allows users to send/receive electronic documents.
These documents are visible in the SAP Business Workplace (TX: SBWP) inbox/outbox and also in the SAP Connect transmission requests (TX: SOST).

As time goes by and users accumulate documents in their inbox and internal/external mails get sent through SAPConnect, space in the database will be used.

SAP Note: 966854 recommends running RSBCS_REORG to clear down these documents and free the space.
Unfortunately it doesn’t tell you how much space is taken up and how much you could get back.

Using the details in SAP Note: 706478 it is possible to check some of the tables at the database level.
Once again, the note doesn’t list all tables involved.
Instead, running the RSBCS_REORG report in “Test” mode reveals the full extent of the tables where records will be deleted:

So using this information, the following constructed SQL query will return the current size of the database segments (Oracle) for the selected tables (FOR ECC 6.0 based systems):


SELECT *
FROM (
select sum(s.bytes)/1024/1024 size_mb ,
s.segment_name,
s.segment_type,
s.segment_name table_name,
t.ddtext descr
from dba_segments s,
sapsr3.dd02t t
where s.segment_name in ('BCST_BOR',
'BCST_CAM',
'BCST_RE',
'BCST_SR',
'SOC3',
'SOCS',
'SOCX',
'SOER',
'SOES',
'SOFM',
'SOOD',
'SOOS',
'SOST')
and s.segment_name = t.tabname
and ddlanguage='E'
group by s.segment_name, s.segment_type, s.segment_name, t.ddtext
union all
select sum(s.bytes)/1024/1024 size_mb ,
s.segment_name,
s.segment_type,
i.table_name,
t.ddtext descr
from dba_segments s,
sapsr3.dd02t t,
dba_indexes i
where i.table_name in (
'BCST_BOR',
'BCST_CAM',
'BCST_RE',
'BCST_SR',
'SOC3',
'SOCS',
'SOCX',
'SOER',
'SOES',
'SOFM',
'SOOD',
'SOOS',
'SOST')
and i.table_name = t.tabname
and i.index_name = s.segment_name
and ddlanguage='E'
group by s.segment_name, s.segment_type, i.table_name, t.ddtext
) t1
ORDER BY t1.table_name ASC, t1.segment_type DESC;

For R/3 4.7 you can use the query below (removes the table and index descriptions):

SELECT *
FROM (
select sum(s.bytes)/1024/1024 size_mb ,
s.segment_name,
s.segment_type,
s.segment_name table_name
from dba_segments s
where s.segment_name in ('BCST_BOR',
'BCST_CAM',
'BCST_RE',
'BCST_SR',
'SOC3',
'SOCS',
'SOCX',
'SOER',
'SOES',
'SOFM',
'SOOD',
'SOOS',
'SOST')
group by s.segment_name, s.segment_type, s.segment_name
union all
select sum(s.bytes)/1024/1024 size_mb ,
s.segment_name,
s.segment_type,
i.table_name
from dba_segments s,
dba_indexes i
where i.table_name in (
'BCST_BOR',
'BCST_CAM',
'BCST_RE',
'BCST_SR',
'SOC3',
'SOCS',
'SOCX',
'SOER',
'SOES',
'SOFM',
'SOOD',
'SOOS',
'SOST')
and i.index_name = s.segment_name
group by s.segment_name, s.segment_type, i.table_name
) t1
ORDER BY t1.table_name ASC, t1.segment_type DESC;

You may just be able to see that the SOC3 table is using ~7GB of space with an index of 144MB and a lob object of 64KB.

Now if you run the RSBCS_REORG report using “Test” mode, with the settings to remove the documents that are >60 days old, then you can estimate what percentage of records will be removed from table SOC3 and therefore estimate the space saving.

As a rule of thumb, it may be wise to remove the documents from users who have left the company.
Generally the SAP account will be locked, so you can pull the account names using the following SQL query then add them into the RSBCS_REORG report “User” field:

SELECT DISTINCT bname FROM sapsr3.usr02 WHERE uflag =128;

NOTE: When running RSBCS_REORG, it will not remove assigned workflows from the “Workflow” folder (or sub-folders).

You may also consider running the report for the user who runs the SAPConnect background job step.  As this user will have the majority of occupied space.

Once you’ve deleted the records that are not required, the space in the database tables will be freed.
However, this will not release the space to the rest of the database, only the tables from where the records were deleted.
Stay tuned for my up-coming post on how to free the table segment space after you’ve removed thousands of records from the Oracle database.

Oracle vs SQL Server – I like it!

I found this today https://www.oaktable.net/sites/default/files/deathmatch.pdf
It shows a good comparison of basic syntactical differences in SQL Server and Oracle when looking to compare performance / features.
I especially like the use of blockrecover in RMAN towards the end.  Nice.

Just take a look at the tags for it’s hosting blog page and it’s obvious which one will win without even reading the slide.