Posts Tagged ‘10gR2’


Cleaning up Tablespaces after OATM has Completed

December 29th, 2008 by Robert McMillen • 1 Comment »

Often after running Oracle Application Tablespace Migration (OATM) you will find that there are still indexes, tables and objects left in some of the old tablespaces.  You want to clean them up so you can delete the old tablespaces and recover the space used by the datafiles.  In the OATM documentation there’s no clear instructions on how to do this since it assumes that OATM will handle it for you.

I recently had this situation and here’s some steps I took to resolve my problem.  This example assumes that I have some tables, indexes and objects left in the old FNDD and FNDX tablespaces.  I wanted to move everything over to one of the new APPS_TS_* tablespaces so I could drop these two old tablespaces and recover the disk space.

Before I got started I found this nice article that outlines options with working on Large Objects (which I had).  The syntax examples are nice.

First I wanted to list all objects left in FNDD so I knew what to move.  I used this script and modifed the Tablespace Name to list all objects (including “free space” segments).

Next I wanted to list any tables left in FNDD so I did this.

select table_name from dba_tables where tablespace_name = ‘FNDD’;

Before you move the table (and any associated LOB segments), you may want to verify you have enough space in the destination tablespace.  You can query dba_segments to find out how many bytes are currently being used for the segments that you are planning to move.  Then verify you have enough free space at the destination.

I found that I had a table with a LOB column and the two associated LOB and LOB Index segments.  I wanted to move the table and both LOB segments to APPS_TS_MEDIA in one group.  The command to move these three objects was:

alter table OWNER.TABLENAME

move tablespace NEWTABLESPACENAME

lob(COLUMNNAME)

store as (tablespace NEWTABLESPACENAME);

The COLUMNNAME is the column name in the table that contains the Large Object.

After the move I verified that there were no other objects left in FNDD using the same script above.  I also did a:

select owner, table_name from dba_tables where tablespace_name = ‘OLDTABLESPACENAME’; to ensure that the table was gone as well.

Now it was time to check FNDX to ensure that any indexes were moved as well.  I modified the script from above to reference FNDX instead of FNDD.  I also ran a select index_name from dba_indexes where tablespace_name = ‘FNDX’;

Once I identifed the indexes I used this command to move them to the new tablespace.

alter index OWNER.INDEXNAME rebuild NEWTABLESPACENAME;

After verifying that everything was gone from FNDX and now in the new tablespaces I was able to drop the FNDD and FNDX tablespaces freeing up lots of needed space.

Several documents on Metalink were also helpful so I’ve listed them here.

  • Summary Note to LOB’s/BLOB’s/CLOB’s/NCLOB’s and BFILEs DOC ID 198160.1
  • How to move LOB Data to another Tablespace  DOC ID 130814.1

Finally, though I didn’t have to use this syntax, here is the command to move just the Large Object (LOBs) segments to a new tablespace while NOT moving the actual table that uses them.

alter table TABLENAME move lob(LOBCOLUMNNAME) store as (tablespace NEWTABLESPACENAME);

And here’s the syntax to just move a Table which doesn’t have any LOB columns.

alter table TABLENAME move tablespace NEWTABLESPACENAME;

That about wraps it up, so good luck on your tablespace cleaning!

1 Comment »

 

Applying RUP6 for Release 12.0.6

December 1st, 2008 by Robert McMillen • No Comments »

I recently applied the latest RUP for Release 12 at a client that is in the midst of a new R12 installation.  I thought I’d recap my experience.

The 12.0.6 patch was released on Friday, November 7th.  We were alerted to it because we ran a fresh version of patchsets.sh during the week and it indicated that everything we had installed was superseded by an unreleased patch.  That got our curiosity going and we checked around Metalink finding that RUP6 was imminent.

The environment was using RedHat Linux 64 bit.  We had recently upgraded the Oracle database from 10.2.0.3 to 10.2.0.4.  They were already on RUP5 and we had recently applied the October CPU and the October Critical Patch Collection patches.  Bottom-line, we were very up-to-date.

Our environment consisted of two Application Servers and a single DB Server.  We were using ASM (10.2.0.4) but not using RAC.  We also had a shared APPL_TOP using OCFS2 for the two Application Servers.

You must start by applying the pre-requisite adpatch, R12 AD.A Delta 6 (Patch 7305520, Doc 736655.1).  It’s about 1.4Mb in size.  After downloading it there was a script to run for adgrants listed in the Patch 7305520 README.  We ran it, the adgrants.sql script, (as sysdba) to grant privileges to selected SYS objects and create PL/SQL profiler objects. We then applied patch 7305520 with adpatch.

Next we downloaded the RUP6 (Patch 6728000, Doc 743368.1).  It’s a big one at 2Gb in size.  It is multi-language but since we had an English-only installation we just downloaded the Linux86 version from Metalink.  It comes packaged in four files:

p6728000_R12_LINUX_1of4.zip  498Mb

p6728000_R12_LINUX_2of4.zip 546Mb

p6728000_R12_LINUX_4of4.zip 503Mb

p6728000_R12_LINUX_4of4.zip 429Mb

Looking at the README, it’s a straight-forward install with adpatch.  However if you have HR implemented there are some post-install steps which I didn’t have to do.  More information about that is in Document 145837.1 on Metalink.

The next step was to install the RUP6 Help Files (Patch 7109200, Doc 743368.1).  This is another multi-language patch where we only had to install the Generic version.  This is a simple adpatch install with no pre/post requirements.

In summary, it was a fairly simple patch exercise for our environment.  Hope yours is the same!

No Comments »

 

New Oracle Database 10g Patch #3 Certified (10.2.0.4)

July 23rd, 2008 by Robert McMillen • No Comments »

Since its introduction in July 2005, 10gR2 has become the database version of choice for many E-Business Suite environments. Originally released as 10.2.0.1 it has been regularly enhanced with new patches to 10.2.0.3. In the last several months, the third patch set was released for 10gR2, raising its current version to 10.2.0.4. In the last week it has been certified with most platforms for the E-Business Suite 11i.

Oracle Database 10gR2 is eligible for Oracle Premier Support through July 2010 and eligible for Extended Support through July 2013. Sustaining support is still listed as “indefinite” in Oracle’s Lifetime Support Policy located at http://www.oracle.com/support/lifetime-support-policy.html.

This new release is certified on all platforms (HPUX, AIX, Linux, Solaris and Windows) in both 32 and 64 bit versions. Keep in mind that this patchset does not provide any additional functionality only applying bug fixes.

Digging into the Metalink documents (Patch# 6810189) it was nice to find that10.2.0.4 includes the January and April 2008 Critical Patch Updates (CPU), which consolidates the effort of doing them. The CPU for July 2008 (Doc# 467881.1) would still need to be applied after this patch. Three issues are noted with this patchset. The one of interest is that parameter “CURSOR_SPACE_FOR_TIME” is being deprecated.

So what are the primary fixes in this 10.2.0.4 patchset? You can check them out in Doc#401436.1 on Metalink (metalink.oracle.com). A quick read show that this new release includes over 3,000 individual bug fixes. In the patchset notes Oracle has identified 14 new issues/bugs that are introduced by this patchset, so be sure to read through them as well.

Stephen Chan has a brief article on the certification of 11i and 10.2.0.4 on his BLOG, so check that out as well. To summarize, it indicates that 10.2.0.4 is certified with E-Business Suite Release 11.5.9.CU2 and higher as well as 11.5.10.CU2 and higher. Real Application Clusters (RAC), Transparent Data Encryption (TDE) and Automated Storage Management (ASM) are also certified. Database Vault is not yet certified.

This patchset includes an update to the Oracle time zone definitions to Version 4 which includes the changes to daylight saving time in the USA in 2007. You can determine which version you have with this query, “SELECT version FROM v$timezone_file;”.

Lastly, while some of the documentation says that this patch includes up to the January 2008 Critical Patch Update (CPU), it actually includes the April 2008 CPU as well (see Metalink Note 555579.1).

Happy Patching!

No Comments »