Sunday, November 9, 2014

Oracle Database 11.2.0.3 Install and Setup on RedHat Linux 6 x86_64


In this post we will install a new server with the latest Oracle Database 11gR2 software (as of this writing, it is version 11.2.0.3). In this example, the new machine is called opus.company.com and the new database instance is calledmeta.

Pre-Installation Tasks


Software Download


Start by connecting to My Oracle Support and search for patchset 10404530. There are seven files in this patch. According to the patch README, the files are :
Table 1 Installation Types and Associated Zip Files

Installation Type Zip File Oracle Database (includes Oracle Database and Oracle RAC)
Note: you must download both zip files to install Oracle Database.
p10404530_112030_platform_1of7.zip
p10404530_112030_platform_2of7.zip

Oracle Grid Infrastructure (includes Oracle ASM, Oracle Clusterware, and Oracle Restart)
p10404530_112030_platform_3of7.zip

Oracle Database Client
p10404530_112030_platform_4of7.zip

Oracle Gateways
p10404530_112030_platform_5of7.zip

Oracle Examples
p10404530_112030_platform_6of7.zip

Deinstall
p10404530_112030_platform_7of7.zip

We only need the first two files to install the database. Since that's our goal, then download the first two files and place them into a staging NFS directory. If you don't have one, then go ahead and create one on your NFS server as this is quite handy! (Check Doc ID 1117597.1 for the NFS options).

Note that even if the files come from a patchset, they're actually a full software install. So we don't need to have version 11.2.0.1 or 11.2.0.2 installed before we install version 11.2.0.3.

mkdir /nfs/install/oracle/11.2/x86_64
mv ~/Downloads/p10404530_112030_Linux-x86-64_*.zip /nfs/install/oracle/11.2/x86_64

Create the checksum files. The exact values are listed in the patch digest page.

echo "80A78DF21976A6586FA746B1B05747230B588E34" > /nfs/install/oracle/11.2/x86_64/p10404530_112030_Linux-x86-64_1of7.zip.sha1
echo "A39BED06195681E31FBB0F6D7D393673BA938660" > /nfs/install/oracle/11.2/x86_64/p10404530_112030_Linux-x86-64_2of7.zip.sha1

Verify the SHA1 checksum of both files and compare the results with the ones listed above. The results are not case sensitive.

openssl dgst -sha1 /nfs/install/oracle/11.2/x86_64/p10404530_112030_Linux-x86-64_1of7.zip
openssl dgst -sha1 /nfs/install/oracle/11.2/x86_64/p10404530_112030_Linux-x86-64_2of7.zip

Extract both zip files. This will create a « database » directory.

cd /nfs/install/oracle/11.2/x86_64
unzip p10404530_112030_Linux-x86-64_1of7.zip
unzip p10404530_112030_Linux-x86-64_2of7.zip

Server Setup


Install a Minimal RedHat Enterprise Linux 6 x86_64 machine. I like to create seperate mount points for /u01, /u02and /u03 as specified by the Oracle Flexible Architecture guide. In this blog, we build an RMAN server. It doesn't need quite a lot of disk space, so I'm only using local disk drives. For production databases, the /u02 and /u03mount points are LUNs on a SAN, so I use ASM. But this will be the topic of another blog post :)

/etc/fstab


Once your server is up and running, connect to it and edit the /etc/fstab to build a bigger shared memory. Bigger is better here. But it depends on the amount of memory the machine has. See the « Oracle Database Administrator's Reference 11g Release 2 (11.2) for Linux and UNIX-Based Operating Systems Chapter C - Administering Oracle Database on Linux » guide for more info.

WARNING : don't just copy this fstab line! Just copy the line which starts with « shmfs » and paste it into your own/etc/fstab file. And adjust the size according to the amount of memory in your system. This is just an example.

sudo vi /etc/fstab
tmpfs   /dev/shm   tmpfs   size=4g        0 0

Kernel Configuration


We must change quite a few parameters in the RedHat Linux kernel to keep Oracle happy.


Don't forget that we must reboot to enable those changes. Well, that's not exactly true, as we can force the config with the help of sysctl(8) command. But rebooting now will ensure that our /etc/sysctl.conf file does not contain any errors. Imagine you reboot after the software is installed and it doesn't work. Try tracing the problem down to this file is quite a time-consuming (and frustrating) task.

sudo shutdown -r now

Security Limits


Configure shell limits for the oracle user. Here I set both the grid and the oracle user's limits. In this blog we're not using the grid user. But I like to have all my systems as identical as possible.


Package Installation


We must make sure this new Oracle machine has several RPM installed. For instance, the xorg-x11-xauth rpm is installed because we need the xauth(1) command for the X11 forwarding to work. We also install the xorg-x11-utils package in order to have access to the xdpyinfo(1) command which is used by the Orace Universal Installer (OUI) when it starts. We don't absolutely need this, as you can always ignore the system prerequisites when you start the OUI with the -ignorePrereq flag.

sudo yum -y install xorg-x11-xauth gcc gcc-c++ libaio libaio-devel compat-libstdc++-33 glibc-devel glibc-headers  libstdc++ sysstat binutils make expat compat-libcap1 ksh compat-glibc compat-glibc-headers glibc-devel.i686

Don't be surprised by the number of other packages that will be installed to satisfy dependencies.

Users and Groups


Your organisation's RedHat Kickstart should have created the users and groups required to run Oracle. But if not, then these are the ones you need. Adapt the UID and GID as you see fit. Just make sure they're unique in the entire corporate network.

We first create several groups.

sudo groupadd -g 5000 oinstall
sudo groupadd -g 5001 dba
sudo groupadd -g 5002 sysoper
sudo groupadd -g 5003 asmadmin
sudo groupadd -g 5004 asmdba
sudo groupadd -g 5005 asmoper

Then we create the oracle and grid users. Again, we don't really need the grid user in this post, but let's create it anyway. Who knows, maybe one day we will migrate to ASM?

sudo useradd -u 5001 -g oinstall -G dba,asmadmin,asmdba,asmoper -d /usr/home/grid -s /bin/bash -c
"Oracle Grid Infrastructure Owner" -m grid

sudo useradd -u 5000 -g oinstall -G dba,sysoper,asmdba -d /usr/home/oracle -s /bin/bash -c "Oracle
Database Owner" -m oracle

Edit /etc/profile to handle these new users.

sudo vi /etc/profile

SSH Keys and X11 Forwarding


We will need our new Oracle machine to accept SSH connections from our oracle and grid users. We also need it to forward X11. To do this, edit sshd's configuration. 

WARNING : make sure you understand this file, because you can lock yourself out from the server if you don't!


Restart the daemon so that he understands the changes.

sudo /etc/init.d/sshd restart

Now from your workstation, if you haven't done so already, create a pair of SSH keys and then send the public one to your new Oracle server. 

ssh-keygen -t rsa
scp ~/.ssh/id_rsa.pub opus.company.com:/tmp

Connect to the machine and place your public SSH key into the oracle user's authorized_keys. 

ssh opus.company.com
sudo su - oracle
mkdir ~/.ssh
cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
exit
rm /tmp/id_rsa.pub
exit

Back on your own workstation, allow the new server X11 access to the local machine and then connect to the new machine with the X11 forwarding enabled.

xhost +opus.company.com
ssh -Y -X oracle@opus.company.com

Create Directories


Let's connect to the new machine and create some directories. First the Oracle Inventory.

ssh opus.company.com
sudo mkdir -p /u01/app/oraInventory
sudo chown root:oinstall /u01/app/oraInventory
sudo chmod -R 2775 /u01/app/oraInventory

Then create the Oracle base.

sudo mkdir -p /u01/app/oracle
sudo chown -R oracle:oinstall /u01/app/oracle
sudo chmod -R 775 /u01/app/oracle

Software Installation


Connect to the new machine with X11 enabled.

ssh -YX oracle@opus.company.com

Fix OUI Bug



Because of a bug with the 11.2.0.3 OUI (see Doc ID 1454982.1), we must edit a file before we can start the OUI.

cd /nfs/install/oracle/11.2/x86_64/database/stage/cvu/cv/admin
cp cvu_config cvu_config.backup

Create a Response File


Edit a response file. The easiest way to create a response file is to run the installer in GUI mode and hit the save response file button just before you would normally start the installation. Exit from the GUI OUI and start it at the console prompt using your new response file.

Why bother with a response file? Because IMHO it's easier to follow the installation progress and you skip some problems when you can't have the X11 output (security policies) or you don't have access to an X server (a workstation running Windows on which you can't install Xming for example).

mkdir ~oracle/oui

Run the installer


./runInstaller -showProgress -ignorePrereq -ignoreSysPrereqs -silent -responseFile ~/oui/db.11.2.0.3.rsp

This will start the OUI. Give him a few minutes to get started and you will be notified of the log file at the standard output. So open a second shell window and follow both ouput simultaneously.

ssh opus.company.com
sudo su - oracle
tail -F /u01/app/oraInventory/logs/installActions*.log

A bit latter, you will see this appear in the standard output window :

As a root user, execute the following script(s):
1. /u01/app/oraInventory/orainstRoot.sh
2. /u01/app/oracle/product/11.2.0.3/dbhome_1/root.sh

It's pretty obvious what we now need to do... So from another shell do this :

sudo /u01/app/oraInventory/orainstRoot.sh
sudo /u01/app/oracle/product/11.2.0.3/dbhome_1/root.sh

The last script will display a log file name saying that's where you should look to see what the script just did. So a simple cat(1) will do the trick (because of the time stamp, the file name will be different every time you run the OUI, so use the file name the script told you). 

sudo cat /u01/app/oracle/product/11.2.0.3/dbhome_1/install/root_opus.company.com_2012-07-03_14-21-29.log

Good job, you now have Oracle RDBMS 11.2.0.3 Enterprise Edition installed! :)

Post-Installation Tasks


Backup Root Scripts


Oracle recommends to backup both root.sh scripts. So let's do this.

mkdir ~/backup
cp /u01/app/oraInventory/orainstRoot.sh ~/backup/orainstRoot.sh.`date +%Y%m%d`
cp /u01/app/oracle/product/11.2.0.3/dbhome_1/root.sh ~/backup/root.sh..`date +%Y%m%d`

Configure User Environment


.bash_profile


Let's configure the oracle user's environment. I always like to keep a copy of the environment that has nothing Oracle related configured. It's usefull when we need to run OUI again.

cp ~/.bash_profile ~/.bash_profile.oui

.aliases


Let's create some finger-friendly aliases.


Check to make sure the environment is ok?

source ~/.bash_profile
env | sort
alias

login.sql


This file is read when we start an sqlplus session. I like to change things a bit.

mkdir -p /nfs/home/oracle/scripts/

Database Creation


We're now ready to create a new empty database. In this example, the database will be called « meta ».

for DIR in adump dpdump hdump pfile scripts; do
  sudo mkdir -p /u01/app/oracle/admin/meta/$DIR
done

sudo mkdir -p /u01/oradata /u02/oradata /u03/oradata
sudo chown -R oracle:oinstall /u0*/oradata
sudo chown -R oracle:oinstall /u01/app/oracle/admin

I like to use the Oracle Database Configuration Assistant (DBCA) to setup the SQL scripts. This is because each version of Oracle has a modified DBCA which uses the latest configurations. Instead of using a database creation script I used for Oracle 10gR1 on a new 11gR2, I prefer to generate new scripts via the latest DBCA. I then save those scripts and run them manually. Running them manually gives me the opportunity to learn how it's done. I can also run those scripts manually on another machine without using DBCA again in case this machine doesn't have X11 forwarding enabled. So start DBCA and save the scripts.

sudo su - oracle
$ORACLE_HOME/bin/dbca
This will generate a bunch of files. You can download them from my dropbox account.

Execute the scripts to create the new database.

sudo su - oracle
sh /u01/app/oracle/admin/meta/scripts/meta.sh

Post-Database Installation Tasks


Edit the hosts's /etc/oratab. Do this as yourself, not as the oracle user.

sudo vi /etc/oratab

Configure SQL*Net


Switch to the oracle user and configure SQL*Net.

sudo su - oracle
vi $ORACLE_HOME/network/admin/tnsnames.ora

Configure a basic listener setup. The point here is just to start the listener. Don't forget that we already have alistener.ora template located in the $ORACLE_HOME/network/admin/samples directory.

vi $ORACLE_HOME/network/admin/listener.ora

Start the listener.

lsnrctl start

Next SQL*Net file to configure is the sqlnet.ora file.

vi $ORACLE_HOME/network/admin/sqlnet.ora

And the tnsnames.ora file.

vi $ORACLE_HOME/network/admin/tnsnames.ora

Configure Database Instance


Setup a few configuration parameters. Most of these will prevent errors from showing up in the Oracle Configuration Manager (OCM) inside My Oracle Support.

SQL> alter system set global_names=true scope=both sid='*';

SQL> alter system set smtp_out_server='127.0.0.1' scope=both sid='*';

SQL> alter system set log_checkpoints_to_alert=true scope=both sid='*';

SQL> alter system set os_authent_prefix='' scope=spfile sid='*';

You may have noticed that I use sid='*' for all the above statements. Since we're configuring a single instance database, we don't really need this. But I keep using it because this way it becomes a reflex and so when I'm working on a RAC database, I never forget it.

The following is going to push the undo retention period to way longer than the 900 default value. As it says in the Oracle Database Backup and Recovery User's Guide :
To ensure that the undo information is retained for Flashback Table operations, Oracle suggests setting the UNDO_RETENTION parameter to 86400 seconds (24 hours) or greater for the undo tablespace.
So let's crank this up to 48 hours (i.e. 172800 seconds).

SQL> alter system set undo_retention=172800 scope=both sid='*';

Next we need to boost the flashback retention period higher than the default value of 1440 minutes (i.e. 24 hours). If you have lots of disk space, then go on and set it quite high. Enough to last a long week-end (i.e. four days) or more. In this example, we will set it to 7200 minutes (i.e. 6 days).

SQL> alter system set db_flashback_retention_target=7200 scope=both sid='*';

We are now going to enable block change tracking. That's going to eat up a bit of disk space, but is going to help improve our RMAN backup times. For this to work, our block change tracking file has to be specified or theDB_CREATE_FILE_DEST parameter has to be set. In this example, we will use a file that will be placed in the same directory as the other database files. So we first check what that directory is?

SQL> select file_name from dba_data_files;

FILE_NAME

-------------------------------------------------------

/u02/oradata/meta/system01.dbf

/u02/oradata/meta/sysaux01.dbf

/u02/oradata/meta/undotbs01.dbf
/u02/oradata/meta/users01.dbf

Then create the file in the same directory.

SQL> alter database enable block change tracking using file '/u02/oradata/meta/block.change.tracking.dbf';

Check to see if it's properly configured?

SQL> select filename, status from v$block_change_tracking;

Prevent Account Expiration for Service Accounts


It’s old news, but oracle 11g expires passwords after 180 days and most DBAs don’t
like that. It’s unsecure, but for client-server-applications a locked account is not a single-user-annoyance, it’s a downtime killing SLAs, nerves and – hopefully not – DBA jobs. So just make your DEFAULT user profile less secure by allowing passwords to never expire.

SQL> select * from dba_profiles where resource_type='PASSWORD' order by resource_name;

SQL> alter profile DEFAULT limit PASSWORD_LIFE_TIME UNLIMITED;

Fix Bug 11891463

According to Metalink Doc ID 1361567.1 - Minact-Scn Master-Status: Grec-Scn Messages In Trace File, we need to fix a bug. Otherwise our diag_dest_dir directory will be filled by .trc and .trm files from the MMON process. To prevent that, issue the following command :

SQL> alter system set "_enable_minscn_cr"=false scope=spfile sid='*';

To enable this, we should bounce the instance right now. But since we still have some configuration work to do, let's wait until everything is configured before the instance restart.

Change Audit Parameters


I've already wrote on this topic in a previous blog post, but it was for RedHat 5 and we're on RedHat 6 here. So let's go over this again. We will change all of our databases audit trail to SYSLOG audit trails as it's the Oracle recommended best practices. The idea here is that logs sent to syslog will be placed inside a file to which neither the oracle user nor any of it's groups have write access. So in theory, the DBA and the Linux systems administrator are not the same person. Which means that if the DBA does something fishy, he won't be able to edit the audit trail to cover his or her actions.
We start by changing our /etc/rsyslog.conf file to send local0 messages to the Oracle audit trail. Recall that we are sending all our syslog data to a central syslog server. So we must change both our local rsyslog.conf file and the central syslog server's rsyslog.conf file. Then restart rsyslogd(8) on both machines.

Oracle RDBMS Server Syslog Configuration

We start by the configuration of rsyslogd(8) on the client machine. I say client machine because the Oracle RDBMS server is the syslog client to our central syslog server.


Create the new log file.

sudo mkdir /var/log/oracle
sudo touch /var/log/oracle/audit.log
sudo chmod go-r /var/log/oracle/audit.log

Make sure this new log file is rotated.

sudo vi /etc/logrotate.d/oracle.audit

Verify that the new logroate(8) configuration file is ok?

sudo logrotate -d /etc/logrotate.conf

Restart the rsyslogd(8) daemon to enable the changes.

sudo /etc/init.d/rsyslogd restart

Central Syslog Server Configuration

The central syslog server's configuration is quite similar as the one for the Oracle RDBMS server. In 11gR2 you can send more then one database audit logs to the same audit log file because they all log their DBID so you can differentiate them. Here I send all the the RDBMS audit logs to the same file.


Create the new log file.

sudo mkdir /var/log/oracle
sudo touch /var/log/oracle/audit.log
sudo chmod go-r /var/log/oracle/audit.log

Make sure this new log file is rotated.

sudo vi /etc/logrotate.d/oracle.audit

Verify that the new logroate(8) configuration file is ok?

sudo logrotate -d /etc/logrotate.conf

Restart the rsyslogd(8) daemon to enable the changes.

sudo /etc/init.d/rsyslogd restart

Exit from the central syslog server and go back to the Oracle RDBMS server.

exit
ssh opus.company.com
sudo su - oracle

Configure the database to send audit logs to syslog.

sqlplus '/ as sysdba'
SQL> show parameter audit;
SQL> alter system set audit_trail='OS' scope=spfile sid='*';
SQL> alter system set audit_syslog_level='local0.info' scope=spfile sid='*';
SQL> alter system set audit_sys_operations=true scope=spfile sid='*';

We just changed a lot of configuration parameters, let's make a copy of the spfile just to be safe. The first query will return the path of the spfile. The next one creates a text file copy of it.

SQL> select name, value from v$parameter where name = 'spfile';

SQL> create pfile = '/u01/app/oracle/admin/meta/pfile/pfile.ora' from spfile;

You may have noticed that the alter system audit parameters where all using the « scope=spfile ». That means we have to bounce the instance for the audit parameters to kick in. We run the show parameter audit query again after the restart to make sure our audit parameters are now online.

SQL> shutdown immediate;
SQL> startup;
SQL> show parameter audit;


NAME        TYPE     VALUE
---------------------- -------- --------------------------------
audit_file_dest        string   /u01/app/oracle/admin/meta/adump
audit_sys_operations   boolean TRUE
audit_syslog_level     string LOCAL0.INFO
audit_trail        string OS

Double check the audit trail now?

SQL> exit
tail /var/log/oracle/audit.log

You should get a « permission denied » here because you tried to access the audit trail as the oracle user. Try again as root via sudo.

exit
sudo tail /var/log/oracle/audit.log

Good!

One last thing before we're finished with the audit parameters. As Doc ID 308066.1 clearly explains, we will always get audit logs in our $ORACLE_BASE/admin/$ORACLE_SID/adump directory. So let's make sure it doesn't grow out of proportion by clearing the old audit logs. We do this in the oracle user's crontab.

sudo su - oracle

Finally, I like to use Jefferey M. Hunter's scripts. He's an Oracle ACE which has created management scripts for Oracle. They're interesting, so we install them. Grab a copy of the scripts and extract them to a central Oracle NFS directory.

mkdir -p /nfs/home/oracle/scripts/jeffrey.hunter

cd /nfs/home/oracle/scripts/jeffrey.hunter

wget http://www.idevelopment.info/data/Oracle/DBA_scripts/dba_scripts_archive_Oracle.zip

unzip /nfs/home/oracle/scripts/jeffrey.hunter/dba_scripts_archive_Oracle.zip

Then, create the ORACLE_PATH directory and extract the scripts into it.

mkdir -p $ORACLE_BASE/common/sql
cp /nfs/home/oracle/scripts/jeffrey.hunter/dba_scripts/sql/* $ORACLE_BASE/common/sql

Oracle Configuration Manager

OCM comes built-in with 11gR2, so we will configure it right now. OCM requires Java JRE to be installed. So go to theOracle Java website and download the latest Java SE package and install it (follow the instructions on the Oracle website).

Once you have Java JRE installed, configure OCM. You will need your Oracle Support Contract number and the email you use to connect to My Oracle Support. In this example, the contract number and the email is bogus, as this is just an example...

$ORACLE_HOME/ccr/bin/setupCCR 973649 david.robillard@company.com

This will deploy OCM and print out some info about what it's doing and what are the next steps you need to execute. One of those steps is to configure the daily collection interval. The idea here is to use different collection times for the various machines on your network so that they don't connect to My Oracle Support at the exact same time.

$ORACLE_HOME/ccr/bin/emCCR set collection_interval="FREQ=DAILY; BYHOUR=6; BYMINUTE=20"

We can now check the crontab to see what was installed by the emCCR command?

crontab -l
0,15,30,45 * * * * /u01/app/oracle/product/11.2.0.3/dbhome_1/ccr/bin/emCCR -cron -silent start

For each of the database instances running on the machine, execute the post-installation script.

$ORACLE_HOME/ccr/admin/scripts/installCCRSQL.sh collectconfig -s meta

Test then start a collection.

$ORACLE_HOME/ccr/bin/emCCR test
$ORACLE_HOME/ccr/bin/emCCR collect

Now login to My Oracle Support and check the Systems tab, you should now see your instance listed there.

Startup Scripts


Let's create startup scripts for the listener and the database. We will include those new scripts in the RedHat startup procedure. So, as your own user, create the Oracle listener startup script.

sudo chkconfig oracle.listener on

And then the Oracle RDBMS startup script.

sudo chkconfig oracle.db on

Double check to see if the new scripts are part of the RedHat system's startup configuration?

chkconfig --list | grep oracle

Be sure to test both scripts!

Reboot your server to see if the database and the listener are up without any intervention on your part.

sudo shutdown -r now

Install Latest Patch Set


Doc ID 756671.1 - Oracle Recommended Patches -- Oracle Database
Doc ID 293369.1 - Master Note For OPatch
Doc ID 1348336.1 - 11.2.0.3 Patch Set - Availability and Known Issues
Doc ID 13923374.8 - Bug 13923374 - 11.2.0.3.3 Patch Set Update (PSU)

As of this writing, the latest patch set is 11.2.0.3.3. So download the patch set update. Get the SHA1 checksum also.

echo "34E9FA2627E06791C8D5DC84C2DCA2090F8B5256" > ~/Downloads/p13923374_112030_Linux-x86-64.zip.sha1

Compare both SHA1 values from the downloaded file and the one found on My Oracle Support.

openssl dgst -sha1 ~/Downloads/p13923374_112030_Linux-x86-64.zip
cat ~/Downloads/p13923374_112030_Linux-x86-64.zip.sha1

If the SHA1 values are the same, then move everything to the staging directory.

mv ~/Downloads/p13923374_112030_Linux-x86-64.zip* /nfs/install/oracle/linux/x86_64

Now download the latest OPatch version and check the SHA1 value.

echo "C0B9E5566DDBDFFD3076735F429587EC8CE9EF18" > ~/Downloads/p6880880_112000_Linux-x86-64.zip.sha1
openssl dgst -sha1 ~/Downloads/p6880880_112000_Linux-x86-64.zip

Move the latest OPatch to the staging directory.

mv ~/Downloads/p6880880_112000_Linux-x86-64.zip* /nfs/install/oracle/linux/11.2/x86_64/

Connect to the database server and check the status of the current OPatch.

ssh opus.company.com
sudo su - oracle
$ORACLE_HOME/OPatch/opatch version
OPatch Version: 11.2.0.1.7

Extract the latest OPatch directly into the $ORACLE_HOME.

unzip /nfs/install/oracle/linux/x86_64/p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME

Then check the new version of OPatch.

$ORACLE_HOME/OPatch/opatch version
OPatch Version: 11.2.0.3.0

Good, we moved from version 11.2.0.1.7 to version 11.2.0.3.0. We can now use this new OPatch to install the latest Patch Set Update (PSU). Let's extract this patch.

unzip /nfs/install/oracle/linux/x86_64/p13923374_112030_Linux-x86-64.zip -d /tmp

Change to the patch directory and check if it conflicts with the currently installed patches. There shouldn't be any because we just installed 11.2.

cd /tmp/13923374
opatch prereq CheckConflictAgainstOHWithDetail -ph ./
Prereq "checkConflictAgainstOHWithDetail" passed.

We are now ready to install the patch.Shutdown all instances and listeners running from that Oracle home. Of course, if this database is in production, make sure you let people know that the database will not be availalble for a short period of time.

echo "shutdown immediate;" | sqlplus '/ as sysdba'
lsnrctl stop

We can now apply the new patch.

cd /tmp/13923374
opatch apply

Once patch installation is finished, run the following scripts in each of the database instances running from this Oracle home.

rlwrap sqlplus '/ as sysdba'
SQL> startup;
SQL> @?/rdbms/admin/catbundle.sql psu apply
SQL> exit

Start the listener again.

lsnrctl start

Configure Recovery Manager (RMAN)


If your site has Oracle RDBMS systems, chances are that you already have a Recovery Manager Catalog. Let's assume you have one and configure the new database with it.

sudo su - oracle
rman target sys@meta catalog rman@rman

RMAN> register database

RMAN> configure retention policy to recovery window of 10 days;
RMAN> configure backup optimization on;
RMAN> configure controlfile autobackup on;
RMAN> configure device type disk parallelism 2 backup type to copy;
RMAN> configure compression algorithm 'basic' as of release 'default' optimize for load false;
RMAN> configure archivelog deletion policy to backed up 2 times to disk;
RMAN> configure snapshot controlfile name to '/u01/app/oracle/admin/oprod/controlfile/snapshot_cf.rman';
RMAN> show all;

RMAN configuration parameters for database with db_unique_name META are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 10 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO COPY;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'basic' AS OF RELEASE 'default' OPTIMIZE FOR LOAD FALSE;
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/admin/meta/controlfile/snapshot_cf.rman'; # default

Once the database is configured, we can already create a first backup. This example uses Incrementally Updated Backups. See these Document ID for more info :

Doc ID 360416.1 - Oracle10g / 11g - Getting Started with Recovery Manager (RMAN)
Doc ID 351455.1 - Oracle Suggested Strategy & Backup Retention
Doc ID 303861.1 - Incrementally Updated Backup In 10G
Oracle Database Backup and Recovery User's Guide 11g Release 2 (11.2) Chapter 9 - Backing Up the Database - Making and Updating Incremental Backups
Oracle Database Backup and Recovery Reference 11g Release 2 (11.2) - BACKUP
Oracle Database Backup and Recovery Reference 11g Release 2 (11.2) - Example 9-10 Advanced Incremental Update Script

Let's create a few directories before we can perform a backup. A good procedure is to create the backup directory on an NFS share and not be local to the machine. This way if ever there was a problem with the database server, the data on the NFS share. Or if the NFS server or NAS system has a problem, you still have the database intact. The idea is not to put all your eggs in the same basket ;)

So let's assume that we already have a NAS share which is automounted on the database server on/backup/oracle, we could run this to create an incrementally updated backup of the database :

RMAN> run {
2> sql "create pfile=''/backup/oracle/meta/pfile.txt'' from spfile";
3> sql "alter database backup controlfile to trace as ''/backup/oracle/meta/controlfile.before.backup.txt'' reuse";
4> recover copy of database with tag DAILY until time 'sysdate - 1';
5> backup as compressed backupset incremental level 1 for recover of copy with tag DAILY database;
6> backup as compressed backupset archivelog all delete all input;
7> sql "alter database backup controlfile to trace as ''/backup/oracle/meta/controlfile.after.backup.txt'' reuse";
8> backup recovery area to destination '/backup/oracle/rman/meta';
9> crosscheck backup;
10> delete noprompt obsolete;
11> }

Once in RMAN, we can also check the database schema :

RMAN> report schema;

Report of database schema for database with db_unique_name META

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    612      SYSTEM               ***     /u02/oradata/meta/system01.dbf
2    666      SYSAUX               ***     /u02/oradata/meta/sysaux01.dbf
3    393      UNDOTBS1             ***     /u02/oradata/meta/undotbs01.dbf
4    5        USERS                ***     /u02/oradata/meta/users01.dbf
5    14       RMAN                 ***     /u02/oradata/meta/rman01.dbf

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    60       TEMP                 32767       /u02/oradata/meta/temp01.dbf

So that's it for now.
Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)