Friday, December 12, 2014

RMAN Backups on NFS

There are many options for mounting NFS to be used with various oracle files (binaries, datafiles, OCR). This post shows results of three mount options used and backup time for a single tablespace (size 16GB) using RMAN. The database is a single instance 11.2.0.3 database. Both NFS server and client were on the same network segment connected via a single switch.
NFS server export file content
 more /etc/exports
/opt/backup 192.168.0.66(rw,sync,all_squash,insecure,anonuid=500,anongid=500)
anonuid and anongid represent user id and group id of oracle user on NFS client (server running the DB). no_root_squash has not been used.
Options used for mounting the NFS are
1. mount -t nfs -o rw,hard,rsize=32768,wsize=32768,vers=3,nointr,timeo=600,tcp,nolock 192.168.0.76:/opt/backup /opt/backup (backup time : 06:45)

2. mount -t nfs 192.168.0.76:/opt/backup /opt/backup (backup time : 07:05)

3. mount -t nfs -o rw,hard,rsize=32768,wsize=32768,vers=3,nointr,timeo=600,tcp,nolock,actimeo=0 192.168.0.76:/opt/backup /opt/backup (backup time : 06:35)

In test 1 the mount is without actimeo. Test 2 doesn't specify any mount options and rely on default options. In test 3 the options are similar to test 1 with the exception of actimeo being included.
There's some confusion as to when to use actimeo option. Some documents state it explicitly not to use noac option RMAN but say nothing explicitly about actimeo option but at the same time states it could be used with single instance databases (359515.1) while others explicitly state not to use actimeo with single instance and only required to RAC (1164673.1,762374.1). Neverthless the option 3 was able to complete the backup in roughly same time at option. However use of noac increased the backup time unacceptably long (into hours. Not included in the post).




Below is the IO rate and throughput observed from the emconsole during each test.


Useful metalink note
Howto Optimize NFS Performance with NFS options. [ID 397194.1]
How To Setup DNFS (Direct NFS) On Oracle Release 11.2 [ID 1452614.1]
Step by Step - Configure Direct NFS Client (DNFS) on Linux (11g) [ID 762374.1]
Mount Options for Oracle files when used with NFS on NAS devices [ID 359515.1]
NFS Performance Decline Introduced by Mount Option "actimeo=0" [ID 1164673.1]

Monday, December 1, 2014

Installing Oracle Database 12.1.0.2 on RHEL 7

Oracle has certified 12.1.0.2 on RHEL 7 kernels 3.10.0-54.0.1.el7 or later (1304727.1). The current RHEL 7 available from RedHat site is
cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.0 (Maipo)
and comes with following kernel
uname -r
3.10.0-123.el7.x86_64
which is valid for installing 12.1.0.2. It must be noted only 12.1.0.2 is certified on RHEL 7.

RHEL 7 comes with XFS as the default file system. Although Oracle has its own material praising the XFS this is still not listed as supported file system on 236826.1 - Supported and Recommended File Systems on Linux. It's not yet known if XFS is supported and recommended for Oracle RDBMS data files. In any explicit support statement is with regard to Oracle linux support but not Oracle RDBMS support. On 1529864.1 (which is relevant for RHEL 6) it is explicitly stated database is supported on ext2, ext3 and ext4 file systems, however there's no similar document (Requirements for Installing Oracle Database 12.1 on RHEL7 or OL7 64-bit (x86-64)) available yet. On the other hand going by documents published for RHEL 6 (1601759.1) which states oracle does not certify local file systems and support and certification is up to the OS vendor. Nevertheless it was possible to install a 12.1.0.2 database on XFS local file system without any problem.



On the updated document which list RHEL 7 as an option for 12.1, the compat-libstdc++-33 is missing from the required RPM list. However the installer checks for this package and raise a warning.
compat-libstdc++-33 is not available on RHEL 7 install media. However it could be downloaded as a separate package from the redhat site.

RHEL 7 uses grub version 2. Editing entries in grub is different to that of RHEL6. This will come into play when setting elevator and transparent_hugepages.

In RHEL 7 the concept of runlevels has been replaced with systemd targets. The runlevel command exists but only for compatibility reasons and it is recommended if possible to avoid using the runlevel command. In minimal installation the runlevel command was returning "unknown" instead of expected "N 3" (RHEL 7 installed with Server and GUI didn't have this problem). As a result the runlevel pre-req check could fail on grid infrastructure and database installs.
It was possible to ignore this pre-req failure and continue the installation.

All other preinstallation task setup is similar to earlier versions of RHEL.

Useful metalink notes
Certification Information for Oracle Database on Linux x86-64 [ID 1304727.1]
Supported and Recommended File Systems on Linux [ID 236826.1]

Related Posts
Installing 11.2.0.3 on RHEL 6
Installing 11gR2 (11.2.0.3) GI with Role Separation on RHEL 6
Installing 11gR2 (11.2.0.3) GI with Role Separation on OEL 6
Installing 11gR2 Standalone Server with ASM and Role Separation on RHEL 6
Installing 12c (12.1.0.1) RAC on RHEL 6 with Role Seperation - Clusterware

Saturday, November 29, 2014

RHEL 7 VNC Setup - "Oh no! Somethign has gone wrong"

If RHEL 7 was installed as a minimal install
 yum grouplist
Available environment groups:
   Minimal Install
then setting up vnc by installing tigervnc-server would result in following screen when login with a vncviwer.
Installing X windows did not resolve the issue
yum groupinstall "X Window System"
The minimal installation does not have any GUI related components as such the vnc has no desktop to connect to. Installing KDE desktop
yum groupinstall "kde-desktop"
or the GNOME the default desktop for RHEL7
yum groupinstall GNOME
resolved the issue.

Related Post
Blank VNC Screen