BEGIN
DBMS_SPACE_ADMIN.DROP_EMPTY_SEGMENTS();
END;

This is a great news for DBAs who are working with PeopleSoft applications.In PeopleSoft applications there are thousands of tables were created and never populated with any rows.In my present HRMS 9.0 production database,there are 23091 tables and 26228 indexes are with zero rows.If I use this package,I would save approximately 60GB of space.

We have 10s of non-production databases,which are getting refreshed every now and then with the copy of production and this new feature will save us a lots of disk space and some cost.

Now time to test this feature.

SQL> select count(*) from sysadm.PS_UPG_APPL_RES;
 

COUNT(*)
———-
         0

SQL> @tbl PS_UPG_APPL_RES
 

   BLOCKS   NUM_ROWS SAMPLE_SIZE Analyzed          AVG_ROW_LEN
---------- ---------- ----------- ----------------- -----------
         0          0           0 06/20/11 22:32:17           0

SEGMENT_NAME           BLOCKS    EXTENTS INITIAL_EXTENT
—————— ———- ———- ————–
PS_UPG_APPL_RES             8          1          40960

SQL> exec dbms_space_admin.drop_empty_segments(schema_name=>’SYSADM’,table_name=>’PS_UPG_APPL_RES’);

PL/SQL procedure successfully completed.

SQL> select segment_name,bytes,extents from dba_segments where segment_name=’PS_UPG_APPL_RES’;

no rows selected

I also tested with dropping segment that has more than one row.

SQL> create table t1(id number);

Table created.

SQL> select segment_created from user_tables where table_name=’T1′;

SEG
—
NO

SQL> select segment_name,bytes,extents from user_segments where segment_name=’T1′;

no rows selected

SQL> begin
  2  for i in 1..2000 loop
  3  insert into t1 values(i);
  4  end loop;
  5  end;
  6  /

PL/SQL procedure successfully completed.
 
SQL> select segment_created from user_tables where table_name=’T1′;

SEG
—
YES

SQL> select segment_name,bytes,extents from user_segments where segment_name=’T1′;

SEGMENT_NAME        BYTES    EXTENTS
—————– ———- ———-
T1                 65536          1
 

SQL> exec dbms_space_admin.drop_empty_segments(schema_name=>’TEST’,table_name =>’T1′);

PL/SQL procedure successfully completed.
 

SQL> select segment_name,bytes,extents from user_segments where segment_name=’T1′;

SEGMENT_NAME        BYTES    EXTENTS
—————– ———- ———-
T1                 65536          1
 

SQL> select count(*) from test.t1;

  COUNT(*)
———-
      2000

As expected,the procedure drops only empty segments.It would be ideal to get an error message when we try to drop non-empty segments instead of “successfully completed” message.

Ok.let’s see what Tools 8.50 provides?

Let me navigate into PeopleSoft to see whether the columns are getting updated correctly or not.

I navigated to User Profiles page which is a search page before going into the component.I checked the columns and surprised to see the one on the ACTION column.

 PROGRAM            MODULE            ACTION            CLIENT_INFO
————-             ———-              ———              ——————————–
 PSAPPSRV.exe  USERMAINT     xyzzy                PS,,oraclevm,HR9DMO,PSAPPSRV.exe

What is the meaning of  “xyzzy”??? It is one of most essential monitoring statistics.Because I have had many cases where user used to complain that my search page is taking too long to display.Oracle sets “xyzzy” for all search pages and so what is the use of this data?

Then after I entered into the component,it’s setting the ACTION value as documented.

PROGRAM        MODULE        ACTION
————– ————- ————–
PSAPPSRV.exe   USERMAINT     USER_GENERAL

As far as Application engine is concerned,we only get very limited information i.e. the program name.It doesn’t update ACTION with each step of the program which is desirable for analyzing ASH and AWR data.It’s not uncommon to run AE programs parallely or concurrently.If we group ASH data by ACTION,we cannot correlate the data with a particular session.

Similarly,the values for SQR program is disappointing.They should atleast set ACTION to the program name.I am not sure what’s the logic behind pouplating both module and action with “sqrw.exe”.

On the whole,I welcome this move from Oracle  and we certainly expect better instrumentation in the future releases..

In the mean time,I am happily use my own triggers to get the data which I wanted for anlysis and troubleshooting..

Cheers!

       SID NAME                                SQLID                    OBJECT       Held       Gets  Held %     Held ms Avg hold ms
———- ———————————– ————- —————– ———- ———- ——- ———– ———–
       644 cache buffers chains                f5wauqmvrv4af           18000DA         34         34     .03       2.475        .073
       616 cache buffers chains                17bysmbufufc2           18000DA         32         32     .03       2.330        .073
       619 cache buffers chains                dprdb6ng88vch           18000DA         30         30     .03       2.184        .073
 
– Find the hot block
 
SQL> @dba 1800527
    RFILE#     BLOCK# DUMP_CMD
———- ———- ———————————————————————————————————————
         6       1319 — alter system dump datafile 6 block 1319

STATE      BLOCK_CLASS        OBJECT_TYPE         DATA_OBJECT_ID object                                          TCH  MODE_HELD D T P S D FLG_LRUFLG                  DQ
———- —————— ——————- ————– —————————————- ———- ———- – - – - – ——————- ———-
xcur       data block         INDEX                        70409 ODS.ST_P1_ORCLEVENTTIME                           71          0 N N N N N 80000:4                      0

 
It’s evident that the sessions were trying to acquire the same block and thereby causes contention on CBC latch.
Further looking into the index reveals that there are 124 keys are packed into one leaf block.
 
Table_Name                       Index_Name                          Tbl_Blocks      Num_Rows     BLEVEL LEAF_BLOCKS            CF DISTINCT_KEYS
——————————– ——————————– ————- ————- ———- ———– ————- ————-
P1_CT_ORCLEVENTTIME              ST_P1_ORCLEVENTTIME                         20          4855          1          20            18          4855
P1_CT_ORCLEVENTTIME              VA_P1_ORCLEVENTTIME                         20          4855          1          20            18          4855
 
 
SQL> SELECT
  2  keys_per_leaf,
  3  count(*) “LeafBlocks”
  4  from
  5  (
  6  select sys_op_lbid(70409,’L',t.rowid) block_id,
  7  count(*)  keys_per_leaf
  8  from
  9  ODS.P1_CT_ORCLEVENTTIME t
 10  where (ENTRYID is not null or ATTRVALUE is not null or ATTRTYPE is not null)
 11  group by
 12  sys_op_lbid(70409,’L',t.rowid)
 13  )
 14  group by keys_per_leaf
 15  order by keys_per_leaf
 16  ;
 
KEYS_PER_LEAF LeafBlocks
————- ———-
          124          1    >>>  124 keys in 1 block
          249         19
 
It’s time to verify the SQLs and their plan.Most of the SQLs are using Nested Loops join.The estimated cardinality with the default statistics values was wrong which leads the optimizer to choose a sub-optimal plan.
 
Then I verified the statistics of the associated tables.I am shell shocked to see none of them are having statistics.The application’s admin team  forgot to run oidstats.sql which is the utility provided by oracle to collect statistics on ODS schema after each bulk load.Once the statistics are collected and the application was restarted,the CPU consumption was back to normal and the problematic SQLs are now using hash joins as expected.
 
Again,the right tool at the right time and it’s Tanel’s (My Oracle Guru) latchprofx makes my job easier.
 
I will see you all soon with another interesting blog…
 
Cheers!