Showing posts with label diagnostics. Show all posts
Showing posts with label diagnostics. Show all posts

Friday, 11 April 2014

Calculating a segment growth in the Oracle RDBMS

There are few ways I can think of, which allow for monitoring or calculation of segments' growth - the easiest one is to snap whole the DBA_SEGMENTS table into some helper store and apply custom logic, which may be a focus on the biggest segments or the ones with biggest growth rate.
I would like however to describe a different way using the DBA_HIST_SNAPSHOT and DBA_HIST_SEG_STAT tables.

License

First things first - is one authorized to use it? As You certainly know there is nothing sure about the Oracle licensing or at least such is the common viewpoint.
I found in this regards the following excerpt (the source), but it can not be used as an excuse:
All data dictionary views beginning with the prefix DBA_HIST_ are part of this pack, along with their underlying tables.The only exception are the views: DBA_HIST_SNAPSHOT, DBA_HIST_DATABASE_INSTANCE, DBA_HIST_SNAP_ERROR, DBA_HIST_SEG_STAT, DBA_HIST_SEG_STAT_OBJ, and DBA_HIST_UNDOSTAT. They can be used without the Oracle Diagnostics Pack license.
Anyway we have got such license for our environments for other reasons, so do not care much for it.

The DBA_HIST_SNAPSHOT

The most important columns for me are:
  • DBID, SNAP_ID, INSTANCE_NUMBER - those 3 I enlist at once because they construct the only index created on underlying table WRM$SNAPSHOT (the order important). Of course the column 3 is important only if one uses RAC and the column 1 only if the data are gathered in one place from many databases. In my simple scenario I need to provide despite the SNAP_ID only the DBID (select dbid from v$database) in order to allow the optimizer to use that index if reasonable.
  • STARTUP_TIME - this is a timestamp of the current database startup, very important border - all the TOTAL* values are cumulated since this timestamp. One example here: the SPACE_USED_TOTAL column not necessarily will show You the current storage space used by the segment. In fact it will show You the sum of all the deltas (in this case the SPACE_USED_DELTA column) since the STARTUP_TIME.
  • BEGIN_INTERVAL_TIME, END_INTERVAL_TIME - the ceasuras placing a snapshot in time. I use mostly the BEGIN_INTERVAL_TIME as means to choose only one month worth snapshots.


The DBA_HIST_SEG_STAT

The most important columns here are:
  • DBID, SNAP_ID, INSTANCE_NUMBER, TS#, OBJ#, DATAOBJ# - again I list them as one. Again those columns form the only index on the underlying table WRH$_SEG_STAT. Despite that SNAP_ID provides the link to the DBA_HIST_SNAPSHOT, while TS# identifies the tablespace and the OBJ# and DATAOBJ# a particular segment
  • SPACE_USED_TOTAL, SPACE_USED_DELTA, SPACE_ALLOCATED_TOTAL, SPACE_ALLOCATED_DELTA - DELTA shows the increment in used space for the current snapshot, TOTAL - aggregate of DELTAs (in this case the sum) since the startup.
  • there are plenty of other counters, but they are irrelevant in the context of storage space, so I do not write about them

Finally the SQL

I will present here few possibilities. Here the first one:
with snaps as (select min(snap_id) min_snap, max(snap_id) max_snap 
from dba_hist_snapshot where begin_interval_time > ADD_MONTHS(sysdate,-1))
select 
O.TABLESPACE_NAME,
O.OWNER||'.'||O.OBJECT_NAME oid,
o.object_type,
--min(SNAP_ID) MIN_OBJ_SNAP,
--max(SNAP_ID) max_obj_snap,
--MIN(H.SPACE_USED_TOTAL) min_space_used, 
SUM(H.SPACE_USED_DELTA) SPACE_USED, 
SUM(H.SPACE_ALLOCATED_DELTA) space_alloc
from
DBA_HIST_SEG_STAT H join dba_hist_seg_stat_obj o 
on h.dbid=o.dbid and h.ts#=o.ts# and h.obj#=o.obj# and h.dataobj#=o.dataobj#
WHERE 1=1
AND H.SNAP_ID BETWEEN (SELECT MIN_SNAP FROM SNAPS) AND (SELECT MAX_SNAP FROM SNAPS)
and H.DBID = (select DBID from V$DATABASE)
and H.INSTANCE_NUMBER = (select INSTANCE_NUMBER from V$INSTANCE)
and O.OWNER != '** MISSING **' -- segments already gone
and O.OBJECT_NAME not like 'BIN$%' -- recycle-bin
and O.OBJECT_NAME not like 'SYS_%' -- LOBs, etc - not too representative
AND o.OWNER NOT IN ('APEX_030200','SCOTT','OWBSYS','PERFSTAT',
'FLOWS_FILES','PUBLIC','SYS','SYSTEM','OUTLN','DIP','DBSNMP','WMSYS', 
'EXFSYS','DMSYS','CTXSYS','XDB','ANONYMOUS','ORDSYS','ORDPLUGINS','SI_INFORMTN_SCHEMA',
'MDSYS','OLAPSYS','MDDATA','SYSMAN','MGMT_VIEW','VIP')
group by 
O.TABLESPACE_NAME,
O.OWNER||'.'||O.OBJECT_NAME,
o.OBJECT_TYPE
having SUM(H.SPACE_ALLOCATED_DELTA)>0

Monday, 22 July 2013

ORADEBUG session for AQ

SQL> select owner, job_name from dba_scheduler_jobs 
SQL> where lower(job_action) like '%register_driver%'
OWNER                          JOB_NAME                     
------------------------------ ------------------------------
SYS                            AQ$_PLSQL_NTFN21               

SQL> select SESSION_ID, SLAVE_PROCESS_ID, SLAVE_OS_PROCESS_ID 
SQL> from DBA_SCHEDULER_RUNNING_JOBS where job_name='AQ$_PLSQL_NTFN21'
SESSION_ID SLAVE_PROCESS_ID SLAVE_OS_PROCESS_ID
---------- ---------------- -------------------
        16               26 26823               

SQL> select sid, serial#, paddr, program from v$session where sid=16
SID SERIAL# PADDR            PROGRAM                                        
--- ------- ---------------- ------------------------------------------------
 16       1 000000009F67D7A8 oracle@dt-bpss-db-04-2 (J000)                    

SQL> select spid from v$process where addr='000000009F67D7A8'
SPID                   
------------------------
26823                    
-------------------
SQL> oradebug setospid 26823
Oracle pid: 26, Unix process pid: 26823, image: oracle@dt-bpss-db-04-2 (J000)
SQL> oradebug unlimit
Statement processed.
SQL> oradebug Event 10046 trace name context forever, level 12
Statement processed.
SQL> select sysdate from dual;

SYSDATE
-------------------
2013-07-18 13:57:50

SQL> oradebug Event 10046 trace name context off
Statement processed.

Friday, 17 August 2012

Problems with connection

From time to time there happens different problems with connections to Oracle database. Below little report about those I have met.

  • problems on client

    Usually they are trivial and bound with tnsnames.ora. Wrong PATH variable (for example few ORACLE_HOME/bin entries), wrong LD_LIBRARY_PATH, entries in the tnsnames.ora with some unusual blank character, wrong syntax in this file, wrong service_name. For example today 2 different tnsnames.ora files, while part of programs uses the right one, and some the wrong one.
    While trivial, sometimes hard to diagnose, especially by phone.

    Fortunately it is easy to get very detailed trace. We need in sqlnet.ora few entries:
    TRACE_LEVEL_CLIENT=16 #or SUPPORT
    TRACE_FILE_CLIENT=mytrace #useful for identification
    TRACE_DIRECTORY_CLIENT=traces #useful for location
    
    The output is quite detailed and usually helpful in the diagnosis.
  • problems on cman

    Of course if one uses it (we do). I have met 3 major problems with it (and this is relevant for 11g version).

    The first one was with the raise of 11g version. The cman needs one rule to connect to itself. Till the 10g it was for example:
    (RULE=(SRC=10.0.50.10)(DST=127.0.0.1)(SRV=cmon)(ACT=accept))
    
    With 11g it must be (at least on Linux):
    (RULE=(SRC=10.0.50.10)(DST=::1)(SRV=cmon)(ACT=accept))
    
    The Metalink (ID 298916.1) still provides address 127.0.0.1 as a right one, and indeed the cman starts, but one can not connect to it with cmctl. Possibly it works, but one can not control it. I always needed to kill the cman process with kill utility to change anything (and no, we did not use it on production before the problem was solved).

    The second problem was with some older RDBMS versions (ie. before 10g) - we needed to add to simple rule some settings, for example:
    (RULE=(SRC=10.0.50.12)(DST=10.0.60.11)(SRV=*)(ACT=accept)(ACTION_LIST=(mct=0)))
    
    Usually it is enough to end with ACT attribute. This particular case with RDBMS servers on Windows kind os.

    The third one was with error in syntax. Once we loose somewhere in the middle of cman.ora a parenthesis. The cman kept all the rules from the time before error emergence, thus in the rules there were rules located before the point of error as well as those after it. When we added rules before that point and reloaded, everything was fine, if we added after, the rules were ignored. Because we always reloaded, the cman worked and for some time we were unaware of the problem at all.
    The true incident we met, when were trying to restart the cman. It went down and we can not start it up. IIRC the returned error was about problem in the configuration file in the end of it (which of course was due to mess in parentheses). The solution here was to display the config with VIM and color the syntax. Eventually we found the place for lacking parenthesis. The problem was trivial, but not so obvious.

    To those three I add yet another - in our case it was lack of mapping IP->hostname in /etc/hosts, possibly similar situation if no proper name in DNS service available (if used instead of /etc/hosts mapping). In result the cman service returned ORA-12529, even though the cman.ora configuration does not use host names at all (all rules with IP).
    The same happens when the entry in /etc/hosts differs from DST hostname.
  • problems on server

    Both problems on server had something to do with firewalls.
    Once it was MTU parameter, which default value appeared too large after some firewall software update.
    The other problem was with inactivity timeout. Some of our firewalls disconnect connections, on which there is no traffic during specified time. A solution here seems to be enabling dead connection detection (DCD) feature. This feature implementation is based upon sending for time to time some bytes as a heartbeat - thus there is some traffic on a connection, so it is not broken.