Showing posts with label Migration. Show all posts
Showing posts with label Migration. Show all posts

Migrating an Oracle Database From Solaris to Linux

on Tuesday, 5 June 2012

Migrating an Oracle Database From Solaris to Linux


There has been a general move over the last couple of years for a number of our clients to migrate their Oracle environments off Solaris/SPARC and onto Linux/x86, normally Red Hat Linux. The reasons typically given are cost savings and performance improvements. I had assumed that the takeover of Sun by Oracle would slow these migrations down as people waited to see the roadmap from Oracle but so far there's been no indication of that.

The migration process is reasonably well described in the Oracle documentation (Transporting Tablespaces Between Databases), but I'll give a summary of the process here so you can see what's involved, we're using the 'power of RMAN' (I think I may need to trademark that!) to do the heavy lifting.

1: Check that platforms are compatible, run this query on the database you want to migrate from and it will list the platforms you can migrate to:

select * from V$TRANSPORTABLE_PLATFORM;

check the value of ENDIAN_FORMAT, if you are migrating from one format to another you are going to need to convert your database files, so for example going from Solaris to Linux you will need to convert.

2: You can only migrate tablespaces to a database which uses the same character set and national charcter set, so check if you are migrating to an existing database or make sure to use the same values if you are building a new database

3: Assuming you are good to go you need to determine which tablespaces hold the data you want to transport and then double check that the list is self-contained, execute this PL/SQL procedure to check the tablespaces you plan to migrate:

execute DBMS_TTS.TRANSPORT_SET_CHECK('tspace1','tspace2', true);

Then query the output table:

select * from TRANSPORT_SET_VIOLATIONS;

Ideally this will come up with no rows, in which case your list of tablespaces is self-contained and you are ready to proceeed, if not then the quuery results will show problems you have, for example:

VIOLATIONS
--------------------------------------------------------------------------------
Index TESTUSER.INDEX1 in tablespace TSPACE1 points to table TESTUSER.Table2 in tablespace TSPACE3

In this case you could move that table from TSPACE3 into one of the tablespaces you are migrating, include TSPACE3 in your tablespace list, drop or move the index, whichever action is most appropriate. Re-run the PL/SQL and recheck the results - rinse and repeat until you are clean to go:

exec DBMS_TTS.TRANSPORT_SET_CHECK('tspace1','tspace2', true);

select * from TRANSPORT_SET_VIOLATIONS;

no rows selected

4: Generate the transportable tablespace set; you need to export the metadata and then copy the datafiles and if you want the views, PL/SQL etc. for the schemas that are included in the tablespaces then you will need to export those too:

alter tablespace TSPACE1 read only;
alter tablespace TSPACE2 read only;



exp file=tts.dmp transport_tablespace=Y tablespaces=TSPACE1,TSPACE2

cp /data/tspace1_01.dbf /migrate

cp /data/tspace1_02.dbf /migrate

cp /data/tspace2_01.dbf /migrate

cp /data/tspace2_02.dbf /migrate

exp file=testuser.dmp log=testuser.log rows=N owner=TESTUSER



alter tablespace TSPACE1 read write;
alter tablespace TSPACE2 read write;



5: copy the metadata export, datafiles and any schema exports to the new host

6: convert the datafiles to new platform format using RMAN, in this example we will put the converted datafiles into an ASM instance:

rman
connect target /
convert datafile
'/migrate/tspace1_01.dbf',
'/migrate/tspace1_02.dbf',

'/migrate/tspace2_01.dbf',

'/migrate/tspace2_02.dbf'

from platform 'Solaris[tm] OE (64-bit)'
format '+DATA1'
parallelism 4;

7: plug the tablespace into the target database, check the ASM instance to get the names of the converted datafiles:



imp file=tts.dmp log=tts.log transport_tablespace=Y datafiles= \
'+DATA1/db1_server1/datafile/TSPACE1.279.699544583',\
'+DATA1/db1_server1/datafile/TSPACE1.299.699544581',\
'+DATA1/db1_server1/datafile/TSPACE2.300.699544581',\
'+DATA1/db1_server1/datafile/TSPACE2.301.699544581'



8: set the imported tablespaces to read write:

alter tablespace TSPACE1 read write;
alter tablespace TSPACE2 read write;



9: import procs, triggers etc

imp file=testuser.dmp log=testuser.log rows=N ignore=Y full=Y

10: unlock the schema object statistics as they will all be 'locked' after the migration - this caught me out the first time!:


exec DBMS_STATS.UNLOCK_SCHEMA_STATS('testuser');


11: Take a backup of your newly migrated tablespaces

Oracle Database Platform Migration From CentOS (RHEL) Linux 4.5 to Solaris 10 Contents

on


Oracle Database Platform Migration From CentOS (RHEL) Linux 4.5 to Solaris 10
Contents

Pre-migration Steps
Verify TDB support for target platform
Target system software version
Identify external files and directories
Start the database in READ ONLY mode
Verify the database is ready for migration
Prepare database on target server
Migration Steps
Run RMAN CONVERT DATABASE on Target
Move necessary files to target system
Complete the migration
Post Migration Steps

Pre-migration Steps
Verify TDB support for target platform

Before attempting a platform migration with TDB, verify the target platform is supported for TDB by your source platform. Query the view V$DB_TRANSPORTABLE_PLATFORM for the target platform name. Here is example output from a database on ‘Linux IA (32-bit)’ platform.
Logon to source database
SQL> connect / as sysdba
SQL> select platform_name from v$db_transportable_platform;
PLATFORM_NAME
---------------------------------------------
Microsoft Windows IA (32-bit)
Linux IA (32-bit)
HP Tru64 UNIX
Linux IA (64-bit)
HP Open VMS
Microsoft Windows IA (64-bit)
Linux 64-bit for AMD
Microsoft Windows 64-bit for AMD
Solaris Operating System (x86)
9 rows selected.
If the target platform does not appear in the output from V$DB_TRANSPORTABLE_PLATFORM, then the database cannot be migrated using TDB.

Target system software version

The target system must have the same Oracle software version and patches installed as the source system. This includes the same patch set version, critical patch updates, and patch set exceptions. The software should be used to create a sample database to ensure it is operational. Refer to Oracle Universal Installer and OPatch User’s Guide [4], for details on using the OPatch utility to determine the currently installed versions and patches.

Identify external files and directories

Identify directories external to the source database that will need to be created on the target system, and external table files and BFILEs that will need to be moved to the target system.
The PL/SQL function CHECK_EXTERNAL identifies external tables, directories, and BFILEs that need to be moved during the migration so the target database is complete when the process is finished.
SQL> set serveroutput on
SQL> declare x boolean;
begin x := dbms_tdb.check_external; end;
The following directories exist in the database:
SYS.DATA_PUMP_DIR, SYS.ADMIN_DIR, SYS.WORK_DIR, SYS.DEV_UIMAGES,
SYS.STAG_UIMAGES, SYS.PROD_UIMAGES, SYS.PRJ_KEY, SYS.testuser2_UPLOADS
PL/SQL procedure successfully completed.

    Directory objects must be created on the target system. Query DBA_DIRECTORIES on the source database to determine the filesystem locations that must exist on the target system for the directory objects to be usable.

SQL> select directory_path from dba_directories;
DIRECTORY_PATH
--------------------------------------------------------------------------------
/ade/aime_10.2_lnx_push/oracle/md/admin
/u02/oracle/apexdb/admin/apex/dpdump/
/var/www/testuser.appshosting.com/web/budevser.com/UIMAGES
/ade/aime_10.2_lnx_push/oracle/work
/var/www/testuser.appshosting.com/web/bustagser.com/UIMAGES
/var/www/testuser.appshosting.com/web/testuser.com/UIMAGES
/usr/bin/
/var/www/testuser2.appshosting.com/web/uploads
8 rows selected.
Ensure that each directory listed in the view DBA_DIRECTORIES points to a valid filesystem directory, or ASM disk group or directory on the target system. Accomplish this by either creating each directory on the target system, or altering the DIRECTORY_PATH to a valid directory when the target database is open after the migration process. For example:
$ mkdir –p /extdata/orcl $ mkdir –p /u01/app/oracle/admin/orcl/tts $ mkdir –p /u01/app/oracle/admin/orcl/dpdump/
• Identify external table files that will need to be transferred to the target system when indicated in a later step. Do not add additional external tables to the source database until the platform migration is complete.
To identify external table files, run the following query
SQL> select directory_path||‘/’||location External_file_path from dba_directories a, dba_external_locations b where a.directory_name=b.directory_name;

Identify BFILE files that will need to be transferred to the target system when indicated in a later step. Do not initialize additional BFILEs in the source database until the platform migration is complete. To identify directories that contain BFILEs, run the following SQL script from the appendix:
SQL> @tdb_get_bfile_dirs.sql
The following directories contain external files for BFILE columns
Copy the files within these directories to the same path on the target system
If it is necessary to list all BFILE external files, then run the script tdb_get_bfiles.sql script from the appendix.

Start the database in READ ONLY mode

TDB requires that the source database be opened in READ ONLY mode. The source database will be unavailable from this step forward.
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database open read only;

Verify the database is ready for migration

To ensure the database is ready for migration, run the DBMS_TDB.CHECK_DB function to verify that the database can be migrated to the target platform and that the database is in the proper state to be migrated.
SQL> set serveroutput on
SQL> declare
retcode boolean;
begin
retcode := dbms_tdb.check_db(‘Solaris Operating System (x86)', dbms_tdb.skip_none);
end;
PL/SQL procedure successfully completed.

Any condition reported by CHECK_DB must be resolved before TDB can proceed. For details of the checks performed by DBMS_TDB.CHECK_DB,

Prepare database on target server

# groupadd dba
# groupadd oinstall
# Useradd -g oinstall oracle
# mkdir /d01
# mkdir /export/home/oracle
# chown oracle:oinstall /export/home/oracle
Modify /etc/auto_home to add a new entry 'oraapex localhost:/export/home/oraapex'
Set password for oraapex to '0raapex!'
Set shell in /etc/passwd file to /usr/bin/bash
# vi /etc/group
  Add oraapex user to dba group

Install RDBMS 10.2.0.1 into /d01/oracle/apexdb/10.2.0
Run root scripts
$ vi $HOME/testdb.env
   Add environment variables for testdb database on ahweb
$ cd
$ . testdb.env
$ mkdir $ORACLE_HOME/admin $ORACLE_HOME/admin/testdb
$ cd $ORACLE_HOME/admin/testdb
$ mkdir bdump udump cdump adump

Add listener and tns entry
$ $ORACLE_HOME/bin/netca
  Add LSNR1 listener and testdb tns entry

Migration Steps
Run RMAN CONVERT DATABASE on Target

When performing a target system conversion, RMAN creates an RMAN script to be used on the target system to convert all datafiles.
Login to source server
# mkdir /tmp/convertdb
# chmod 777 /tmp/convertdb
# su – oraapex
$ . testdb.env
$ rman
RMAN> connect target /
RMAN> configure device type disk parallelism 1;
RMAN> show all;
RMAN> convert database on target platform
convert script ‘/tmp/convertdb/convert_testdb.rman’
transport script '/tmp/convertdb/transport_testdb.sql'
new database 'testdb'
format '/tmp/convertdb/testdb%U'
db_file_name_convert '/u02/oracle/apexdata/apex','/d01/oracle/apexdata';
RMAN> exit
$ sqlplus /nolog
SQL> connect / as sysdba
SQL> shutdown;

Run SQL script /tmp/convertdb/transport_testdb.sql on the target platform to create database
Edit init.ora file /tmp/convertdb/init_testdb00j60sqd_1_0.ora. This PFILE will be used to create the database on the target platform
Run RMAN script /tmp/convertdb/convert_testdb.rman on target platform to convert datafiles
To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on the target platform
To change the internal database identifier, use DBNEWID Utility
Finished backup at 13-JAN-08

The CONVERT DATABASE command specified in the example will create a convert script named /tmp/convert_mydb.rman, a transport script named /tmp/transport_mydb.sql, and a PFILE named /tmp/init_mydb.ora. See the appendix for example target system conversion output.

Move necessary files to target system

Once the CONVERT DATABASE command is complete transfer /tmp/convertdb directory and files to the target system using operating system utilities (e.g. ftp, scp).
Login to target ahweb.appshosting.com as oraapex
$ scp -pr root@targetserver.appshosting.com:/tmp/convertdb $HOME/
In addition to the common files listed above, if performing a target system conversion, the following files must be transferred to the target system:

    Unconverted datafiles – should be placed in a staging area. The convert RMAN script will read datafiles from this location and write the converted datafiles to their final location.

Login to target server ahweb.appshosting.com as oraapex
$ mkdir /d01/oracle /d01/oracle/apexdata
$ scp –pr root@targetserver.appshosting.com:/u02/oracle/apexdata/apex /export/home/oraapex/apexdata/

To reduce overall outage time, instead of transferring the unconverted datafiles using a command like FTP, NFS mount the source system’s datafile location on the target system. During the conversion process, this will allow the datafiles to be read from their original source location and written in the converted format to their final target location. See step 6 for details on modifying the convert RMAN script.
# mount source:/u01/oradata/PROD/datafile /mnt/mydb
• Convert RMAN script

Complete the migration

The final steps required to complete the migration differ slightly depending on the type of conversion chosen – source system or target system.
Review the PFILE
For all migrations, the PFILE created on the source system and transferred to the target system must be reviewed to ensure that directory paths and file locations are accurate for the target system. The parameters that need to be changed are grouped together at the top of the PFILE.
$ cp $HOME/convertdb/*.ora $ORACLE_HOME/dbs/
$ cd $ORACLE_HOME/dbs
$ mv init_testdb00j60sqd_1_0.ora inittestdb.ora
$ vi inittestdb.ora
   To modify parameters for target database on ahweb.appshosting.com
Target system conversion only – review and run the Convert RMAN script
When performing a target system conversion, the datafiles are moved to the target system in the source system format. The convert RMAN script must be reviewed to ensure the file locations are accurate. The following should be reviewed and changed as necessary:

    The filename specified for CONVERT FILENAME should be the unconverted datafile that was transferred from the source system. If instead of transferring the unconverted datafiles the source datafile
    location was NFS mounted to the target system, then specify the location of the NFS mount.
    The FORMAT spec should indicate the final location of the converted datafile. This final location must match the location specified in the transport SQL script. See the next section for more detail.

$ su – oraapex
$ vi $HOME/convertdb/convert_testdb.rman
   Replace ‘/u02/oracle/apexdata/apex’ to ‘/export/home/oraapex/apexdata’
$ sqlplus /nolog
SQL> connect / as sysdba
SQL> startup mount;
After the convert RMAN script is reviewed and edited as necessary, run the script:
RMAN> connect target /
RMAN> @convert_testdb.rman
RMAN> exit
SQL> shutdown
Review and run the Transport SQL script
For all migrations, the final step to complete is to run the transport SQL script that was created by RMAN’s CONVERT DATABASE command. The script must first be edited on the target system to ensure that locations for all referenced files are correct. The following sections should be reviewed for accuracy and changed as necessary:

    Ensure that the PFILE referenced in the STARTUP command in the transport script point to the location where the PFILE was placed when it was transferred from the source system.
    Ensure the DATAFILE locations in the CREATE CONTROLFILE statement refer to the final location of the converted datafiles on the target system. If it is a target system, conversion, then the DATAFILE locations should match where the CONVERT DATAFILE placed its output.
    Ensure that the LOGFILE locations in the CREATE CONTROLFILE statement refer to the desired location of the online logfiles on the target system. If no location is specified then Oracle-Managed Files will be used to name and place the files.
    Ensure the TEMPFILE location(s), if specified, are accurate for new tempfiles being created for temporary tablespaces.

After the transport SQL script has been reviewed and edited as necessary, run the script:
SQL> connect / as sysdba;
SQL> @transport_testdb.sql
When the transport SQL script is complete, review the output for errors.

Post Migration Steps

Directory objects must be created on the target system. Query DBA_DIRECTORIES on the target database to determine the filesystem locations that must exist for the directory objects to be usable.
$ mkdir $ORACLE_HOME/admin/dpdump
SQL> select directory_path from dba_directories;
DIRECTORY_PATH
--------------------------------------------------------------------------------
/ade/aime_10.2_lnx_push/oracle/md/admin
/u02/oracle/apexdb/admin/apex/dpdump/
/var/www/testuser.appshosting.com/web/budevser.com/UIMAGES
/ade/aime_10.2_lnx_push/oracle/work
/var/www/testuser.appshosting.com/web/bustagser.com/UIMAGES
/var/www/testuser.appshosting.com/web/testuser.com/UIMAGES
/usr/bin/
/var/www/testuser2.appshosting.com/web/uploads
8 rows selected.
SQL> update dba_directories set directory_path=’/d01/oracle/apexdb/admin/testdb/dpdump’
           where directory_path=’/u02/oracle/apexdb/admin/apex/dpdump’;

Copy web upload directories from source to target server
# cp -pr root@<sourceServer>:/var/www/*/web/uploads  /var/www/*/web/