Tuesday, February 20, 2018

The key features in RHEL 7

The key features in RHEL 7
RHEL7 Extras
Introduction of DockerDocker is an open source project that automates the deployment of applications inside Linux Containers, and provides the capability to package an application with its run time dependencies into a container.
Device Hot-plug RemovedWhile RHEL 5/6 has device hot-plug support (udev rule that runs the ifup script for newly created devices), it has been disabled for RHEL 7 since it can result in race conditions when initializing newly found.
No 32 Bit ISO ImageNo 32 bit ISO for download. Red Hat Enterprise Linux 7 will only provide 64-bit ISO's, thus allowing only a 64-bit operating environment. RHEL 7 will not natively support 32-bit hardware.
"MemAvailable" Added to /proc/meminfo 
A new entry to the /proc/meminfo file has been introduced to provide the MemAvailable field. MemAvailable provides an estimate of how much memory is available for starting new applications, without swapping. However, unlike the data provided by the Cache or Free fields, MemAvailable takes into account page cache and also that not all reclaimable memory slabs will be reclaimable due to items being in use.
New Ruby and Python VersionsRed Hat Enterprise Linux 7 provides the latest Ruby version, 2.0.0 and Python 2.7.5.
OpenJDK7 Made DefaultRed Hat Enterprise Linux 7 features OpenJDK7 as the default Java Development Kit (JDK) and Java 7 as the default Java version.
More Powerful NetworkManager
NetworkManager has been significantly enhanced to configure and monitor all the networking features for enterprise class servers and for desktop applications.

For the enterprise data centers, NetworkManager can be used for tasks such as basic networking configuration, network teaming, configuring virtual LANs, bridges, bonds, IPv6, VPNs, assigning interfaces to firewall zones, and others. For desktop servers it can manage wired and wireless networks and VPNs.
Support for 40 Gigabit NICs
Red Hat Enterprise Linux 7 supports 40 Gigabit network interface controllers (NICs) from multiple hardware partners. This provides support for 40 Gigabit Ethernet link speeds enabling faster network communication for applications and systems. Note that the ethtool utility will report interface link speeds up to 40Gb data rates.
No RHN ClassicRHN Classic is not supported in RHEL7. Older versions supported different subscription management methods. Red Hat Subscription Management is the only one used by RHEL 7.
OpenSSH - Multiple Required Authentications
Red Hat Enterprise Linux 7 supports multiple required authentications in SSH protocol version 2 using the AuthenticationMethods option. This option lists one or more comma-separated lists of authentication method names. Successful completion of all the methods in any list is required for authentication to complete.
Minimum Disk Space for Installation of RHEL7Red Hat Enterprise Linux 7 now requires at least 1 GB of disk space to install. However, Red Hat recommends a minimum of 5 GB of disk space for all supported architectures.
Implementation of tmpfs file systemRed Hat Enterprise Linux 7 offers the ability to use /tmp as a mount point for a temporary file storage system (tmpfs).

When enabled, this temporary storage appears as a mounted file system, but stores its content in volatile memory instead of on a persistent storage device. No files in /tmp are stored on the hard drive except when memory is low, in which case swap space is used. This means that the contents of /tmp are not persisted across a reboot.
In-place upgrade, now supportedNow, in-place upgrade from RHEL 6 is supported to RHEL 7 (Reference: https://access.redhat.com/solutions/637583).
Dracut used by AnacondaAnaconda would use "Dracut" to configure disks during installation (GUI) in RHEL 7.x which was earlier performed by utility called "disk druid".
New Logging FrameworkRed Hat Enterprise Linux 7 introduces a new logging daemon, journald, as part of the move to systemd.

journald captures the following types of message for all services:

- syslog messages
- kernel messages
- initial RAM disk and early boot messages
- messages sent to standard output and standard error output.
Samba 4 fully supportedRHEL 7 provides Samba 4, bundle of utilities, features, python bindings which allows communications using SMB1, SMB2 & SMB3 protocols. In RHEL 6.4 and later versions, Samba 4 was provided as Technology Preview.
Non-root user process limitationsIn RHEL 6.x, non-root users were resitricted to a total of 1024 processes per PAM session. In RHEL 7.x, this has been increased to 4096 processes per PAM session by default.
PCS replaces luciThe high availability management agent "luci" has been replaced by "pcs" in RHEL 7. Now, "pcs" can controls pacemaker-based clusters only, not rgmanager-based cluster setups.
Default IO Scheduler"deadline" is now the default IO scheduler in RHEL 7.x (except SATA drives) which was earlier "cfq" by default.
Changes to mount optionsUnlike ext3 and ext4, the XFS file system enables the user_xattr and acl mount options by default. Ext3 and ext4 file systems do not enable these attributes by default.

at No comments:

The major differences between RHEL 7 and 6

The major differences between RHEL 7 and 6
FeaturesRHEL 7RHEL 6
Default File SystemXFSEXT4
Kernel Version3.10.x-x kernel2.6.x-x Kernel
Kernel Code NameMaipoSantiago
General Availability Date of First Major Release2014-06-09 (Kernel Version 3.10.0-123)2010-11-09 (Kernel Version 2.6.32-71)
First Processsystemd (process ID 1)init (process ID 1)
Runlevelrunlevels are called as "targets" as shown below:

runlevel0.target -> poweroff.target
runlevel1.target -> rescue.target
runlevel2.target -> multi-user.target
runlevel3.target -> multi-user.target
runlevel4.target -> multi-user.target
runlevel5.target -> graphical.target
runlevel6.target -> reboot.target

/etc/systemd/system/default.target (this by default is linked to the multi-user target) 		Traditional runlevels defined :

runlevel 0
runlevel 1
runlevel 2
runlevel 3
runlevel 4
runlevel 5
runlevel 6

and the default runlevel would be defined in "/etc/inittab" file.
Host Name Change
In Red Hat Enterprise Linux 7, as part of the move to the new init system (systemd), the hostname variable is defined in "/etc/hostname" file.		In Red Hat Enterprise Linux 6, the hostname variable was defined in the "/etc/sysconfig/network" configuration file.
Change In UID AllocationBy default a new user created would get UIDs assigned starting from 1000.

This could be changed in "/etc/login.defs" file if required.		Default UID assigned to users would start from 500.


This could be changed in "/etc/login.defs" file if required.
Max Supported File Size
Maximum (individual) file size = 500TB
Maximum filesystem size = 500TB

(This maximum file size is only on 64-bit machines. Red Hat Enterprise Linux does not support XFS on 32-bit machines.)		Maximum (individual) file size = 16TB
Maximum filesystem size = 16TB

(This maximum file size is based on a 64-bit machine. On a 32-bit machine, the maximum files size is 8TB.)
File System Check
"xfs_repair"

XFS does not run a file system check at boot time.		"e2fsck"

File system check would gets executed at boot time.
Differences Between xfs_repair & e2fsck
"xfs_repair"

- Inode and inode blockmap (addressing) checks.
- Inode allocation map checks.
- Inode size checks.
- Directory checks.
- Pathname checks.
- Link count checks.
- Freemap checks.
- Super block checks.
"e2fsck"

- Inode, block, and size checks.

- Directory structure checks.

- Directory connectivity checks.

- Reference count checks.

- Group summary info checks.
Difference Between xfs_growfs & resize2fs"xfs_growfs"

xfs_growfs takes mount point as arguments.		"resize2fs"

resize2fs takes logical volume name as arguments.
Change In File System Structure/bin, /sbin, /lib, and /lib64 are now nested under /usr./bin, /sbin, /lib, and /lib64 are usually under /
Boot Loader
GRUB 2
Supports GPT, additional firmware types, including BIOS, EFI and OpenFirmware. Ability to boot on various file systems (xfs, ext4, ntfs, hfs+, raid, etc)		GRUB 0.97
KDUMPRHEL7 supports kdump on large memory based systems up to 3 TBKdump doesn’t work properly with large RAM based systems.
System & Service Manager"Systemd"

systemd is a system and service manager for Linux, and replaces SysV and Upstart used in previous releases of Red Hat Enterprise Linux. systemd is compatible with SysV and Linux Standard Base init scripts.		Upstart
Enable/Start ServiceFor RHEL 7, the systemctl command replaces service and chkconfig.

- Start Service : "systemctl start nfs-server.service".

- Enable Service : To enable the service (example: nfs service ) to start automatically on boot : "systemctl enable nfs-server.service".

Although one can still use the service and chkconfig commands to start/stop and enable/disable services, respectively, they
are not 100% compatible with the RHEL 7 systemctl command 		Using "service" command and "chkconfig" commands.

- Start Service : "service start nfs" OR "/etc/init.d/nfs start"

- Enable Service : To start with specific runlevel : "chkconfig --level 3 5 nfs on"
Default Firewall
"Firewalld (Dynamic Firewall)"

The built-in configuration is located under the "/usr/lib/firewalld" directory. The configuration that you can customize is under the "/etc/firewalld" directory. It is not possible to use Firewalld and Iptables at the same time. But it is still possible to disable Firewalld and use Iptables as before.		Iptables
Network Bonding"Team Driver"

-/etc/sysconfig/network-scripts/ifcfg-team0
- DEVICE=”team0”
- DEVICETYPE=”Team” 		"Bonding"

-/etc/sysconfig/network-scripts/ifcfg-bond0
- DEVICE=”bond0”
Network Time SynchronizationUsing Chrony suite (faster time sync compared with ntpd)Using ntpd
NFSNFS4.1
NFSv2 is no longer supported. Red Hat Enterprise Linux 7 supports NFSv3, NFSv4.0, and NVSv4.1 clients.		NFS4
Cluster Resource ManagerPacemakerRgmanager
Load Balancer TechnologyKeepalived and HAProxyPiranha
Desktop/GUI InterfaceGNOME3 and KDE 4.10GNOME2
Default DatabaseMariaDB is the default implementation of MySQL in Red Hat Enterprise Linux 7MySQL
Managing Temporary FilesRHEL 7 uses systemd-tmpfiles (more structured, and configurable, method to manage tmp files and directories).Using "tmpwatch"

at No comments:

Friday, February 2, 2018

RMAN BACKUP AND RECOVERY SCENARIOS INVOLVING LOSS OF SPFILE

RMAN BACKUP AND RECOVERY SCENARIOS INVOLVING LOSS OF SPFILE

Let us look at some backup and recovery scenarios pertaining to the SPFIILE. The SPFILE is a small but very important file and if we lose the spfile, we cannot start the database even if all the other database files are present and intact.
So in my opinion, it is quite an important thing to consider in our disaster recovery strategy.
Remember best practise is to turn the autobackup of the control file to ON (it is OFF by default).
SPFILE is automatically backed up along with the database control file when any of the following events occur and when the control file autobackup has been enabled in RMAN. .
RMAN> show controlfile autobackup;

RMAN configuration parameters for database with db_unique_name GAVIN are:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
When does the SPFILE gat backed up with AUTOBACKUP now tuned on?
  • After every BACKUP or CREATE CATALOG command
  • After every BACKUP command contained in a RUN block
  • After every structural change to the database occurs like adding a new tablespace, altering the state of a tablespace or datafile (for example, bringing it online), adding a new online redo log, renaming a file

Where does the SPFILE autobackup reside?
RMAN> show controlfile autobackup format ;

RMAN configuration parameters for database with db_unique_name GAVIN are:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
This is the default setting for CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
By default, RMAN will send the autobackup to the flash recovery area (if used).
Let us now remove the default keyword
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';

new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
new RMAN configuration parameters are successfully stored
In this case the SPFILE (and control file) autobackup is located anywhere you specify, but default location will be %ORACLE_HOME%\Database on Windows and $ORACLE_HOME/dbs on UNIX.
RMAN> list backup of spfile;

using target database control file instead of recovery catalog

List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
252     Full    9.73M      DISK        00:00:00     13-JUN-13
        BP Key: 267   Status: AVAILABLE  Compressed: NO  Tag: TAG20130613T144508
        Piece Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/c-2968723077-20130613-00
Let us now specify an actual location on disk instead of just the %F, 
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/backup/%F';

old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/backup/%F';
new RMAN configuration parameters are successfully stored


RMAN> list backup of spfile;

using target database control file instead of recovery catalog

List of Backup Sets
===================


BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
256     Full    9.73M      DISK        00:00:01     13-JUN-13
        BP Key: 271   Status: AVAILABLE  Compressed: NO  Tag: TAG20130613T155004
        Piece Name: /u01/backup/c-2968723077-20130613-01
Note the SPFILE autobackup is now located at /u01/backup and we can see the format of the backup file on disk is no longer OMF.
The DBID (2968723077) and the timestamp (20130613) is now contained in the backup file name c-2968723077-20130613-01
Let us now revert the autobackup back to the FRA.
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;


old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
RMAN configuration parameters are successfully reset to default value

RMAN> show CONTROLFILE AUTOBACKUP FORMAT;

RMAN configuration parameters for database with db_unique_name GAVIN are:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default


RMAN> list backup of spfile;

using target database control file instead of recovery catalog

List of Backup Sets
===================


BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
266     Full    9.73M      DISK        00:00:01     13-JUN-13
        BP Key: 281   Status: AVAILABLE  Compressed: NO  Tag: TAG20130613T162411
        Piece Name: /u01/app/oracle/fast_recovery_area/GAVIN/autobackup/2013_06_13/o1_mf_s_818007851_8vlsdd3n_.bkp
Autobackup is now back to OMF.
Recovery scenarios involving loss of SPFILE
Case 1) Autobackup in Flash (or now called Fast) Recovery Area
The SPFILE has accidently been deleted and now the database is not starting up after a shutdown has been executed.
FRA has been configured.
If FRA has been configured, the backup of the SPFILE is located in the autobackup sub-directory.
For example:
/u01/app/oracle/fast_recovery_area/GAVIN/autobackup/2013_06_10/ o1_mf_s_818007851_8vlsdd3n_.bkp
Note that it is stored in OMF format in this example. The ‘s’ in the string identifies the OMF as a backup related to the SPFILE
To recover from loss of SPFILE if you are NOT using an RMAN Catalog, we need to do two things first :
1) Set the DBID
2) Issue the STARTUP NOMOUNT FORCE command from an RMAN prompt (note – not SQL*PLUS) 
RMAN> SET DBID=2968723077;

executing command: SET DBID

RMAN> startup force nomount;

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initgavin.ora'

starting Oracle instance without parameter file for retrieval of spfile
Oracle instance started

Total System Global Area     158662656 bytes

Fixed Size                     2226456 bytes
Variable Size                104859368 bytes
Database Buffers              46137344 bytes
Redo Buffers                   5439488 bytes
This is a typical error we will face when either restoring the SPFILE or control file from an autobackup.
RMAN>  restore controlfile from autobackup;

Starting restore at 13-JUN-13
using channel ORA_DISK_1

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130613
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130612
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130611
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130610
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130609
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130608
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130607
channel ORA_DISK_1: no AUTOBACKUP in 7 days found
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 06/13/2013 17:15:52
RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece
The reason in this case is that since the spfile is missing and we have mounted the instance using a dummy spfile, the database needs to know where to look to find the autobackup of the spfile .
So now we include the db_file_recovery_dest and db_name parameters in the RESTORE SPFILE command.
RMAN> restore spfile from autobackup db_recovery_file_dest='/u01/backup/fast_recovery_area' db_name='GAVIN';

Starting restore at 13-JUN-13
using channel ORA_DISK_1

recovery area destination: /u01/backup/fast_recovery_area
database name (or database unique name) used for search: GAVIN
channel ORA_DISK_1: AUTOBACKUP /u01/backup/fast_recovery_area/GAVIN/autobackup/2013_06_10/o1_mf_s_818007851_8vlsdd3n_.bkp found in the recovery area
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130613
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /u01/backup/fast_recovery_area/GAVIN/autobackup/2013_06_10/o1_mf_s_818007851_8vlsdd3n_.bkp
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 13-JUN-13
Case 2) Autobackup in non-FRA location – non OMF
RMAN> startup nomount force

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initgavin.ora'

starting Oracle instance without parameter file for retrieval of spfile
Oracle instance started

Total System Global Area     158662656 bytes

Fixed Size                     2226456 bytes
Variable Size                104859368 bytes
Database Buffers              46137344 bytes
Redo Buffers                   5439488 bytes

RMAN> set DBID=2968723077

executing command: SET DBID

RMAN>  run {
2> set CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/backup/%F';
3> restore spfile from autobackup;
4> }

executing command: SET CONTROLFILE AUTOBACKUP FORMAT

Starting restore at 13-JUN-13
using channel ORA_DISK_1

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130613
channel ORA_DISK_1: AUTOBACKUP found: '/u01/backup/c-2968723077-20130613-01
channel ORA_DISK_1: restoring spfile from AUTOBACKUP '/u01/backup/c-2968723077-20130613-01
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 13-JUN-13
Case 3) Total Disaster Recovery ( restore by specifying the backup file name)
In this scenario, the entire database server has crashed and we have lost the entire database files including the SPFILE.
A new server has been provisioned and all the latest backup files have been restored from tape to a location on disk /u01/backup.
In this case the backup files are OMF and we have been able to identify the SPFILE backup file from the ‘s’ keyword in the backup file name
RMAN> restore spfile from '/u01/backup/o1_mf_s_818007851_8vlsdd3n_.bkp';

Starting restore at 13-JUN-13
using channel ORA_DISK_1

channel ORA_DISK_1: restoring spfile from AUTOBACKUP /u01/backup/o1_mf_s_818007851_8vlsdd3n_.bkp
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 13-JUN-13
Case 4) Total Disaster Recovery ( restore by specifying restore from AUTOBACKUP)
In this case, the scenario is the same as the above.
But what happens if we want to use the AUTOBACKUP command to restore the spfile because many backup files have been restored and we are not sure which backup file contains the SPFILE backup.
But what happens in this case when we try to restore the SPFILE from the location where the backup has been restored.
RMAN>  run {
2> set CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/backup/%F';
3> restore spfile from autobackup;
4> }

executing command: SET CONTROLFILE AUTOBACKUP FORMAT

Starting restore at 17-JUN-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=171 device type=DISK

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130617
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130616
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130615
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130614
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130613
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130612
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130611
channel ORA_DISK_1: no AUTOBACKUP in 7 days found
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 06/17/2013 15:29:58
RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece
So to work around this, we tried to fool RMAN by creating the directory structure when using a FRA.
We create the directory structure GAVIN/autobackup/2013_06_17 under the to level location /u01/backup and copy the backup pieces to this location.
-bash-3.2$ cd /u01/backup
-bash-3.2$ mkdir -p GAVIN/autobackup/2013_06_17
-bash-3.2$ mv /u01/backup/o1* /u01/backup/GAVIN/autobackup/2013_06_17
Now we are able to restore the SPFILE from autobackup!
RMAN>  run {
2> restore spfile from autobackup db_recovery_file_dest='/u01/backup/' db_name='GAVIN';
3> }

Starting restore at 17-JUN-13
using channel ORA_DISK_1

recovery area destination: /u01/backup/
database name (or database unique name) used for search: GAVIN
channel ORA_DISK_1: AUTOBACKUP /u01/backup/GAVIN/autobackup/2013_06_17/o1_mf_s_818349778_8vx79lo6_.bkp found in the recovery area
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130617
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /u01/backup/GAVIN/autobackup/2013_06_17/o1_mf_s_818349778_8vx79lo6_.bkp
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 17-JUN-13
at No comments:
RESTORING A ASM BACKUP TO NON-ASM AND RESTORING FROM RAC TO SINGLE-INSTANCE

Scenario:
1) We want to restore the production database which is running on two-node RAC environment in a test non-RAC environment
2) We want to restore the backup residing on ASM disk groups in a non-ASM file system.
Note:
The production database orcl has two instances named orcl1 and orcl2. The database will be restored in the test environment as single instance database named orcl.
The production database database files and FRA are located on the ASM disk +DATA and the file system location on the target server where the files will be restored will be /u01/app/oracle/oradata/orcl. The FRA will be the file system location /u01/app/oracle/flash_recovery_area
The database files will be OMF in this case. By using a different SET NEWNAME command we can if we prefer not restore the files as OMF. For easier manageability I would prefer not to use OMF but in this example OMF is shown.
These are the backupset pieces of the database, control file and archivelog backups which are located on the source server in the ASM disk group +DATA.
 +DATA/orcl/backupset/2013_02_18/nnndf0_tag20130218t093350_0.345.807701631
 +DATA/orcl/backupset/2013_02_18/ncnnf0_tag20130218t093811_0.337.807701893
 +DATA/orcl/backupset/2013_02_18/annnf0_tag20130218t093927_0.325.807701967
On the source server we create a directory on the local file system where we will copy these files out from the ASM disk group. We can also NFS mount a remote file system which has adequate disk space in case the backup pieces are large in size and we do not have adequate space on the local file system.
Since it is 11gR2 Grid Infrastructure, we connect as the grid user who owns the GI software and use the asmcmd cp command to copy files from ASM to file system.
[oracle@kens-racnode1 backup]$ su - grid
Password:
[grid@kens-racnode1 ~]$ . oraenv
ORACLE_SID = [grid] ? +ASM1
The Oracle base has been set to /u01/app/grid

grid@kens-racnode1 ~]$ asmcmd
ASMCMD> cd DATA
ASMCMD> cd ORCL
ASMCMD> cd BACKUPSET
ASMCMD> ls
2013_02_18/
ASMCMD> cd *
ASMCMD> cp nnndf0_tag20130218t093350_0.345.807701631 /u02/app/backup
copying +DATA/ORCL/BACKUPSET/2013_02_18/nnndf0_tag20130218t093350_0.345.807701631 -> /u02/app/backup/nnndf0_tag20130218t093350_0.345.807701631
ASMCMD> cp ncnnf0_tag20130218t093811_0.337.807701893  /u02/app/backup
copying +DATA/ORCL/BACKUPSET/2013_02_18/ncnnf0_tag20130218t093811_0.337.807701893 -> /u02/app/backup/ncnnf0_tag20130218t093811_0.337.807701893
ASMCMD> cp annnf0_tag20130218t093927_0.325.807701967 /u02/app/backup
copying +DATA/ORCL/BACKUPSET/2013_02_18/annnf0_tag20130218t093927_0.325.807701967 -> /u02/app/backup/annnf0_tag20130218t093927_0.325.807701967
Now scp these files from the file system on the source server to a file system on the target server
Copy the password file and init.ora of one of the RAC instances from the source server to target server and make the required changes as we will bring up the database on the target server as a non-RAC single instance database
For example, this is how the init.ora for the single instance database orcl would look like
orcl.__db_cache_size=603979776
orcl.__java_pool_size=50331648
orcl.__large_pool_size=16777216
orcl.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
orcl.__pga_aggregate_target=603979776
orcl.__sga_target=1157627904
orcl.__shared_io_pool_size=0
orcl.__shared_pool_size=469762048
orcl.__streams_pool_size=0
*.audit_file_dest='/u01/app/oracle/admin/orcl/adump'
*.audit_trail='DB'
*.compatible='11.2.0.0.0'
*.control_files='/u01/app/oracle/oradata/orcl/control01.ctl','/u01/app/oracle/oradata/orcl/control02.ctl'
*.db_block_size=8192
*.db_file_name_convert='+DATA/orcl/onlinelog/','/u01/app/oracle/oradata/orcl/'
*.db_create_online_log_dest_1=’ /u01/app/oracle/oradata/'
*.db_domain='mydb.domain'
*.db_name='orcl'
*.db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
*.db_recovery_file_dest_size=4G
*.diagnostic_dest='/u01/app/oracle'
*.log_archive_format='%t_%s_%r.dbf'
*.memory_target=1761607680
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
orcl.undo_tablespace='UNDOTBS1'
On the target server, set the environment and start the database in NOMOUNT mode.
SQL> startup nomount;

ORACLE instance started.
 
Total System Global Area 1753731072 bytes
Fixed Size                  2229144 bytes
Variable Size            1140853864 bytes
Database Buffers          603979776 bytes
Redo Buffers                6668288 bytes
Restore the control file 
RMAN> restore controlfile from '/u01/app/oracle/backup/ncnnf0_tag20130218t093811_0.337.807701893';
 
Starting restore at 19-FEB-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=134 device type=DISK
 
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u01/app/oracle/oradata/orcl/control01.ctl
output file name=/u01/app/oracle/oradata/orcl/control02.ctl
Finished restore at 19-FEB-13
Mount the database and catalog the RMAN backup pieces
RMAN> alter database mount;
 
database mounted
released channel: ORA_DISK_1
 
 
 
RMAN> catalog start with '/u01/app/oracle/backup/';
 
searching for all files that match the pattern /u01/app/oracle/backup/
 
List of Files Unknown to the Database
=====================================
File Name: /u01/app/oracle/backup/ncnnf0_tag20130218t093811_0.337.807701893
File Name: /u01/app/oracle/backup/nnndf0_tag20130218t093350_0.345.807701631
File Name: /u01/app/oracle/backup/annnf0_tag20130218t093927_0.325.807701967
 
Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging done
 
List of Cataloged Files
=======================
File Name: /u01/app/oracle/backup/ncnnf0_tag20130218t093811_0.337.807701893
File Name: /u01/app/oracle/backup/nnndf0_tag20130218t093350_0.345.807701631
File Name: /u01/app/oracle/backup/annnf0_tag20130218t093927_0.325.807701967
This is the RMAN script we will be using :
run {
SET NEWNAME FOR DATABASE   TO  '/u01/app/oracle/oradata/orcl/%b';
SET NEWNAME FOR tempfile  1 TO  '/u01/app/oracle/oradata/orcl/%b';
restore database;
switch datafile all;
switch tempfile all;
}
Execute the same
RMAN> run {
SET NEWNAME FOR DATABASE   TO  '/u01/app/oracle/oradata/orcl/%b';
SET NEWNAME FOR tempfile  1 TO  '/u01/app/oracle/oradata/orcl/%b';
restore database;
switch datafile all;
switch tempfile all;
}
2> 3> 4> 5> 6> 7>
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
Starting restore at 21-FEB-13
using channel ORA_DISK_1
 
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/orcl/system.260.787036171
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/orcl/sysaux.261.787036171
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/orcl/undotbs1.273.787036171
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/orcl/users.266.787036173
channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/orcl/example.262.787036303
channel ORA_DISK_1: restoring datafile 00006 to /u01/app/oracle/oradata/orcl/undotbs2.268.787036459
channel ORA_DISK_1: restoring datafile 00007 to /u01/app/oracle/oradata/orcl/ggs_data.327.798611507
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/backup/nnndf0_tag20130218t093350_0.345.807701631
channel ORA_DISK_1: piece handle=/u01/app/oracle/backup/nnndf0_tag20130218t093350_0.345.807701631 tag=TAG20130218T093350
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
Finished restore at 21-FEB-13
 
datafile 1 switched to datafile copy
input datafile copy RECID=9 STAMP=807958250 file name=/u01/app/oracle/oradata/orcl/system.260.787036171
datafile 2 switched to datafile copy
input datafile copy RECID=10 STAMP=807958250 file name=/u01/app/oracle/oradata/orcl/sysaux.261.787036171
datafile 3 switched to datafile copy
input datafile copy RECID=11 STAMP=807958250 file name=/u01/app/oracle/oradata/orcl/undotbs1.273.787036171
datafile 4 switched to datafile copy
input datafile copy RECID=12 STAMP=807958250 file name=/u01/app/oracle/oradata/orcl/users.266.787036173
datafile 5 switched to datafile copy
input datafile copy RECID=13 STAMP=807958250 file name=/u01/app/oracle/oradata/orcl/example.262.787036303
datafile 6 switched to datafile copy
input datafile copy RECID=14 STAMP=807958250 file name=/u01/app/oracle/oradata/orcl/undotbs2.268.787036459
datafile 7 switched to datafile copy
input datafile copy RECID=15 STAMP=807958250 file name=/u01/app/oracle/oradata/orcl/ggs_data.327.798611507
 
renamed tempfile 1 to /u01/app/oracle/oradata/orcl/temp.263.787036293 in control file
We now need to perform a recovery of the database
This is the script we will use.
Note how we arrive at the sequence number 145
run {
set until sequence 145 thread 1;
recover database;
}
We need to identify the archive log sequence number which we will use in the SET UNTIL command. RMAN will perform recovery of the database until the log sequence number that we need to determine.
Run the RMAN command LIST BACKUP OF ARCHIVELOG.
Note the last or latest archive log backup for each thread (since this backup was taken from a RAC database).
Then among the two archive log sequence numbers, identify the one which has the lower NEXT_SCN number.
That will be the archive log sequence that we need to make a note of.
Remember, we need to add 1 to this number which is then used in the SET UNTIL SEQUENCE clause of the RMAN RECOVER command.
For example, we see that for thread 1, the most recent archive log backup available belongs to log sequence number 144 while for thread 2 the most recent archive log backup available belongs to log sequence number 139 .
Comparing, the NEXT_SCN value for both those sequence numbers, we can see that for sequence 144 , the NEXT_SCN value is lower (736746 compared with 736760).
Thrd  Seq     Low SCN     Low Time  Next SCN   Next Time

  1    144   736706   28-MAR-12 736746  28-MAR-12

....
.....

  2    139   736740   28-MAR-12 736760  28-MAR-12

RMAN> run {
set until sequence 145 thread 1;
recover database;
}
2> 3> 4>
executing command: SET until clause
 
Starting recover at 21-FEB-13
using channel ORA_DISK_1
 
starting media recovery
 
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=144
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=139
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/backup/annnf0_tag20130218t093927_0.325.807701967
channel ORA_DISK_1: piece handle=/u01/app/oracle/backup/annnf0_tag20130218t093927_0.325.807701967 tag=TAG20130218T093927
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
archived log file name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2013_02_21/o1_mf_1_144_8lbwbp3o_.arc thread=1 sequence=144
archived log file name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2013_02_21/o1_mf_2_139_8lbwbp4o_.arc thread=2 sequence=139
channel default: deleting archived log(s)
archived log file name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2013_02_21/o1_mf_1_144_8lbwbp3o_.arc RECID=270 STAMP=807958744
channel default: deleting archived log(s)
archived log file name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2013_02_21/o1_mf_2_139_8lbwbp4o_.arc RECID=269 STAMP=807958742
media recovery complete, elapsed time: 00:00:00
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=140
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=141
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=142
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=143
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/backup/annnf0_tag20130219t103153_0.295.807791515
channel ORA_DISK_1: piece handle=/u01/app/oracle/backup/annnf0_tag20130219t103153_0.295.807791515 tag=TAG20130219T103153
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
channel default: deleting archived log(s)
archived log file name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2013_02_21/o1_mf_2_140_8lbwbt41_.arc RECID=273 STAMP=807958750
channel default: deleting archived log(s)
archived log file name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2013_02_21/o1_mf_2_141_8lbwbt1b_.arc RECID=274 STAMP=807958750
channel default: deleting archived log(s)
archived log file name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2013_02_21/o1_mf_2_142_8lbwbt66_.arc RECID=272 STAMP=807958747
channel default: deleting archived log(s)
archived log file name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2013_02_21/o1_mf_2_143_8lbwbvnc_.arc RECID=271 STAMP=807958747
Finished recover at 21-FEB-13
Open the database with RESETLOGS option 
RMAN> sql 'alter database open resetlogs';
 
sql statement: alter database open resetlogs
Note the location of the online redo log files. We can drop and recreate the online redo log file groups if we wnat to rename them from the OMF format in which they are currently present.
SQL> select member from v$logfile;
 
MEMBER
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/ORCL/onlinelog/o1_mf_2_8lbwd9kq_.log
/u01/app/oracle/oradata/ORCL/onlinelog/o1_mf_3_8lbwdb5n_.log
/u01/app/oracle/oradata/ORCL/onlinelog/o1_mf_1_8lbwd8v5_.log
/u01/app/oracle/oradata/ORCL/onlinelog/o1_mf_4_8lbwdbqr_.log
at No comments:
Subscribe to: Posts (Atom)

  How to Change Instance Type & Security Group of EC2 in AWS By David Taylor Updated April 29, 2023 EC2 stands for Elastic Compute Cloud...