AskDba.org Weblog

AskDba.org Weblog

Writing About Our Experiences With Oracle Databases

AskDba.org Weblog RSS Feed
 
 
 
 

CleanUp Temporary Segments Occupying Permanent Tablespace

There are situations when we see “temporary segments” in permanent tablespaces hanging around and not getting cleaned up.
These temporary segments in permanent tablespace can be created by DDL operations like CTAS and “alter index..rebuild” because
the new object is created as a temporary segment in the target tablespace and when the DDL action finishes it will be changed to permanent type.
These temporary segments take actual disk space when SMON fails to perform its assigned job to cleanup stray temporary segments.
Following query finds out these segments:

 SQL > select tablespace_name, owner, sum(bytes/1024/1024) from dba_segments
where segment_type = 'TEMPORARY' group by tablespace_name, owner;

TABLESPACE_NAME     OWNER          SEGMENT_NAME     SUM(BYTES/1024/1024)
------------------- ------------   ------------     --------------------
xxxx_DATA           SYS              123.8365          137706
BDEPST_INDEX        SYS              345.8756            8910
KMRPT_DATA          SYS                345.87       25284.875
BILL_INDEX          SYS                                   .25
DSS_DATA            SYS                                   798
MRKT_INDEX          SYS                                   208
SPCT_DATA           SYS                              69642.25
SPCT_INDEX          SYS                              956.4375

Here we can see that tablespace KMRPT_DATA, SPCT_INDEX and SPCT_DATA have large temporary segments.

To know if any DDL is active which can create temporary segments we can use the following:

SQL> conn / as sysdba
SQL> select owner FROM dba_segments WHERE segment_name='345.87';
SQL> select pid from v$process where username='owner from above query';
SQL> alter session set tracefile_identifier='TEMPORARY_SEGMENTS';
SQL> oradebug setorapid <pid obtained>
SQL> oradebug dump errorstack 3
SQL > oradebug tracefile_name

It will give you the tracefile name, open that file and check for the “current sql”
If it is a DDL like CTAS or index rebuild, then wait for the operation to complete. If there is no pid
returned then these segments are “stray segements” and needs to cleaned up manually.

There are two ways to force the drop of temporary segments:

1. Using event DROP_SEGMENTS
2. Corrupting the segments and dropping these corrupted segments.

1. Using DROP_segments:

Find out the tablespace number (ts#) which contains temporary segments:
SQL> select ts# from sys.ts$ where name = 'tablespace name';

Suppose it comes out to be 10, use the following command to cleanup temporary segments:

SQL> alter session set events 'immediate trace name DROP_SEGMENTS level 11';

level is ts#+1 i.e 10+1=11 in this case.

2. Corrupting temporary segments for drop:
For this following procedures are used:
- DBMS_SPACE_ADMIN.TABLESPACE_VERIFY
- DBMS_SPACE_ADMIN.SEGMENT_CORRUPT
- DBMS_SPACE_ADMIN.SEGMENT_DROP_CORRUPT

– Verify the tablespace that contains temporary segments (In this case it is KMRPT_DATA)

SQL> exec DBMS_SPACE_ADMIN.TABLESPACE_VERIFY('KMRPT_DATA');

– Corrupt the temporary segments in tablespace KMRPT_DATA

SQL> select 'exec DBMS_SPACE_ADMIN.SEGMENT_CORRUPT(' || chr(39) || tablespace_name || chr(39) || ',' || HEADER_FILE || ',' || HEADER_BLOCK || ');'  from dba_segments where SEGMENT_TYPE like 'TEMP%' and tablespace_name = 'KMRPT_DATA';

– Drop the corrupted temporary segments

SQL> select 'exec DBMS_SPACE_ADMIN.SEGMENT_DROP_CORRUPT (' || chr(39) || tablespace_name || chr(39) || ',' || HEADER_FILE || ',' || HEADER_BLOCK || ');' from dba_segments where SEGMENT_TYPE like 'TEMP%' and tablespace_name = 'KMRPT_DATA';

– Verify the tablespace again to update the new dictionary information:

SQL> EXECUTE DBMS_SPACE_ADMIN.TABLESPACE_VERIFY('KMRPT_DATA');

This will remove temporary segments from permanent tablespace.

Cheers!!!

Saurabh Sood

Use awk/sed in vi

Thought of sharing some useful info which can help you to do your work faster in vi.You can use awk/sed scripts in vi using following command in vi

:%!scriptname

Here the scriptname file should have execute privilges for user. I used this to create a useful script which I was doing by typing multiple substitution command in vi.

e.g Your file contains list of table
$cat t.lst
BANK005
BJSTM
BJS_ORG
CHAINED_ROWS
CORR_BAM
CORR_CAM
CORR_EIT
CORR_GAC
CORR_GAM
CORR_ITC
CORR_LDT
CORR_LHT
Create script (quotes)  with following command and give execute permission to user.

sed -e “s/^/’/g” -e “s/$/’,/” $1|awk ‘{printf (”%s”,$0)}’|sed -e “s/^/(/g” -e “s/,$/)/g”

open t.lst in vi and type :%!quotes
('BANK005','BJSTM','BJS_ORG','CHAINED_ROWS','CORR_BAM','CORR_CAM','CORR_EIT','CORR_GAC','CORR_GAM','CORR_ITC','CORR_LDT','CORR_LHT')

Similarly if you wish to remove blank lines, have a file blank like

awk ‘!NF==0 {print $0}’ $1
Blank lines can also be directly removed from vi using :g/^$/d
Isn’t it cool.. :)

dbms_stats.copy_table_stats does not alter low/high value

I was working on a performance issue arising due to missing table stats on a new partition for large Partitioned table.This was a 10.2.0.4 database on IBM AIX 5L. So as to resolve the issue , I used dbms_stats.copy_table_stats to copy the stats to new parition from the previous partition.

EXEC DBMS_STATS.COPY_TABLE_STATS (’owner’, ‘tabname’, ‘SourcePart’, ‘TargetPart’)

You can find more details about it in below link

http://optimizermagic.blogspot.com/2009/02/maintaining-statistics-on-large.html

There is one more link explaining this with example

http://dioncho.wordpress.com/2009/02/12/how-to-copy-partition-stats-we-got-easier-way/

Article from Optimizer development group states that the low and high value for the target partition is set from the partition key values. But when I used dbms_stats.copy_table_stats, I found that it is not the case and it actually copies the low and high values from the previous partition.

You can use following function to check the high and low values ( Thanks to Greg Rahn’s article )

create or replace function display_raw (rawval raw, type varchar2)
return varchar2
is
   cn     number;
   cv     varchar2(32);
   cd     date;
   cnv    nvarchar2(32);
   cr     rowid;
   cc     char(32);
begin
   if (type = 'NUMBER') then
      dbms_stats.convert_raw_value(rawval, cn);
      return to_char(cn);
   elsif (type = 'VARCHAR2') then
      dbms_stats.convert_raw_value(rawval, cv);
      return to_char(cv);
   elsif (type = 'DATE') then
      dbms_stats.convert_raw_value(rawval, cd);
      return to_char(cd);
   elsif (type = 'NVARCHAR2') then
      dbms_stats.convert_raw_value(rawval, cnv);
      return to_char(cnv);
   elsif (type = 'ROWID') then
      dbms_stats.convert_raw_value(rawval, cr);
      return to_char(cnv);
   elsif (type = 'CHAR') then
      dbms_stats.convert_raw_value(rawval, cc);
      return to_char(cc);
   else
      return 'UNKNOWN DATATYPE';
   end if;
end;
/

alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS';
col DATA_TYPE for a20
col TABLE_NAME for a25
col low_val for a25
col high_val for a25
col PARTITION_NAME for a15
col COLUMN_NAME for a25
select a.table_name,
   a.column_name,
   display_raw(a.low_value,b.data_type) as low_val,
   display_raw(a.high_value,b.data_type) as high_val,
   b.data_type
from
   dba_tab_col_statistics a, dba_tab_cols b
where
   a.table_name ='&tabname' and
   a.table_name=b.table_name and
   a.column_name=b.column_name and a.owner='&owner' and a.column_name='&colname'
/

select a.table_name,a.partition_name,
   a.column_name,
   display_raw(a.low_value,b.data_type) as low_val,
   display_raw(a.high_value,b.data_type) as high_val,
   b.data_type
from
   dba_part_col_statistics a, dba_tab_cols b
where
   a.table_name ='&tab_name' and
   a.table_name=b.table_name and
   a.column_name=b.column_name and a.owner='&owner' and a.column_name='&colname' and a.partition_name='&part_name'
/

This is attributed to bug 8318020. You need to install one-off patch for same. This is also mentioned in the article from optimizer devlopment group. I am quoting the same

“It is necessary to install the one off patch for bug 8318020 if you are using copy_table_stats procedure or APPROX_GLOBAL option in 10.2.0.4 (patch 8413548) or in 11.1.0.7 (patch 8411968).”

This is important as CBO while calculating the selectivity uses the low/high value . In this case as the values are old (my case last month values), when you try to query with new month data , CBO will treat it as out of range predicate and can pick suboptimal plans.

e.g You can see below when you enable 10053 trace for the query, how the CBO has estimated a very low selectivity for the index (based on the partitioned column) and thus estimating a very low cost. Note that CBO will not immediately pick incorrect selectivity if it goes out of range as it tries to linearly deduce a value within range of density of that column and 0.5/num_rows. Below selectivity is actually the extreme value i.e 0.5/num_rows.

Column (#1): PART_DATE(DATE)
    AvgLen: 8.00 NDV: 21 Nulls: 0 Density: 0.047619 Min: 2454953 Max: 2454977
  Using prorated density: 8.8550e-09 of col #1 as selectivity of out-of-range value pred
Access Path: index (RangeScan)
    Index: IDX_HIST_TABLE
    resc_io: 5.00  resc_cpu: 34401
    ix_sel: 8.8980e-09  ix_sel_with_filters: 8.8980e-09
		Resp: 1.00  Degree: 1

As of now I have used dbms_stats.set_column_stats to set the values but I would need to apply the fix so as to use copy_table_stats which is much easier to use. Note that you will have to set the stats at partition name and also table level to alter the high value to contain the latest partition upper bound.

Generating Datapump Export Dump with Dumpfile name Containing Current Date and Time

Few days back I got a request from development team to generate hourly export dumps of few schemas.

Following were the requirements:

1. Dumpfile name should contain current date and timestamp information.
2. The generated dumpfile should be moved to a specific location.
3. All users should have read privileges on the export dumpfile.
4. The export dump should be taken on hourly basis.

To accomplish this task I generated a shell script and scheduled it in crontab:

#!/bin/ksh
#Script to Perform Datapump Export Every Hour
################################################################
#Change History
#================
#DATE         AUTHOR                       cHANGE
#---------   -----------------------  -------------------
#23-jUN-2009 SAURABH SOOD        New Script Created
#
#
#
################################################################
export ORACLE_HOME=/u01/app/oracle/product/11.1.0/db
export ORACLE_SID=orcl
export PATH=$PATH:$ORACLE_HOME/bin
expdp username/password@orcl dumpfile=expdp-`date '+%d%m%Y_%H%M%S'`.dmp directory=DATA_PUMP_DIR logfile=expdp-`date '+%d%m%Y_%H%M%S'`.log schemas=SCHEMA_A,SCHEMA_B
mv /tmp/expdp*.dmp /u01/backup/daily_export_orcl/
mv /tmp/expdp*.log /u01/backup/daily_export_orcl/
chmod o+r /s01/backup/daily_export_orcl/*

This script will do the following:


1. Set the ORACLE_HOME,ORACLE_SID and PATH in the environment settings.
2. Taken the datapump export to /tmp location as DATA_PUMP_DIR points to /tmp location.
3. Move the dump and log file to location /u01/backup/daily_export_orcl/
4. Change the permissions of the dumpfile so that any user can read the file.

The main thing here is to set the dumpfile name format. The following syntax is used for that:

DUMPFILE=expdp-`date ‘+%d%m%y_%H%M%S’`.dmp

The dumpfiles will be generated as expdp-23062009_090000.dmp, means that the export dump was taken on 23rd June 2009 at 9AM.

To schedule it on hourly basis crontab was modified as:
$ crontab -e

##############################################################
#Script Used To Create Hourly Exports Of orcl database Schemas
###############################################################
00 09-18 * * 1-6 /u01/backup/daily_export_orcl/export.sh >/dev/null

It will taken the export at 9AM,10AM,11AM,12AM,13PM,14PM,15PM,16PM,17PM,18PM on everyday except sunday.

Cheers!!!

- Saurabh Sood

Link: Best practices for AIX RAC Database on OTN

A new whitepaper has been published on OTN which primarily discusses best practices for AIX 5.2,5.3 and 6.1 for RAC database for avoiding node eviction due to Oprocd.  It also mentions recommended AIX VMO parameters and recommended patches for Oracle RAC.

You can find the article at below location

http://www.oracle.com/technology/products/database/clusterware/pdf/rac_aix_system_stability.pdf

Wordpress 2.8 “Baker” Released

Wordpress version 2.8 has been released. Following link contains video demo of changes in V2.8.

I found option of installing theme directly from Wordpress themes the coolest feature. It is not new for people using the free wordpress account’s  but for people using wordpress on their own domains had to first download the theme from net and then ftp back to their  hosting server (I am using yahoo webhosting which provides only ftp access , no ssh access). 

I do not see any note on how to Upgrade V2.7.1 to V2.8. If you try using the Wordpress Automatic upgrade tool in V2.7.1, it gives a message that ” You are already on latest Release”. Anyways I am looking forward to upgrading it to V2.8 asap as it gives me option of trying out new themes :) . In case anyone find’s any article on how to do it, then do let me know.

Update : – Now Upgrade link has come up on Dashboard ..May be the developers forgot about it initially :-)

- Amit

Cloning database..Just do some Post checks !!

Well I will be covering some points which I believe should be part of post checklist for any cloned database environment. This might not be complete list as it contains point which I have encountered or heard of.

1) Change database Name and Database Id

You should try to change the database name/instance name for UAT/ Cloned environment. In case if there is specific requirement to have the same instance_name/db_name, then atleast you should try changing the database id. If you are using RMAN duplicate command, dbid will be changed automatically. But in case you do not use duplicate command, then dbid will remain same.

DBid change becomes very important if you are using rman catalog database. In case you connect to rman catalog database from new cloned DB (without changing DBID),it would resync the resetlog information in the rman catalog database. Next time you try to take RMAN database backup on production database, you will get following errors

RMAN-06004: ORACLE error from recovery catalog database:
RMAN-20011: target database incarnation is not current in recovery catalog
 

 Following metalink notes discuss how to handle these issues
 
Note 1070453.6 : RMAN: Point-in-Time Recovery of a Backup From Before Last Resetlogs
Note 237232.1 : How to Recover Through a Resetlogs Command Using RMAN


As you see, you will be better off changing Dbid (Database Id) at first place. DBNEWID can be used to change the DB_NAME or DBId or Both

http://download.oracle.com/docs/cd/B19306_01/server.102/b14215/dbnewid.htm

2) Check for database link

Check for database link present in the cloned environment. Ensure that these are select only dblinks and will not perform any DML in production databases. If you find any ,then you can either drop these or recreate them to point to any UAT or simply remove/hash out tnsnames entry corresponding to these hosts. Also check for any hard coded IP address in host column in DBA_DB_LINKS.

3)Remove or hash out any entries in tnsnames.ora pointing to production database and recovery catalog database

This again is to avoid any issues with dblink or RMAN catalog issues. Also note that when you hash the tnsnames.ora you need to place # in front of each line.

Incorrect Correct
#TESTDB10G =
(DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = test10g)(PORT = 1521))
      )
      (CONNECT_DATA =
      (SERVICE_NAME = testdb10g)
    )
 )
#TESTDB10G =
#(DESCRIPTION =
#   (ADDRESS_LIST =
#      (ADDRESS = (PROTOCOL = TCP)(HOST = test10g)(PORT = 1521))
 #     )
#    (CONNECT_DATA =
#     (SERVICE_NAME = testdb10g)
#   )
#)

 

 

 

4) Check cronjobs for oracle database user
If you have copied cron entries for server from production ( as part of database migration activity) , then crosscheck which all jobs need to be enabled for this cloned environment. e.g You can easily disable any cron for RMAN database, archivelog backup.

5)Modify listener.ora file

Modify listener.ora file to include new host entry and port number. This is also quite important as in case you copied it from production server, you could turn off production listener by mistake. Check following metalink note for details

Note 460666.1 – How To Remotely Administer a Listener

6) Check for local_listener and remote_listener parameter

Check for local_listener and remote_listener parameter and modify accordingly. Note that not changing remote_listener parameter can also lead to issues where in your UAT/Test database can get registered with Listener running on Production server.

7)Modify /etc/hosts entries

Modify /etc/hosts entries to remove entries for production database. Also try to use /etc/hosts for resolving host instead of DNS.

8) Add tempfiles to Temporary tablespace

After you clone the environment, tempfiles need to be added to the database.

9) Check for Archivelog mode

Generally archivelog mode is disabled for UAT/Cloned databases. In case your production database is in archivelog mode, ensure that you disable the archiving. 

10) Verify Initialization Parameters

Verify all initialization parameter’s like *_dump_dest locations,utl_file_dir ,sga_max_size , etc.

Disclaimer!

The views expressed on this blog are our own and do not necessarily reflect the views of our Current/Past Employers. The views and opinions expressed by visitors on this blog are theirs solely and may not reflect ours.

Authors

Subscribe To Feed

Enter your email address:

Delivered by FeedBurner

Subscribe in a reader

Feed Subscribers

Recent Comments

RSS AskDba.org Forum

RSS AskDba Non-Oracle Blog

Stats

Meta

Blog Visits

    Wordpress.com stats not installed!
» wp.com stats helper

Spams Caught

Popular Posts

Recent Comments

 

July 2009
M T W T F S S
« Jun    
 12345
6789101112
13141516171819
20212223242526
2728293031  

Tags

Top Posts

    Wordpress.com stats not installed!

Recent Posts

Blogroll

License

Aggregator

Archives