Oracle Super-cluster important meta-link id's

11.2.0.2, 11.2.0.3, 11.2.0.4 or 12.1.0.1 to 12.1.0.2 Grid Infrastructure and Database Upgrade on Exadata Database Machine running Oracle Solaris and Solaris Supercluster (Doc ID 1908556.1)

Oracle SuperCluster Supported Software Versions - All Hardware Types (Doc ID 1567979.1)
Database Patches Required by Oracle E-Business Suite on Oracle Engineered Systems: Exadata Database Machines and SuperClusters (Doc ID 1392527.1)


SuperCluster Critical Issues (Doc ID 1452277.1)

11.2.0.2, 11.2.0.3, 11.2.0.4 or 12.1.0.1 to 12.1.0.2 Grid Infrastructure and Database Upgrade on Exadata Database Machine running Oracle Linux (Doc ID 1681467.1)

SuperCluster- How to dynamically resize the file system inside a Solaris zone backed by an iSCSI lun. (Doc ID 1921605.1)

How to increase the size of a database zone zoneroot storage pool on Oracle SuperCluster (Doc ID 2482275.1)

SOLUTION

In the global zone of every database domain on Oracle SuperCluster, there is a storage pool called 'zoneroot'. This provides the storage for all local database zones /root & /u01 filesystems. Over time, the available free space in zoneroot may become low e.g.

# zfs get available zoneroot
NAME      PROPERTY   VALUE  SOURCE
zoneroot  available  190M     -

# df -h zoneroot
Filesystem             Size   Used  Available Capacity  Mounted on
zoneroot               313G   313G       190M   100%    /zoneroot

Before attempting to increase the available space in zoneroot, first ensure you have package supercluster/iscsi version 2.1.0.603 (or later) installed e.g.

# pkg list supercluster/iscsi
NAME (PUBLISHER)                                  VERSION                    IFO
system/platform/supercluster/iscsi (exa-family)   0.5.11-2.6.0.1561          i--

If your version of supercluster/iscsi is earlier than 2.1.0.603, then you must update the database domains to the latest Quarterly Full Stack Download Patch (QFSDP).

You can then use the /opt/oracle.supercluster/bin/iscsi-zpool.sh command to increase the size of the zoneroot storage pool e.g.

# cd /opt/oracle.supercluster/bin
# ./iscsi-zpool.sh -h
Usage:
    To create new zpool :   ./iscsi-zpool.sh -p zfs_pool_name -s zfs_pool_size
    To increase zpool size: ./iscsi-zpool.sh -p zfs_pool_name -a size_to_add
    To destroy zpool:       ./iscsi-zpool.sh -p zfs_pool_name -d
NOTE:
    "increase" and "destroy" will only work for zpools that were created by this tool

The following example shows how to add 200G to the zoneroot storage pool.

# ./iscsi-zpool.sh -p zoneroot -a 200G
INFO: Getting the list of active ZFSSA head(s)
INFO: *****-h1-storadm is verified to be a ZFSSA active head
INFO: *****-h2-storadm is verified to be a ZFSSA active head
INFO: The owner of interface ipmp1 is *****-h1-storadm
INFO: Getting name of IB interface on *****-h1-storadm with prefix ipmp_stor
INFO: IB interface with label prefix ipmp_stor is ipmp3
INFO: Getting IP address of IB interface ipmp3 on *****-h1-storadm
INFO: IP address of ZFSSA IB interface ipmp3 is xxx.xxx.28.1
INFO: Verifying *****-h1-storadm owns all the required cluster resources
INFO: The LUN GUID of zpool zoneroot is 600144F09555F81300005C0AA5520009
INFO: The size of this LUN has been increased to: 520.00G

# zfs get available zoneroot
NAME      PROPERTY   VALUE  SOURCE
zoneroot  available  197G   -

# df -h zoneroot
Filesystem             Size   Used  Available Capacity  Mounted on
zoneroot               510G   313G       197G    62%    /zoneroot

Note that although exactly 200G is added to the iSCSI LUN on the ZFS storage appliance, you only see approximately 197G additional free space in the zoneroot filesystem. This is due to filesystem overheads.

Also note that you cannot shrink or reduce the available space in a zoneroot storage pool.

11.2.0.4 Grid Infrastructure and Database Upgrade on Exadata Database Machine running Oracle Solaris and Oracle SuperCluster (Doc ID 1919941.1)

Thanks

Srini

Recover archive gaps in standby database

Using 2 MethodsManually Log Shipping (when the missing logs are very less approx 100)

1. Performing Incremental Backup (When there is a very huge gap)

 METHOD 1:When the logs missing or corrupt is less in number (say below 15), we can ship the logs which were missing in the standby site from the primary site (scp/sftp/ftp) and then we can register the log file in the standby so that the gap can be resolved.This is easy process if you have missing or corrupt logs in lesser number.Otherwise we can use the incremental backup strategy, and perform the recovery at standby site.Lets go through the Archive log Shipping processFirst, Find the archives which are missing by issuing the following command. This would give the gap sequencesSQL> select * from v$archive_gapOr you can use the v$managed_standby view to find where the log apply stuck.SQL> select sequence#,process,status from v$managed_standby; Now, Copy the logs to the standby site from the primary siteUsing the below command$ scp log_file_name_n.arc oracle@standby:/log/file/location/log_file_name_n.arc At standby site, Do the log file registration at the standby site until all the missing log files are registered, Use this below command.SQL> alter database register logfile '/log/file/location/log_file_name_n.arc'; Now apply would take place and your standby will become sync with the primary.METHOD 2 :when the difference is huge (say around 500 logs) the above method is very time consuming and not a proper approach. Else you have to rebuild the standby database from scratch.As an enhancement from 10g, an incremental backup created with BACKUP INCREMENTAL... FROM SCN can be used to refresh the standby database with changes at the primary database since the last SCN at Standby and then managed recovery can resume. Step 1:Use this below command to find the SCN difference, on both the database – Primary DB & Standby DBSQL> select current_scn from v$database;Step 2 :Stop the managed standby apply process:SQL> alter database recover managed standby database cancel;Step 3:Now Shutdown the standby databaseSQL> shut immediateStep 4:On the primary, take an incremental backup from the SCN number where the standby has been stuck:RMAN> run {allocate channel c1 type disk format '/u01/backup/%U.bkp';backup incremental from scn ********* database;}Step 5: On the primary, create a new standby controlfile and copy this file to standby side:SQL> alter database create standby controlfile as '/u01/backup/for_standby.ctl';$ scp * oracle@dataguard : /u01/backupStep 6 :Bring up the Standby instance in nomount mode:SQL> startup nomountStep 7Now, replace the previous controlfile with this new one created at primary , and Bring the database to MOUNT state.(Because, this Primary Side control file has the information of the SCN and we have to perform the recovery using this controlfile)SQL> alter database mount standby database;Step 8 :Open the RMAN prompt and Catalog the backup piece.(Because , RMAN does not know about these files yet; so you must let it know – by a process called cataloging)$ rman target=/RMAN> catalog start with '/u01/backup'; Step 9 :Recover these files:RMAN> recover database;Step 10 :After performing the recovery , exit RMAN and start managed recovery process:SQL> alter database recover managed standby database disconnect from session;Step 11 :Again Check the SCN’s in primary and standby to make sure that both are in SYNc:SQL> select current_scn from v$database;ThanksSrini