Stop password for user accounts expiring on Exadata

Depending on how the Oracle Exadata Machine was setup, the password for user accounts can expire thus requiring the password to be changed.

This has the knock on effect of the crontab not accessible and more importantly jobs do not run:

[oracle@v1ex1dbadm01 ~]$ crontab -l

Authentication token is no longer valid; new one required
You (oracle) are not allowed to access to (crontab) because of pam configuration.
[oracle@v1ex1dbadm01 ~]$

You can check the pam configuration for the password expiry as shown below as the root user:

[root@v1ex1dbadm01 ~]# chage -l oracle
Last password change : Dec 11, 2017
Password expires : Mar 11, 2018
Password inactive : never
Account expires : never
Minimum number of days between password change : 1
Maximum number of days between password change : 90
Number of days of warning before password expires : 7
[root@v1ex1dbadm01 ~]#

We can see the password expired on the 11th March 2018 and hence why crontab jobs are not running since then.

To change, so the password doesn’t expiry, use chage as shown below:

[root@v1ex1dbadm01 ~]# chage -d 9999 -E -1 -m 0 -M -1 oracle

The manual page for chage explains the switches:

-d, --lastday LAST_DAY
 Set the number of days since January 1st, 1970 when the password was last changed. The date may also be expressed in the format YYYY-MM-DD (or the format more commonly used in your area). If the LAST_DAY is set to 0 the user is forced to change his password on the next log on.

-E, --expiredate EXPIRE_DATE
 Set the date or number of days since January 1, 1970 on which the user´s account will no longer be accessible. The date may also be expressed in the format YYYY-MM-DD (or the format more commonly used in your area). A user whose account is locked must contact the system administrator before being able to use the system again.

Passing the number -1 as the EXPIRE_DATE will remove an account expiration date.

-m, --mindays MIN_DAYS
 Set the minimum number of days between password changes to MIN_DAYS. A value of zero for this field indicates that the user may change his/her password at any time.

-M, --maxdays MAX_DAYS
 Set the maximum number of days during which a password is valid. When MAX_DAYS plus LAST_DAY is less than the current day, the user will be required to change his/her password before being able to use his/her account. This occurrence can be planned for in advance by use of the -W option, which provides the user with advance warning.

Passing the number -1 as MAX_DAYS will remove checking a password´s validity.

Now, when re-checking the password expiry, you can see it’s changed to ‘never‘:

[root@v1ex1dbadm01 ~]# chage -l oracle
Last password change : May 01, 2008
Password expires : never
Password inactive : never
Account expires : never
Minimum number of days between password change : 0
Maximum number of days between password change : -1
Number of days of warning before password expires : 7
[root@v1ex1dbadm01 ~]#

And we didn’t need to change the password for the user and the crontab job work again 🙂

This doesn’t just apply to Exadata but to Linux.

See Related MOS Note:
Expiry of user accounts on Oracle Linux 5 (Doc ID 2327855.1)

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

Advertisements

Oracle Exadata Smart Flash Logging

What is Exadata Smart Flash Logging?

In an OLTP environment, it is crucial to have fast response times to redo log writes i.e. low latency.  When multiplexing redo logs for high availability i.e. to protect against hardware failure, redo log writes are only acknowledge when redo is written to all redo log members i.e when the slowest disk completes the write.  By this nature, whenever a disk slows down even if for a moment it can have impact on redo log performance and throughput.

Flash alone can’t resolve this issue as flash can also momentarily slow down due to issue in erase cycles or wear leveling and remember the acknowledgement is only given when the redo is written to all redo log members.

Exadata Smart Flash Logging, is the feature that writes to both hard disk and flash with the acknowledgement given as soon as either completes the write, thus improving response time and throughput.  So if a write is slow to hard disk the flash will give a quicker acknowledgement but when flash is experiencing a slow down due to erase cycles or wear leveling then the hard disk will acknowledge, smoothing out response times.

The Exadata Smart Flash Cache isn’t permanent but a temporary store to provide fast response times by storing redo until it’s safely written to disk.

No changes are required to redo log configuration and is transparent to database and recovery.

How to enable Smart Flash Logging?

It’s enabled out the box or for older systems it’s enabled when applying cell patch version 11.2.2.4 and also requires Database 11.2.0.2 Bundle Patch 11 or higher.

How to disable Smart Flash Logging?

This shouldn’t be done unless instructed to do so by Oracle Support or Development.

How much flash is used by Smart Flash Logging?

By default just 512Mb is used per cell, which should be sufficient for most situations.   It’s a small investment for huge performance benefit.  Statistics record the number of successful write and unsuccessful writes due to the temporary space filled.  In which case the size may need to be increased.  Also I/O Resource Manager (IORM) can be used to disable Smart Flash Logging for none critical databases.

Do standby redo logs use Smart Flash Logging?

Yes, standby redo logs benefit from Smart Flash Logging just as redo logs as long as cell patch 11.2.2.4 or higher is applied and Database 11.2.0.2 Bundle Patch 11 or higher is applied.

How to check that Smart Flash Logging is configured?

Using CellCLI run “LIST FLASHLOG DETAIL” and if output is returned as shown below with the details, then this means that Smart Flash Logging is configured:

[root@v1ex1dbadm01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/cell_group -l root cellcli -e "list flashlog detail"
 v1ex1celadm01: name: v1ex1celadm01_FLASHLOG
 v1ex1celadm01: cellDisk: FD_00_v1ex1celadm01,FD_01_v1ex1celadm01
 v1ex1celadm01: creationTime: 2015-06-28T17:52:43+01:00
 v1ex1celadm01: degradedCelldisks:
 v1ex1celadm01: effectiveSize: 512M
 v1ex1celadm01: efficiency: 100.0
 v1ex1celadm01: id: 366421ec-bf77-499e-870f-f0cf5390343e
 v1ex1celadm01: size: 512M
 v1ex1celadm01: status: normal
 v1ex1celadm02: name: v1ex1celadm02_FLASHLOG
 v1ex1celadm02: cellDisk: FD_01_v1ex1celadm02,FD_00_v1ex1celadm02
 v1ex1celadm02: creationTime: 2015-06-28T17:52:44+01:00
 v1ex1celadm02: degradedCelldisks:
 v1ex1celadm02: effectiveSize: 512M
 v1ex1celadm02: efficiency: 100.0
 v1ex1celadm02: id: 9f670843-c9cc-4156-a32e-8d23fa79cdb8
 v1ex1celadm02: size: 512M
 v1ex1celadm02: status: normal
 v1ex1celadm03: name: v1ex1celadm03_FLASHLOG
 v1ex1celadm03: cellDisk: FD_01_v1ex1celadm03,FD_00_v1ex1celadm03
 v1ex1celadm03: creationTime: 2015-06-28T17:52:33+01:00
 v1ex1celadm03: degradedCelldisks:
 v1ex1celadm03: effectiveSize: 512M
 v1ex1celadm03: efficiency: 100.0
 v1ex1celadm03: id: 749bada6-8ae2-4c51-8410-97622f9a9532
 v1ex1celadm03: size: 512M
 v1ex1celadm03: status: normal
[root@v1ex1dbadm01 ~]#

For more info:
Exadata Smart Flash Logging FAQ (Doc ID 1372894.1)
Oracle Exadata Whitepaper:  Exadata Smart Flash Cache Features and the Oracle Exadata Database Machine

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

How to Enable Exadata Write-Back Flash Cache

Please check the following blog post “How to check if Exadata Write-Back Flash Cache is Enabled” for:

  • What is Exadata Write-Back Flash Cache?
  • What are the Performance Benefit of Exadata Write-Back Flash Cache?
  • How to check if Exadata Write-Back Flash Cache is Enabled?
  • Pre-requisites and minimum versions.

You can also get more info from My Oracle Support (MOS) note:
Exadata Write-Back Flash Cache – FAQ (Doc ID 1500257.1)
OTN Article: Oracle Exadata Database Machine – Write-Back Flash Cache

How to Enable Exadata Write-Back Flash Cache

PLEASE NOTE: Although I have illustrated the steps below, please cross check with the MOS note to ensure the method below matches your setup or the steps haven’t changed with future releases (after the time of writing).

With Exadata software 11.2.3.3.1 or higher, it is not required to stop the cellsrv process on the storage cells or to inactivate griddisk.  If you are 11.2.3.2.1 to 11.2.3.3.0, the refer to the MOS notes for additional steps.

It is recommend to enabled Write-Back Flash Cache during a period of reduced workload to reduce the performance impact on the database.

Before proceeding with the enabling of Write-Back Flash Cache, it is recommended to check the caching policy of the grid disks, as we don’t want to enable Write-Back Flash Cache for grid disks that don’t need it i.e. RECO and DBFS disk groups:

[root@v1oex2dbadm01 ~]# dcli -l root -g /opt/oracle.SupportTools/onecommand/cell_group cellcli -e list griddisk attributes name,cachingpolicy,cachedby
 v1oex2celadm01: DATAC1_CD_00_v1oex2celadm01 default
 v1oex2celadm01: DATAC1_CD_01_v1oex2celadm01 default
 v1oex2celadm01: DATAC1_CD_02_v1oex2celadm01 default
 v1oex2celadm01: DATAC1_CD_03_v1oex2celadm01 default
 v1oex2celadm01: DATAC1_CD_04_v1oex2celadm01 default
 v1oex2celadm01: DATAC1_CD_05_v1oex2celadm01 default
 v1oex2celadm01: DBFS_DG_CD_02_v1oex2celadm01 default
 v1oex2celadm01: DBFS_DG_CD_03_v1oex2celadm01 default
 v1oex2celadm01: DBFS_DG_CD_04_v1oex2celadm01 default
 v1oex2celadm01: DBFS_DG_CD_05_v1oex2celadm01 default
 v1oex2celadm01: RECOC1_CD_00_v1oex2celadm01 default
 v1oex2celadm01: RECOC1_CD_01_v1oex2celadm01 default
 v1oex2celadm01: RECOC1_CD_02_v1oex2celadm01 default
 v1oex2celadm01: RECOC1_CD_03_v1oex2celadm01 default
 v1oex2celadm01: RECOC1_CD_04_v1oex2celadm01 default
 v1oex2celadm01: RECOC1_CD_05_v1oex2celadm01 default
 v1oex2celadm02: DATAC1_CD_00_v1oex2celadm02 default
 v1oex2celadm02: DATAC1_CD_01_v1oex2celadm02 default
 v1oex2celadm02: DATAC1_CD_02_v1oex2celadm02 default
 v1oex2celadm02: DATAC1_CD_03_v1oex2celadm02 default
 v1oex2celadm02: DATAC1_CD_04_v1oex2celadm02 default
 v1oex2celadm02: DATAC1_CD_05_v1oex2celadm02 default
 v1oex2celadm02: DBFS_DG_CD_02_v1oex2celadm02 default
 v1oex2celadm02: DBFS_DG_CD_03_v1oex2celadm02 default
 v1oex2celadm02: DBFS_DG_CD_04_v1oex2celadm02 default
 v1oex2celadm02: DBFS_DG_CD_05_v1oex2celadm02 default
 v1oex2celadm02: RECOC1_CD_00_v1oex2celadm02 default
 v1oex2celadm02: RECOC1_CD_01_v1oex2celadm02 default
 v1oex2celadm02: RECOC1_CD_02_v1oex2celadm02 default
 v1oex2celadm02: RECOC1_CD_03_v1oex2celadm02 default
 v1oex2celadm02: RECOC1_CD_04_v1oex2celadm02 default
 v1oex2celadm02: RECOC1_CD_05_v1oex2celadm02 default
 v1oex2celadm03: DATAC1_CD_00_v1oex2celadm03 default
 v1oex2celadm03: DATAC1_CD_01_v1oex2celadm03 default
 v1oex2celadm03: DATAC1_CD_02_v1oex2celadm03 default
 v1oex2celadm03: DATAC1_CD_03_v1oex2celadm03 default
 v1oex2celadm03: DATAC1_CD_04_v1oex2celadm03 default
 v1oex2celadm03: DATAC1_CD_05_v1oex2celadm03 default
 v1oex2celadm03: DBFS_DG_CD_02_v1oex2celadm03 default
 v1oex2celadm03: DBFS_DG_CD_03_v1oex2celadm03 default
 v1oex2celadm03: DBFS_DG_CD_04_v1oex2celadm03 default
 v1oex2celadm03: DBFS_DG_CD_05_v1oex2celadm03 default
 v1oex2celadm03: RECOC1_CD_00_v1oex2celadm03 default
 v1oex2celadm03: RECOC1_CD_01_v1oex2celadm03 default
 v1oex2celadm03: RECOC1_CD_02_v1oex2celadm03 default
 v1oex2celadm03: RECOC1_CD_03_v1oex2celadm03 default
 v1oex2celadm03: RECOC1_CD_04_v1oex2celadm03 default
 v1oex2celadm03: RECOC1_CD_05_v1oex2celadm03 default
 [root@v1oex2dbadm01 ~]#

As you can see, all the grid disks have default caching policy.  As per the following MOS note, we disable caching for RECO and DBFS disk groups:
Oracle Exadata Database Machine Setup/Configuration Best Practices (Doc ID 1274318.1)

[root@v1oex2dbadm01 ~]# dcli -c v1oex2celadm01 -l root cellcli -e alter griddisk DBFS_DG_CD_02_v1oex2celadm01,DBFS_DG_CD_03_v1oex2celadm01,DBFS_DG_CD_04_v1oex2celadm01,DBFS_DG_CD_05_v1oex2celadm01 cachingPolicy="none"
 v1oex2celadm01: GridDisk DBFS_DG_CD_02_v1oex2celadm01 successfully altered
 v1oex2celadm01: GridDisk DBFS_DG_CD_03_v1oex2celadm01 successfully altered
 v1oex2celadm01: GridDisk DBFS_DG_CD_04_v1oex2celadm01 successfully altered
 v1oex2celadm01: GridDisk DBFS_DG_CD_05_v1oex2celadm01 successfully altered
[root@v1oex2dbadm01 ~]# dcli -c v1oex2celadm02 -l root cellcli -e alter griddisk DBFS_DG_CD_02_v1oex2celadm02,DBFS_DG_CD_03_v1oex2celadm02,DBFS_DG_CD_04_v1oex2celadm02,DBFS_DG_CD_05_v1oex2celadm02 cachingPolicy="none"
 v1oex2celadm02: GridDisk DBFS_DG_CD_02_v1oex2celadm02 successfully altered
 v1oex2celadm02: GridDisk DBFS_DG_CD_03_v1oex2celadm02 successfully altered
 v1oex2celadm02: GridDisk DBFS_DG_CD_04_v1oex2celadm02 successfully altered
 v1oex2celadm02: GridDisk DBFS_DG_CD_05_v1oex2celadm02 successfully altered
[root@v1oex2dbadm01 ~]# dcli -c v1oex2celadm03 -l root cellcli -e alter griddisk DBFS_DG_CD_02_v1oex2celadm03,DBFS_DG_CD_03_v1oex2celadm03,DBFS_DG_CD_04_v1oex2celadm03,DBFS_DG_CD_05_v1oex2celadm03 cachingPolicy="none"
 v1oex2celadm03: GridDisk DBFS_DG_CD_02_v1oex2celadm03 successfully altered
 v1oex2celadm03: GridDisk DBFS_DG_CD_03_v1oex2celadm03 successfully altered
 v1oex2celadm03: GridDisk DBFS_DG_CD_04_v1oex2celadm03 successfully altered
 v1oex2celadm03: GridDisk DBFS_DG_CD_05_v1oex2celadm03 successfully altered 
[root@v1oex2dbadm01 ~]# dcli -c v1oex2celadm01 -l root cellcli -e alter griddisk RECOC1_CD_00_v1oex2celadm01,RECOC1_CD_01_v1oex2celadm01,RECOC1_CD_02_v1oex2celadm01,RECOC1_CD_03_v1oex2celadm01,RECOC1_CD_04_v1oex2celadm01,RECOC1_CD_05_v1oex2celadm01 cachingPolicy="none"
 v1oex2celadm01: GridDisk RECOC1_CD_00_v1oex2celadm01 successfully altered
 v1oex2celadm01: GridDisk RECOC1_CD_01_v1oex2celadm01 successfully altered
 v1oex2celadm01: GridDisk RECOC1_CD_02_v1oex2celadm01 successfully altered
 v1oex2celadm01: GridDisk RECOC1_CD_03_v1oex2celadm01 successfully altered
 v1oex2celadm01: GridDisk RECOC1_CD_04_v1oex2celadm01 successfully altered
 v1oex2celadm01: GridDisk RECOC1_CD_05_v1oex2celadm01 successfully altered 
[root@v1oex2dbadm01 ~]# dcli -c v1oex2celadm02 -l root cellcli -e alter griddisk RECOC1_CD_00_v1oex2celadm02,RECOC1_CD_01_v1oex2celadm02,RECOC1_CD_02_v1oex2celadm02,RECOC1_CD_03_v1oex2celadm02,RECOC1_CD_04_v1oex2celadm02,RECOC1_CD_05_v1oex2celadm02 cachingPolicy="none"
 v1oex2celadm02: GridDisk RECOC1_CD_00_v1oex2celadm02 successfully altered
 v1oex2celadm02: GridDisk RECOC1_CD_01_v1oex2celadm02 successfully altered
 v1oex2celadm02: GridDisk RECOC1_CD_02_v1oex2celadm02 successfully altered
 v1oex2celadm02: GridDisk RECOC1_CD_03_v1oex2celadm02 successfully altered
 v1oex2celadm02: GridDisk RECOC1_CD_04_v1oex2celadm02 successfully altered
 v1oex2celadm02: GridDisk RECOC1_CD_05_v1oex2celadm02 successfully altered
[root@v1oex2dbadm01 ~]# dcli -c v1oex2celadm03 -l root cellcli -e alter griddisk RECOC1_CD_00_v1oex2celadm03,RECOC1_CD_01_v1oex2celadm03,RECOC1_CD_02_v1oex2celadm03,RECOC1_CD_03_v1oex2celadm03,RECOC1_CD_04_v1oex2celadm03,RECOC1_CD_05_v1oex2celadm03 cachingPolicy="none"
 v1oex2celadm03: GridDisk RECOC1_CD_00_v1oex2celadm03 successfully altered
 v1oex2celadm03: GridDisk RECOC1_CD_01_v1oex2celadm03 successfully altered
 v1oex2celadm03: GridDisk RECOC1_CD_02_v1oex2celadm03 successfully altered
 v1oex2celadm03: GridDisk RECOC1_CD_03_v1oex2celadm03 successfully altered
 v1oex2celadm03: GridDisk RECOC1_CD_04_v1oex2celadm03 successfully altered
 v1oex2celadm03: GridDisk RECOC1_CD_05_v1oex2celadm03 successfully altered
[root@v1oex2dbadm01 ~]#

Now when we enabling of Write-Back Flash Cache, it will not cache for grid disks for RECO and DBFS disk group, avoiding the need to flush to disk and change policy as post step:

[root@v1oex2dbadm01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/cell_group -l root cellcli -e list griddisk attributes name,cachingpolicy,cachedby
 v1oex2celadm01: DATAC1_CD_00_v1oex2celadm01 default
 v1oex2celadm01: DATAC1_CD_01_v1oex2celadm01 default
 v1oex2celadm01: DATAC1_CD_02_v1oex2celadm01 default
 v1oex2celadm01: DATAC1_CD_03_v1oex2celadm01 default
 v1oex2celadm01: DATAC1_CD_04_v1oex2celadm01 default
 v1oex2celadm01: DATAC1_CD_05_v1oex2celadm01 default
 v1oex2celadm01: DBFS_DG_CD_02_v1oex2celadm01 none
 v1oex2celadm01: DBFS_DG_CD_03_v1oex2celadm01 none
 v1oex2celadm01: DBFS_DG_CD_04_v1oex2celadm01 none
 v1oex2celadm01: DBFS_DG_CD_05_v1oex2celadm01 none
 v1oex2celadm01: RECOC1_CD_00_v1oex2celadm01 none
 v1oex2celadm01: RECOC1_CD_01_v1oex2celadm01 none
 v1oex2celadm01: RECOC1_CD_02_v1oex2celadm01 none
 v1oex2celadm01: RECOC1_CD_03_v1oex2celadm01 none
 v1oex2celadm01: RECOC1_CD_04_v1oex2celadm01 none
 v1oex2celadm01: RECOC1_CD_05_v1oex2celadm01 none
 v1oex2celadm02: DATAC1_CD_00_v1oex2celadm02 default
 v1oex2celadm02: DATAC1_CD_01_v1oex2celadm02 default
 v1oex2celadm02: DATAC1_CD_02_v1oex2celadm02 default
 v1oex2celadm02: DATAC1_CD_03_v1oex2celadm02 default
 v1oex2celadm02: DATAC1_CD_04_v1oex2celadm02 default
 v1oex2celadm02: DATAC1_CD_05_v1oex2celadm02 default
 v1oex2celadm02: DBFS_DG_CD_02_v1oex2celadm02 none
 v1oex2celadm02: DBFS_DG_CD_03_v1oex2celadm02 none
 v1oex2celadm02: DBFS_DG_CD_04_v1oex2celadm02 none
 v1oex2celadm02: DBFS_DG_CD_05_v1oex2celadm02 none
 v1oex2celadm02: RECOC1_CD_00_v1oex2celadm02 none
 v1oex2celadm02: RECOC1_CD_01_v1oex2celadm02 none
 v1oex2celadm02: RECOC1_CD_02_v1oex2celadm02 none
 v1oex2celadm02: RECOC1_CD_03_v1oex2celadm02 none
 v1oex2celadm02: RECOC1_CD_04_v1oex2celadm02 none
 v1oex2celadm02: RECOC1_CD_05_v1oex2celadm02 none
 v1oex2celadm03: DATAC1_CD_00_v1oex2celadm03 default
 v1oex2celadm03: DATAC1_CD_01_v1oex2celadm03 default
 v1oex2celadm03: DATAC1_CD_02_v1oex2celadm03 default
 v1oex2celadm03: DATAC1_CD_03_v1oex2celadm03 default
 v1oex2celadm03: DATAC1_CD_04_v1oex2celadm03 default
 v1oex2celadm03: DATAC1_CD_05_v1oex2celadm03 default
 v1oex2celadm03: DBFS_DG_CD_02_v1oex2celadm03 none
 v1oex2celadm03: DBFS_DG_CD_03_v1oex2celadm03 none
 v1oex2celadm03: DBFS_DG_CD_04_v1oex2celadm03 none
 v1oex2celadm03: DBFS_DG_CD_05_v1oex2celadm03 none
 v1oex2celadm03: RECOC1_CD_00_v1oex2celadm03 none
 v1oex2celadm03: RECOC1_CD_01_v1oex2celadm03 none
 v1oex2celadm03: RECOC1_CD_02_v1oex2celadm03 none
 v1oex2celadm03: RECOC1_CD_03_v1oex2celadm03 none
 v1oex2celadm03: RECOC1_CD_04_v1oex2celadm03 none
 v1oex2celadm03: RECOC1_CD_05_v1oex2celadm03 none
 [root@v1oex2dbadm01 ~]#

Next we check that all the grid disks on all storage cells have the asmdeactivationoutcome and asmmodestatus as “Yes” and “ONLINE” respectively.

[root@v1ex2dbadm01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/cell_group -l root cellcli -e list griddisk attributes asmdeactivationoutcome, asmmodestatus
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm01: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm02: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
v1ex2celadm03: Yes ONLINE
[root@v1ex2dbadm01 ~]#

Next we check that all of the Flash Cache are in the “normal” state and that no flash disks are in a degraded or critical state:

[root@v1ex2dbadm01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/cell_group -l root cellcli -e list flashcache detail
v1ex2celadm01: name: v1ex2celadm01_FLASHCACHE
v1ex2celadm01: cellDisk: FD_01_v1ex2celadm01,FD_00_v1ex2celadm01
v1ex2celadm01: creationTime: 2015-07-01T13:39:22+01:00
v1ex2celadm01: degradedCelldisks:
v1ex2celadm01: effectiveCacheSize: 2.910369873046875T
v1ex2celadm01: id: 655bdb7a-8d3b-40e5-88af-cd42843dd3f7
v1ex2celadm01: size: 2.910369873046875T
v1ex2celadm01: status: normal
v1ex2celadm02: name: v1ex2celadm02_FLASHCACHE
v1ex2celadm02: cellDisk: FD_01_v1ex2celadm02,FD_00_v1ex2celadm02
v1ex2celadm02: creationTime: 2015-07-01T06:38:05+01:00
v1ex2celadm02: degradedCelldisks:
v1ex2celadm02: effectiveCacheSize: 2.910369873046875T
v1ex2celadm02: id: 1cc0f7a4-885a-4e23-aec5-b47bc488e8e3
v1ex2celadm02: size: 2.910369873046875T
v1ex2celadm02: status: normal
v1ex2celadm03: name: v1ex2celadm03_FLASHCACHE
v1ex2celadm03: cellDisk: FD_01_v1ex2celadm03,FD_00_v1ex2celadm03
v1ex2celadm03: creationTime: 2015-07-01T20:39:30+01:00
v1ex2celadm03: degradedCelldisks:
v1ex2celadm03: effectiveCacheSize: 2.910369873046875T
v1ex2celadm03: id: b07f6011-1d66-4c3f-a25f-26d1e6b55633
v1ex2celadm03: size: 2.910369873046875T
v1ex2celadm03: status: normal
[root@v1ex2dbadm01 ~]#

Next we validate all the Physical Disks are in the “NORMAL” state before we modifying the Flash Cache:

[root@v1ex2dbadm01 ~]# dcli -l root -g /opt/oracle.SupportTools/onecommand/cell_group cellcli -e "list physicaldisk attributes name,status"
v1ex2celadm01: 8:0 normal
v1ex2celadm01: 8:1 normal
v1ex2celadm01: 8:2 normal
v1ex2celadm01: 8:3 normal
v1ex2celadm01: 8:4 normal
v1ex2celadm01: 8:5 normal
v1ex2celadm01: 8:6 normal
v1ex2celadm01: 8:7 normal
v1ex2celadm01: 8:8 normal
v1ex2celadm01: 8:9 normal
v1ex2celadm01: 8:10 normal
v1ex2celadm01: 8:11 normal
v1ex2celadm01: FLASH_1_1 normal
v1ex2celadm01: FLASH_2_1 normal
v1ex2celadm01: FLASH_4_1 normal
v1ex2celadm01: FLASH_5_1 normal
v1ex2celadm02: 8:0 normal
v1ex2celadm02: 8:1 normal
v1ex2celadm02: 8:2 normal
v1ex2celadm02: 8:3 normal
v1ex2celadm02: 8:4 normal
v1ex2celadm02: 8:5 normal
v1ex2celadm02: 8:6 normal
v1ex2celadm02: 8:7 normal
v1ex2celadm02: 8:8 normal
v1ex2celadm02: 8:9 normal
v1ex2celadm02: 8:10 normal
v1ex2celadm02: 8:11 normal
v1ex2celadm02: FLASH_1_1 normal
v1ex2celadm02: FLASH_2_1 normal
v1ex2celadm02: FLASH_4_1 normal
v1ex2celadm02: FLASH_5_1 normal
v1ex2celadm03: 8:0 normal
v1ex2celadm03: 8:1 normal
v1ex2celadm03: 8:2 normal
v1ex2celadm03: 8:3 normal
v1ex2celadm03: 8:4 normal
v1ex2celadm03: 8:5 normal
v1ex2celadm03: 8:6 normal
v1ex2celadm03: 8:7 normal
v1ex2celadm03: 8:8 normal
v1ex2celadm03: 8:9 normal
v1ex2celadm03: 8:10 normal
v1ex2celadm03: 8:11 normal
v1ex2celadm03: FLASH_1_1 normal
v1ex2celadm03: FLASH_2_1 normal
v1ex2celadm03: FLASH_4_1 normal
v1ex2celadm03: FLASH_5_1 normal
[root@v1ex2dbadm01 ~]#

You can run the same command with inverse grep on “normal” to ensure you didn’t miss any disks that are not normal:

[root@v1ex2dbadm01 ~]# dcli -l root -g /opt/oracle.SupportTools/onecommand/cell_group cellcli -e "list physicaldisk attributes name,status"|grep -v normal
[root@v1ex2dbadm01 ~]#

Next we drop the Flash Cache to be able to change the attribute:

PLEASE NOTE: Any data that is currently cached in Flash Cache and being served will then need to be served by Hard Disks and a noticeable performance degradation will be observed.  Hence it is recommend to enabled Write-Back Flash Cache during a period of reduced workload to reduce the performance impact on the database.

[root@v1ex2dbadm01 ~]# dcli -l root -g /opt/oracle.SupportTools/onecommand/cell_group cellcli -e drop flashcache 
v1ex2celadm01: Flash cache v1ex2celadm01_FLASHCACHE successfully dropped 
v1ex2celadm02: Flash cache v1ex2celadm02_FLASHCACHE successfully dropped 
v1ex2celadm03: Flash cache v1ex2celadm03_FLASHCACHE successfully dropped 
[root@v1ex2dbadm01 ~]#

Next we set the “flashCacheMode” attribute to “writeback“:

[root@v1ex2dbadm01 ~]# dcli -l root -g /opt/oracle.SupportTools/onecommand/cell_group cellcli -e "alter cell flashCacheMode=writeback"
v1ex2celadm01: Cell v1ex2celadm01 successfully altered
v1ex2celadm02: Cell v1ex2celadm02 successfully altered
v1ex2celadm03: Cell v1ex2celadm03 successfully altered
[root@v1ex2dbadm01 ~]#

Next we re-create the Flash Cache, which will be in Write-Back instead of WriteThrough:

[root@v1ex2dbadm01 ~]# dcli -l root -g /opt/oracle.SupportTools/onecommand/cell_group cellcli -e create flashcache all
v1ex2celadm01: Flash cache v1ex2celadm01_FLASHCACHE successfully created
v1ex2celadm02: Flash cache v1ex2celadm02_FLASHCACHE successfully created
v1ex2celadm03: Flash cache v1ex2celadm03_FLASHCACHE successfully created
[root@v1ex2dbadm01 ~]#

Next we check the attribute “flashCacheMode” is actually now “writeback“:

[root@v1ex2dbadm01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/cell_group -l root cellcli -e "list cell attributes flashcachemode"
v1ex2celadm01: writeback
v1ex2celadm02: writeback
v1ex2celadm03: writeback
[root@v1ex2dbadm01 ~]#

At this point, write I/O will go straight to flash and then can be moved to hard disk if aged or not required for read caching.  The Flash Cache will be repopulated over time and performance will return to normal for reads with addition performance for writes 🙂

You can check the usage increase as Flash Cache repopulates as follows:

[root@v1oex2dbadm01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/cell_group -l root cellcli -e LIST METRICCURRENT FC_BY_USED
 v1oex2celadm01: FC_BY_USED FLASHCACHE 104,838 MB
 v1oex2celadm02: FC_BY_USED FLASHCACHE 104,479 MB
 v1oex2celadm03: FC_BY_USED FLASHCACHE 105,192 MB
[root@v1oex2dbadm01 ~]#

Finally, we validate grid disk attributes cachingPolicy and cachedby, where we can see only the DATA disk group is being cached by Flash Cache and by which Flash Disk:

[root@v1oex2dbadm01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/cell_group -l root cellcli -e list griddisk attributes name,cachingpolicy,cachedby
v1oex2celadm01: DATAC1_CD_00_v1oex2celadm01 default FD_01_v1oex2celadm01
v1oex2celadm01: DATAC1_CD_01_v1oex2celadm01 default FD_01_v1oex2celadm01
v1oex2celadm01: DATAC1_CD_02_v1oex2celadm01 default FD_00_v1oex2celadm01
v1oex2celadm01: DATAC1_CD_03_v1oex2celadm01 default FD_00_v1oex2celadm01
v1oex2celadm01: DATAC1_CD_04_v1oex2celadm01 default FD_01_v1oex2celadm01
v1oex2celadm01: DATAC1_CD_05_v1oex2celadm01 default FD_00_v1oex2celadm01
v1oex2celadm01: DBFS_DG_CD_02_v1oex2celadm01 none
v1oex2celadm01: DBFS_DG_CD_03_v1oex2celadm01 none
v1oex2celadm01: DBFS_DG_CD_04_v1oex2celadm01 none
v1oex2celadm01: DBFS_DG_CD_05_v1oex2celadm01 none
v1oex2celadm01: RECOC1_CD_00_v1oex2celadm01 none
v1oex2celadm01: RECOC1_CD_01_v1oex2celadm01 none
v1oex2celadm01: RECOC1_CD_02_v1oex2celadm01 none
v1oex2celadm01: RECOC1_CD_03_v1oex2celadm01 none
v1oex2celadm01: RECOC1_CD_04_v1oex2celadm01 none
v1oex2celadm01: RECOC1_CD_05_v1oex2celadm01 none
v1oex2celadm02: DATAC1_CD_00_v1oex2celadm02 default FD_01_v1oex2celadm02
v1oex2celadm02: DATAC1_CD_01_v1oex2celadm02 default FD_00_v1oex2celadm02
v1oex2celadm02: DATAC1_CD_02_v1oex2celadm02 default FD_01_v1oex2celadm02
v1oex2celadm02: DATAC1_CD_03_v1oex2celadm02 default FD_01_v1oex2celadm02
v1oex2celadm02: DATAC1_CD_04_v1oex2celadm02 default FD_00_v1oex2celadm02
v1oex2celadm02: DATAC1_CD_05_v1oex2celadm02 default FD_00_v1oex2celadm02
v1oex2celadm02: DBFS_DG_CD_02_v1oex2celadm02 none
v1oex2celadm02: DBFS_DG_CD_03_v1oex2celadm02 none
v1oex2celadm02: DBFS_DG_CD_04_v1oex2celadm02 none
v1oex2celadm02: DBFS_DG_CD_05_v1oex2celadm02 none
v1oex2celadm02: RECOC1_CD_00_v1oex2celadm02 none
v1oex2celadm02: RECOC1_CD_01_v1oex2celadm02 none
v1oex2celadm02: RECOC1_CD_02_v1oex2celadm02 none
v1oex2celadm02: RECOC1_CD_03_v1oex2celadm02 none
v1oex2celadm02: RECOC1_CD_04_v1oex2celadm02 none
v1oex2celadm02: RECOC1_CD_05_v1oex2celadm02 none
v1oex2celadm03: DATAC1_CD_00_v1oex2celadm03 default FD_01_v1oex2celadm03
v1oex2celadm03: DATAC1_CD_01_v1oex2celadm03 default FD_01_v1oex2celadm03
v1oex2celadm03: DATAC1_CD_02_v1oex2celadm03 default FD_00_v1oex2celadm03
v1oex2celadm03: DATAC1_CD_03_v1oex2celadm03 default FD_00_v1oex2celadm03
v1oex2celadm03: DATAC1_CD_04_v1oex2celadm03 default FD_01_v1oex2celadm03
v1oex2celadm03: DATAC1_CD_05_v1oex2celadm03 default FD_00_v1oex2celadm03
v1oex2celadm03: DBFS_DG_CD_02_v1oex2celadm03 none
v1oex2celadm03: DBFS_DG_CD_03_v1oex2celadm03 none
v1oex2celadm03: DBFS_DG_CD_04_v1oex2celadm03 none
v1oex2celadm03: DBFS_DG_CD_05_v1oex2celadm03 none
v1oex2celadm03: RECOC1_CD_00_v1oex2celadm03 none
v1oex2celadm03: RECOC1_CD_01_v1oex2celadm03 none
v1oex2celadm03: RECOC1_CD_02_v1oex2celadm03 none
v1oex2celadm03: RECOC1_CD_03_v1oex2celadm03 none
v1oex2celadm03: RECOC1_CD_04_v1oex2celadm03 none
v1oex2celadm03: RECOC1_CD_05_v1oex2celadm03 none
[root@v1oex2dbadm01 ~]#

Final note, there is a script provided by Oracle that can do this all for you called setWBFC, however the version 1.0.0.2.1.20160602 didn’t work for me as it detected 4 Flash Disks in eighth rack when it expected 2.  Although there is only 2 in use in eighth rack, there is 4 physically present, so I believe this is a bug.  I did raise an SR with Oracle Support, which is yet to be concluded.  Below is the output for those who are interested:

[root@v1oex2dbadm01 WBFC]# ./setWBFC.sh
 setWBFC Version: 1.0.0.2.1.20160602
 Usage:
 ./setWBFC.sh -g cell_group_file [-d dbs_group_file ]
 [ -h ] [ -i ] [ -l log_directory ]
 [ -m WriteBack | WriteThrough ] [ -o rolling | non-rolling ]
 [ -p ] [ -s step_number ] [ -t time_out_seconds ]
 [ -x trace_level ] [ -v ]

-g file file that lists cell host names, one per line
 -d file file that lists the database host names, one
 per line. Required for non-rolling.
 -h help, print this information
 -i run in interactive mode
 -l log directory directory path for log files
 -m FC_mode flashcache mode: WriteBack | WriteThrough
 -o exec_mode execution mode: rolling | non-rolling (default)
 -p perform a precheck only
 -s step # (*) specify step number to restart at
 -t timeout sec specify in seconds the amount of time to wait
 for griddisks to come ONLINE - range: [600 - 43200]
 Default: 21600 (6 hours)
 -x trace level # specify trace level for further diagnostics
 -v show version

(*) -- Option not yet implemented.

 [root@v1oex2dbadm01 WBFC]# ./setWBFC.sh -g /opt/oracle.SupportTools/onecommand/cell_group -l /root/v1/WBFC/logs -m WriteBack -o rolling -p
 ./setWBFC.sh: Using log directory '/root/v1/WBFC/logs'
 ./setWBFC.sh: Log File '/root/v1/WBFC/logs/setWBFC_18335_2018-01-17-10:46:26.log' created successfully
 2018-01-17 10:46:26
 Starting ./setWBFC.sh on v1oex2dbadm01
 Version: 1.0.0.2.1.20160602
 Command line options used:
 -g /opt/oracle.SupportTools/onecommand/cell_group
 -o rolling
 -m WriteBack
 -p (Perform pre-req checks only)
 -t 21600
 -x 0

2018-01-17 10:46:26
 Performing pre-req checks.....
 2018-01-17 10:46:26
 Creating baseline inventory for griddisks
 2018-01-17 10:46:27
 Creating baseline inventory for flashdisks
 2018-01-17 10:46:28
 Creating baseline inventory for flashsize
 2018-01-17 10:46:28
 dcli present and in PATH. [PASSED]
 2018-01-17 10:46:28
 Checking cell nodes are valid storage servers...
 2018-01-17 10:46:29
 All cells are valid Exadata storage cells.
 2018-01-17 10:46:29
 Checking Exadata Storage Software Versions...
 2018-01-17 10:46:33
 Software versions of the following cells:
 v1oex2celadm01: 12.1.2.3.5.170418 [PASSED]
 v1oex2celadm02: 12.1.2.3.5.170418 [PASSED]
 v1oex2celadm03: 12.1.2.3.5.170418 [PASSED]

2018-01-17 10:46:33
 Checking Grid Infrastructure Software Version...
 2018-01-17 10:46:38
 Grid Infrastructure version: 12.1.0.2.00 [PASSED]

2018-01-17 10:46:38
 Checking for active ASM operations....
 2018-01-17 10:46:38
 Check for no active ASM operations: [PASSED]
 2018-01-17 10:46:38
 Checking griddisk status across all cells....
 2018-01-17 10:46:39
 All griddisks across all cells have asmdeactivationoutcome = Yes
 All griddisks across all cells are ONLINE
 Griddisk checks: [PASSED]
 2018-01-17 10:46:39
 Checking flash cache status.....
 2018-01-17 10:46:40
 Flashcache status normal: [PASSED]
 2018-01-17 10:46:40
 Checking that all FlashDisks are present...
 2018-01-17 10:46:42
 Cell v1oex2celadm01 has one or more FlashDisk missing. Expecting 2 but found 4

2018-01-17 10:46:42
 FlashDisk validation: [FAILED]
 2018-01-17 10:46:42
 Checking current flash cache mode.....
 2018-01-17 10:46:43
 Flashcache not already in target mode: [PASSED]
 2018-01-17 10:46:43
 Pre-req checks failed with status 7. Exiting....

[root@v1oex2dbadm01 WBFC]#

If this works for you, great then I would recommend using this method, otherwise it can be used to double check the pre-requisites at least and then you can do manually as I did shown above 🙂

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

How to check if Exadata Write-Back Flash Cache is Enabled

What is Exadata Write-Back Flash Cache?

Exadata Write-Back Flash Cache provides the ability to cache not only read I/Os but write I/O to the Exadata’s PCI flash on the storage cells.  Exadata storage software 11.2.3.2.1 or higher and Grid Infrastructure and Database software 11.2.0.3.9 or higher is required to use Exadata Write-Back Flash Cache, which is persistent across storage cell restarts.

The default since April 2017 for the Oracle Exadata Deployment Assistant (OEDA) is Write-Back Flash Cache when DATA diskgroup is HIGH redundancy and Grid Infrastructure and Database software are:

  • 11.2.0.4.1 or higher
  • 12.1.0.2 or higher
  • 12.2.0.2 or higher

PLEASE NOTE: This option is only applicable to High Capacity as Extreme Flash doesn’t have Hard Disks and therefore Write-Back Flash Cache is explicitly enabled and can’t be disabled.

What are the Performance Benefit of Exadata Write-Back Flash Cache?

Write-Back Flash Cache can significantly improve write intensive operations because writing to Flash Cache is significantly faster than writing to Hard Disks.  Depending on the workload, write performance (IOPS) can be improved by 10x on older generations of Exadata Machines V2 and X2 and 20x on newer generations X3 onwards (correct at time of writing).

If you are experiencing high write I/O times on storage cells from AWR Reports or Storage Cell metrics, then you should consider enabling Write-Back Flash Cache to alleviate write operations on Hard Disks and move to Flash Cache.

See the following My Oracle Support (MOS) Note for more info:
Exadata Write-Back Flash Cache – FAQ (Doc ID 1500257.1)

How to check if Exadata Write-Back Flash Cache is Enabled?

To check if Exadata Write-Back Flash Cache is enabled, run “list cell attributes flashcachemode” on the storage cell using CellCLI as shown below:

[root@v1ex2celadm01 ~]# cellcli
CellCLI: Release 12.1.2.3.5 - Production on Wed Jan 17 10:09:51 GMT 2018

Copyright (c) 2007, 2016, Oracle. All rights reserved.

CellCLI> list cell attributes flashcachemode
 WriteThrough

CellCLI> exit
quitting

[root@v1ex2celadm01 ~]#

If “WriteThrough” then Write-Back Flash Cache is disabled (writes go straight to hard disk and then can be placed in flash for caching reads if required), otherwise if “WriteBack” then Write-Back Flash Cache is enabled as the name suggests (writes go straight to flash and then can be moved to hard disk if aged or not required for read caching).

You can also run “list cell detail” using CellCLI as shown below:

[root@v1ex2celadm01 ~]# cellcli
CellCLI: Release 12.1.2.3.5 - Production on Wed Jan 17 10:10:22 GMT 2018

Copyright (c) 2007, 2016, Oracle. All rights reserved.

CellCLI> list cell detail
 name: v1ex2celadm01
 accessLevelPerm: remoteLoginEnabled
 bbuStatus: normal
 cellVersion: OSS_12.1.2.3.5_LINUX.X64_170418
 cpuCount: 16/32
 diagHistoryDays: 7
 eighthRack: TRUE
 fanCount: 8/8
 fanStatus: normal
 flashCacheMode: WriteThrough
 id: xxxxxxxxxx
 interconnectCount: 2
 interconnect1: ib0
 interconnect2: ib1
 iormBoost: 6.4
 ipaddress1: 10.1.11.14/22
 ipaddress2: 10.1.11.15/22
 kernelVersion: 2.6.39-400.294.4.el6uek.x86_64
 locatorLEDStatus: off
 makeModel: Oracle Corporation ORACLE SERVER X5-2L High Capacity
 memoryGB: 95
 metricHistoryDays: 7
 notificationMethod: snmp
 notificationPolicy: critical,warning,clear
 offloadGroupEvents:
 powerCount: 2/2
 powerStatus: normal
 releaseImageStatus: success
 releaseVersion: 12.1.2.3.5.170418
 rpmVersion: cell-12.1.2.3.5_LINUX.X64_170418-1.x86_64
 releaseTrackingBug: 25509078
 rollbackVersion: 12.1.2.3.4.170111
 securityCert: PrivateKey OK
 Certificate: Subject CN=v1ex2celadm01.v1.com,OU=Oracle Exadata,O=Oracle Corporation,L=Redwood City,ST=California,C=US
 Issuer CN=v1ex2celadm01.v1.com,OU=Oracle Exadata,O=Oracle Corporation,L=Redwood City,ST=California,C=US
 snmpSubscriber: host=v1ex2dbadm02.v1.com,port=1830,community=public
 host=v1ex2dbadm01.v1.com,port=1830,community=public
 host=v1ex2dbadm01.v1.com,port=3872,community=public
 host=v1ex2dbadm02.v1.com,port=3872,community=public
 status: online
 temperatureReading: 24.0
 temperatureStatus: normal
 upTime: 105 days, 7:35
 usbStatus: normal
 cellsrvStatus: running
 msStatus: running
 rsStatus: running

CellCLI> exit
quitting

[root@v1ex2celadm01 ~]#

However, the simpler way to check is via dcli, especially when you have lots of storage cells as shown below:

[root@v1ex2dbadm01 ~]# dcli -g /opt/oracle.SupportTools/onecommand/cell_group -l root cellcli -e "list cell attributes flashcachemode"
v1ex2celadm01: WriteThrough
v1ex2celadm02: WriteThrough
v1ex2celadm03: WriteThrough

Related Posts:
How to Enable Exadata Write-Back Flash Cache

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

How to use the Oracle Exadata Diagnostics Collection Tool (sundiag.sh)

What is the Oracle Exadata Diagnostics Collection Tool sundiag.sh

Very often when creating a Support Request (SR) for an issue on an Oracle Exadata Database Machine, you’ll need to run the script “sundiag.sh“.  Which is the “Oracle Exadata Database Machine – Diagnostics Collection Tool“.

The tool collects a lot of diagnostics information that assist the support analyst in diagnosing your problem, such as failed hardware like a failed disk, etc.

More information can be found on My Oracle Support (MOS) Note:
SRDC – EEST Sundiag (Doc ID 1683842.1)
Oracle Exadata Diagnostic Information required for Disk Failures and some other Hardware issues (Doc ID 761868.1)

How to run the Diagnostics Collection Tool

To run “sundiag.sh“, is very simple as shown below:

[root@v1ex1dbadm01 ~]# /opt/oracle.SupportTools/sundiag.sh
Oracle Exadata Database Machine - Diagnostics Collection Tool
Gathering Linux information
Skipping collection of OSWatcher/ExaWatcher logs, Cell Metrics and Traces
Skipping ILOM collection. Use the ilom or snapshot options, or login to ILOM
over the network and run Snapshot separately if necessary.
/var/log/exadatatmp/sundiag_v1ex1dbadm01_xxxxxxxxxx_2018_01_17_13_49
Gathering dbms information
Generating diagnostics tarball and removing temp directory
==============================================================================
Done. The report files are bzip2 compressed in /var/log/exadatatmp/sundiag_v1ex1dbadm01_xxxxxxxxxx_2018_01_17_13_49.tar.bz2
==============================================================================
[root@v1ex1dbadm01 ~]#

For more advanced collections, use the option switches to override default behaviour as shown in the help:

[root@v1ex1dbadm01 ~]# /opt/oracle.SupportTools/sundiag.sh -h

Oracle Exadata Database Machine - Diagnostics Collection Tool

Version: 12.1.2.3.3.161109

By default sundiag will collect OSWatcher/ExaWatcher, Cell Metrics and traces,
if there was an alert in the last 7 days. If there is more than one alert, latest
alert is chosen to set the time range for data collection.
Time range is 8hrs prior to and 1hr after the latest alert, for the total of 9 hrs
e.g: latest alert timestamp = 2014-03-29T01:20:04-05:00
 echo Time range = 2014-03-28_16:00:00 and 2014-03-29_01:00:00
User can also specify time ranges (as explained in usage below), which takes
precedence over default behavior of checking for alerts

Usage: /opt/oracle.SupportTools/sundiag.sh [ilom | snapshot] [osw <time ranges>]
 osw - This argument when used expects value of one or more comma separated
 time ranges. OSWatcher/ExaWatcher, cell metrics and traces will be gathered
 in those time ranges.
 The format for time range(s) is <from>-<to>,<from>-<to> and so on without spaces
 where <from> and <to> format is <date>_<time>
 <date> and <time> format should be any valid format that can be recognized by
 'date' command. The command 'date -d <date>' or 'date -d <time>' should be valid
 e.g: /opt/oracle.SupportTools/sundiag.sh osw 2014/03/31_15:00:00-2014/03/31_18:00:00
 Note: Total time range should not exceed 9 hrs. Only the time ranges that
 fall within this limit are considered for the collection of above data
 ilom - User level ILOM data gathering option via ipmitool, in place of
 separately using root login to get ILOM snapshot over the network.
 snapshot - Collects node ILOM snapshot- requires host root password for ILOM
 to send snapshot data over the network.
[root@v1ex1dbadm01 ~]#

Then just upload the bzip2 file to your SR on MOS.

I tend to run this as part of my SR creation and upload to save time.

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

ODC Appreciation Day : Oracle Exadata Database Machine

Those that know me well, will know about my “appreciation” of the “Oracle Exadata Database Machine“, more commonly known as “Exadata” 🙂

So this will be my contribution to ODC Appreciation Day formally known as OTN Appreciation Day, a great initiative by Tim Hall aka Oracle-Base.com.

You can see a summary of last year’s blog post here:
OTN Appreciation Day : Summary

The very first Exadata, was the V1 model, the hardware by HP and the software by Oracle.  I still remember being very excited by this in my previous employment at Auto Trader and trying very hard to convince them to get one 🙂

I, of course, became an instant fan of the brawn hardware with smart software, Oracle labelling as “Hardware and Software optimised together“.

Oracle’s partnership with HP only lasted a year with Oracle switching to Sun on the V2 model, when shortly after Oracle then brought Sun in 2010.  This is when Oracle switched from the V models to X models, with the initial models being the X2-2 (2 socket) and X2-8 (8 sockets).

I still remember this old video “Oracle Exadata. Are You Ready?” that I played at an internal Auto Trader conference which was about sharing knowledge, interesting new things, etc:

Exadata has come a long way since the initial release that was aimed at being a Data Warehouse to a Full On OLTP, Data Warehouse, mixed load, consolidation platform, etc with “record-breaking” IOPS and scan rate!

My favourite feature is the smart scan, the ability to off load data intensive SQL operations from the database servers directly into the storage servers, mitigating the need to pull lots of data from storage to database server.  Yes you can have very fast All Flash Storage, but the network to ship all this to the database server becomes the bottleneck and the compute to filter the data on the database server.  Exadata does this at the storage server meaning only the rows and columns that are directly relevant to a query are sent to the database servers.

Another one is storage indexes where the min and max values are stored of a column in 1Mb chunk in memory to allow for unnecessary I/O to be avoided when it’s known that block of data doesn’t meet the predicate condition.

I didn’t manage to convince Auto Trader, however I have since been very fortunate in my current employment at Version 1 to have worked on Exadata since 2014 from the Exadata X2-2 through to X5-2.  I do really appreciate these “Engineered Systems” for the Extreme Performance, Reliability and Availability.  The whole concept of being “Engineered” and the whole stack optimised, really works and the fact that all Exadatas are the same hardware makes you appreciate their supportability.  Even patching them with patchmgr is pretty much a doddle these days! 🙂

For more info, visit the following site:
www.Oracle.com/Exadata
https://en.wikipedia.org/wiki/Oracle_Exadata

Tuesday 10th October 2017

Happy ODC Appreciation Day! #ThanksODC #ThanksOTN 🙂

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

How to use Oracle Exadata Database Machine Exa Check (exachk)

Oracle customers who are fortunate to have an Oracle Exadata Database Machine, will need to run “exachk” from time to time, which is pronounced as Exa-Check.  This tool checks your Oracle Exadata Database Machine configuration, software, critical issue and provides a Maximum Availability Architecture score.  It is required to run before and after Exadata patching and is good practice to run on a frequent basis and review the recommendations.

More info here:

Oracle Exadata Database Machine exachk or HealthCheck (Doc ID 1070954.1)

“exachk holistically evaluates all Oracle Engineered Systems.   

It includes:

  • Configuration checks for Database Servers, Storage Servers and InfiniBand Switches
  • Grid Infrastructure, Database and ASM and operating system software checks
  • MAA Scorecard which conducts an automatic MAA Review
  • Exadata Software Planner, Software prechecks, Exadata and Database Critical Issue alerts

All checks have explanations, recommendations, and manual verification commands so that customers can self-correct all FAIL and WARNING conditions reported. 

Development recommends that the latest exachk be executed with the following frequency:

  • Monthly
  • Week before any planned maintenance activity
  • Day before any planned maintenance activity
  • Immediately after completion of planned maintenance activity or an outage or incident”

The download can be obtained from the above MOS note 1070954.1.  Place the download zip file as root on a compute node, in the Oracle’s Home for example, I use “/home/oracle/version1/exachk”.  Within this folder create another folder called exachk, which allows you to easily replace the tool with the latest version and unzip the zip file to this folder:

[root@v1ex2dbadm01 exachk]# pwd
/home/oracle/version1/exachk
[root@v1ex2dbadm01 exachk]# rm -rf exachk
[root@v1ex2dbadm01 exachk]# mkdir exachk
[root@v1ex2dbadm01 exachk]# ls -lh
total 19M
drwxr-xr-x 2 root root 4.0K Sep 5 10:53 exachk
-rw-r--r-- 1 root root 19M Sep 5 10:51 exachk.zip
[root@v1ex2dbadm01 exachk]# unzip exachk.zip -d ./exachk
Archive: exachk.zip
creating: ./exachk/.cgrep/
inflating: ./exachk/.cgrep/versions.dat
...
inflating: ./exachk/UserGuide.txt
inflating: ./exachk/readme.txt
inflating: ./exachk/doc/ORAchk_and_EXAchk_User_Guide.pdf
[root@v1ex2dbadm01 exachk]#

You’ll now see the tool “exachk” as an executable along with the other files as part of the tool, including the User Guide:

[root@v1ex2dbadm01 exachk]# ls
exachk exachk.zip
[root@v1ex2dbadm01 exachk]# ls -l exachk
total 69792
-r-xr-xr-x 1 root root 8218911 Apr 4 12:12 Apex5_CollectionManager_App.sql
-r-xr-xr-x 1 root root 4816355 Sep 15 2016 CollectionManager_App.sql
-rw-r--r-- 1 root root 47172483 Jul 19 08:38 collections.dat
drwxr-xr-x 2 root root 4096 Sep 5 10:54 doc
-r-xr-xr-x 1 root root 2897015 May 17 20:59 exachk
-rw-r--r-- 1 root root 1976299 Jul 19 09:03 EXAchk_Health_Check_Catalog.html
drwxr-xr-x 2 root root 4096 Jul 19 03:17 exadiscover
-r--r--r-- 1 root root 4896 Mar 31 09:58 readme.txt
-rw-r--r-- 1 root root 6302687 Jul 19 08:38 rules.dat
-r-xr-xr-x 1 root root 40052 Jul 22 2015 sample_user_defined_checks.xml
drwxr-xr-x 2 root root 4096 Jul 19 03:17 templates
-r-xr-xr-x 1 root root 2888 Oct 9 2015 user_defined_checks.xsd
-r--r--r-- 1 root root 234 Apr 1 10:05 UserGuide.txt
[root@v1ex2dbadm01 exachk]# cd exachk
[root@v1ex2dbadm01 exachk]#

To run the tool, simply execute without any switches (there are other options, refer to User Guide):

[root@v1ex2dbadm01 exachk]# ./exachk

Checking for prompts on v1ex2dbadm01 for oracle user...

Checking ssh user equivalency settings on all nodes in cluster

Node v1ex2dbadm02 is configured for ssh user equivalency for root user

Checking for prompts for oracle user on all nodes...

Searching for running databases . . . . .
. . . . . . . . . . . .
List of running databases registered in OCR
1. VERSS
2. VERSDEV
3. VERS24H
4. IONS
5. IONDEV
6. VERSREP
7. All of above
8. None of above

Select databases from list for checking best practices. For multiple databases, select 7 for All or comma separated number like 1,2 etc [1-8][7].7

Searching out ORACLE_HOME for selected databases.

. . . . . . . . . . . . . . . . . . . . . . . .

.
Checking Status of Oracle Software Stack - Clusterware, ASM, RDBMS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .
-------------------------------------------------------------------------------------------------------
 Oracle Stack Status
-------------------------------------------------------------------------------------------------------
Host Name    CRS Installed  RDBMS Installed  CRS UP  ASM UP  RDBMS UP  DB Instance Name
-------------------------------------------------------------------------------------------------------
v1ex2dbadm01 Yes            Yes              Yes     Yes     Yes       IONDEV1 IONS1 VERS24H1 VERSDEV1 VERSREP1 VERSS1
v1ex2dbadm02 Yes            Yes              Yes     Yes     Yes       IONDEV2 IONS2 VERS24H2 VERSDEV2 VERSREP2 VERSS2
-------------------------------------------------------------------------------------------------------

v1ex2cel01 is configured for ssh user equivalency for root user
.
v1ex2cel02 is configured for ssh user equivalency for root user
.
v1ex2cel03 is configured for ssh user equivalency for root user
. . . . . . . . . . . . . . . . . . .
v1ex2sw-ibb01 is configured for ssh user equivalency for root user

v1ex2sw-iba01 is configured for ssh user equivalency for root user

v1ex2sw-ibb01 is configured for ssh user equivalency for root user

*** Checking Best Practice Recommendations (PASS/WARNING/FAIL) ***

Collections and audit checks log file is
/home/oracle/version1/exachk/exachk/exachk_v1ex2dbadm01_VERSREP_090517_105859/log/exachk.log

Checking for prompts in /root/.bash_profile on v1ex2dbadm01 for root user...

Checking for prompts in /root/.bash_profile on v1ex2dbadm02 for root user...

Starting to run exachk in background on v1ex2dbadm02

. .
=============================================================
 Node name - v1ex2dbadm01
=============================================================
. . . . .

Collecting - ASM Disk Group for Infrastructure Software and Configuration
Collecting - ASM Diskgroup Attributes
Collecting - ASM diskgroup usable free space
Collecting - ASM initialization parameters
Collecting - Database Parameters for IONDEV database
Collecting - Database Parameters for IONS database
Collecting - Database Parameters for VERSDEV database
Collecting - Database Parameters for VERSREP database
Collecting - Database Parameters for VERSS database
Collecting - Database Undocumented Parameters for IONDEV database
Collecting - Database Undocumented Parameters for VERSDEV database
Collecting - Database Undocumented Parameters for VERSREP database
Collecting - RDBMS Feature Usage for IONDEV database
Collecting - RDBMS Feature Usage for VERSDEV database
Collecting - RDBMS Feature Usage for VERSREP database
Collecting - CPU Information
Collecting - Clusterware and RDBMS software version
Collecting - Compute node PCI bus slot speed for infiniband HCAs
Collecting - Kernel parameters
Collecting - Maximum number of semaphore sets on system
Collecting - Maximum number of semaphores on system
Collecting - OS Packages
Collecting - Patches for Grid Infrastructure
Collecting - Patches for RDBMS Home
Collecting - RDBMS patch inventory
Collecting - Switch Version Information
Collecting - number of semaphore operations per semop system call
Collecting - CRS user limits configuration
Collecting - CRS user time zone check
Collecting - Check alerthistory for non-test open stateless alerts [Database Server]
Collecting - Check alerthistory for stateful alerts not cleared [Database Server]
Collecting - Check alerthistory for test open stateless alerts [Database Server]
Collecting - Clusterware patch inventory
Collecting - Detect duplicate files in /etc/*init* directories
Collecting - Discover switch type(spine or leaf)
Collecting - Enterprise Manager agent targets
Collecting - Exadata Critical Issue DB09
Collecting - Exadata Critical Issue EX30
Collecting - Exadata software version on database server
Collecting - Exadata system model number
Collecting - Exadata version on database server
Collecting - HCA firmware version on database server
Collecting - HCA transfer rate on database server
Collecting - Infrastructure Software and Configuration for compute
Collecting - MaxStartups setting in sshd_config
Collecting - OFED Software version on database server
Collecting - Obtain hardware information
Collecting - Operating system and Kernel version on database server
Collecting - Oracle monitoring agent and/or OS settings on ADR diagnostic directories
Collecting - Raid controller bus link speed
Collecting - System Event Log
Collecting - Validate key sysctl.conf parameters on database servers
Collecting - Verify Ambient Air Temperature [Database Server]
Collecting - Verify Data Network is Separate from Management Network
Collecting - Verify Database Server Disk Controller Configuration
Collecting - Verify Database Server Physical Drive Configuration
Collecting - Verify Database Server Virtual Drive Configuration
Collecting - Verify Disk Cache Policy on database server
Collecting - Verify Hardware and Firmware on Database and Storage Servers (CheckHWnFWProfile) [Database Server]
Collecting - Verify ILOM Power Up Configuration for HOST_AUTO_POWER_ON
Collecting - Verify ILOM Power Up Configuration for HOST_LAST_POWER_STATE
Collecting - Verify IP routing configuration on database servers
Collecting - Verify InfiniBand Address Resolution Protocol (ARP) Configuration on Database Servers
Collecting - Verify InfiniBand Fabric Topology (verify-topology)
Collecting - Verify InfiniBand subnet manager is not running on database server
Collecting - Verify InfiniBand subnet manager is running on an InfiniBand switch
Collecting - Verify Master (Rack) Serial Number is Set [Database Server]
Collecting - Verify NTP configuration on database servers
Collecting - Verify Quorum disks configuration
Collecting - Verify RAID Controller Battery Temperature [Database Server]
Collecting - Verify RAID disk controller CacheVault capacitor condition [Database Server]
Collecting - Verify TCP Segmentation Offload (TSO) is set to off
Collecting - Verify active kernel version matches expected version for installed Exadata Image
Collecting - Verify basic Logical Volume(LVM) system devices configuration
Collecting - Verify database server disk controllers use writeback cache
Collecting - Verify database server file systems have Check interval = 0
Collecting - Verify database server file systems have Maximum mount count = -1
Collecting - Verify imageinfo on database server
Collecting - Verify imageinfo on database server to compare systemwide
Collecting - Verify key InfiniBand fabric error counters are not present
Collecting - Verify no database server kernel out of memory errors
Collecting - Verify service exachkcfg autostart status on database server
Collecting - Verify that the SDP over IB option sdp_apm_enable is set to 0
Collecting - Verify the localhost alias is pingable [Database Server]
Collecting - Verify the Name Service Cache Daemon (NSCD) is Running
Collecting - Verify the file /.updfrm_exact does not exist [Database Server]
Collecting - Verify the grid Infrastructure management database (MGMTDB) does not use hugepages
Collecting - Verify the vm.min_free_kbytes configuration
Collecting - root time zone check
Collecting - verify asr exadata configuration check via ASREXACHECK on database server

Starting to run root privileged commands in background on STORAGE SERVER v1ex2cel01 (10.1.11.15)

Starting to run root privileged commands in background on STORAGE SERVER v1ex2cel02 (10.1.11.17)

Starting to run root privileged commands in background on STORAGE SERVER v1ex2cel03 (10.1.11.19)

Starting to run root privileged commands in background on INFINIBAND SWITCH v1ex2sw-ibb01

Starting to run root privileged commands in background on INFINIBAND SWITCH v1ex2sw-iba01

Collections from STORAGE SERVER:
----------------------------------
Collecting - Exadata Critical Issue EX10
Collecting - Exadata Critical Issue EX11
Collecting - Exadata Critical Issue EX22
Collecting - Exadata Critical Issue EX28
Collecting - Exadata Critical Issue EX31
Collecting - Exadata critical issue EX14
Collecting - Exadata critical issue EX16
Collecting - Exadata critical issue EX17
Collecting - Exadata critical issue EX23
Collecting - Exadata critical issue EX24
Collecting - Exadata software version on storage server
Collecting - Exadata software version on storage servers
Collecting - Exadata storage server system model number
Collecting - Infrastructure Software and Configuration for storage
Collecting - RAID controller version on storage servers
Collecting - Verify Ambient Air Temperature [Storage Server]
Collecting - Verify Disk Cache Policy on storage servers
Collecting - Verify Exadata Smart Flash Cache is created
Collecting - Verify Hardware and Firmware on Database and Storage Servers (CheckHWnFWProfile) [Storage Server]
Collecting - Verify ILOM Power Up Configuration for HOST_AUTO_POWER_ON on storage servers
Collecting - Verify ILOM Power Up Configuration for HOST_LAST_POWER_STATE on storage servers
Collecting - Verify InfiniBand subnet manager is not running on storage server
Collecting - Verify Master (Rack) Serial Number is Set [Storage Server]
Collecting - Verify NTP configuration on storage servers
Collecting - Verify OSSCONF/cellinit.ora consistency across storage servers
Collecting - Verify RAID Controller Battery Temperature [Storage Server]
Collecting - Verify RAID disk controller CacheVault capacitor condition [Storage Server]
Collecting - Verify Storage Server user CELLDIAG exists
Collecting - Verify active system values match those defined in configuration file cell.conf [Storage Server]
Collecting - Verify data (non-system) disks on Exadata Storage Servers have no partitions
Collecting - Verify imageinfo on storage server
Collecting - Verify imageinfo on storage server to compare systemwide
Collecting - Verify release tracking bug on storage servers
Collecting - Verify service exachkcfg autostart status on storage server
Collecting - Verify storage server disk controllers use writeback cache
Collecting - Verify the localhost alias is pingable [Storage Server]
Collecting - Verify the file /.updfrm_exact does not exist [Storage Server]
Collecting - verify asr exadata configuration check via ASREXACHECK on storage servers
Collecting - Check alerthistory for non-test open stateless alerts [Storage Server]
Collecting - Check alerthistory for stateful alerts not cleared [Storage Server]
Collecting - Check alerthistory for test open stateless alerts [Storage Server]
Collecting - Configure Storage Server alerts to be sent via email
Collecting - Determine storage server type(All Flash/High Capacity)
Collecting - Exadata Celldisk predictive failures
Collecting - Exadata storage server root filesystem free space
Collecting - HCA firmware version on storage server
Collecting - OFED Software version on storage server
Collecting - Operating system and Kernel version on storage server
Collecting - Storage server flash cache mode
Collecting - Storage server make and model
Collecting - Verify Data Network is Separate from Management Network on storage server
Collecting - Verify Datafiles are Placed on Diskgroups consisting of griddisks with correct attributes
Collecting - Verify Ethernet Cable Connection Quality on storage servers
Collecting - Verify ExaWatcher is executing [Storage Server]
Collecting - Verify Exadata Smart Flash Cache is actually in use
Collecting - Verify Exadata Smart Flash Cache status is normal
Collecting - Verify Exadata Smart Flash Log is Created
Collecting - Verify InfiniBand Cable Connection Quality on storage servers
Collecting - Verify average ping times to DNS nameserver [Storage Server]
Collecting - Verify celldisk configuration on disk drives
Collecting - Verify celldisk configuration on flash memory devices
Collecting - Verify griddisk ASM status
Collecting - Verify griddisk count matches across all storage servers where a given prefix name exists
Collecting - Verify storage server metric CD_IO_ST_RQ
Collecting - Verify the percent of available celldisk space used by the griddisks
Collecting - Verify there are no griddisks configured on flash memory devices
Collecting - Verify total number of griddisks with a given prefix name is evenly divisible of celldisks
Collecting - mpt_cmd_retry_count from /etc/modprobe.conf on Storage Servers

Collections from INFINIBAND SWITCH:
------------------------------------
Collecting - Exadata Critical Issue IB5
Collecting - Hostname in /etc/hosts
Collecting - Infiniband Switch NTP configuration
Collecting - Infiniband subnet manager status
Collecting - Infiniband switch HCA status
Collecting - Infiniband switch HOSTNAME configuration
Collecting - Infiniband switch firmware version
Collecting - Infiniband switch health
Collecting - Infiniband switch localtime configuration
Collecting - Infiniband switch module configuration
Collecting - Infiniband switch subnet manager configuration
Collecting - Infiniband switch type(Spine or leaf)
Collecting - Infrastructure Software and Configuration for switch
Collecting - Verify average ping times to DNS nameserver [IB Switch]
Collecting - Verify no IB switch ports disabled due to excessive symbol errors
Collecting - Verify the localhost alias is pingable [IB Switch]
Collecting - sm_priority configuration on Infiniband switch

Data collections completed. Checking best practices on v1ex2dbadm01.
--------------------------------------------------------------------------------------

FAIL => One or more storage servers have stateful alerts that have not been cleared.
FAIL => DB_UNIQUE_NAME on primary has not been modified from the default, confirm that database name is unique across your Oracle enterprise. for VERSDEV
FAIL => DB_UNIQUE_NAME on primary has not been modified from the default, confirm that database name is unique across your Oracle enterprise. for IONDEV
FAIL => DB_UNIQUE_NAME on primary has not been modified from the default, confirm that database name is unique across your Oracle enterprise. for VERSREP
WARNING => Hidden ASM Initialization Parameter usage is not correct
WARNING => ASM parameter AUDIT_SYSLOG_LEVEL should be set to the recommended value
WARNING => Database parameter AUDIT_TRAIL should be set to the recommended value on VERSS1 instance
WARNING => Database parameter AUDIT_TRAIL should be set to the recommended value on IONS1 instance
FAIL => Database parameter _smm_auto_max_io_size should be set to the recommended value on VERSDEV1 instance
FAIL => Database parameter _smm_auto_max_io_size should be set to the recommended value on IONDEV1 instance
FAIL => Database parameter _smm_auto_max_io_size should be set to the recommended value on VERSREP1 instance
WARNING => ASM parameter ASM_POWER_LIMIT is not set to the default value.
FAIL => One or more database servers have stateful alerts that have not been cleared
INFO => Oracle GoldenGate failure prevention best practices
INFO => One or more non-default AWR baselines should be created for VERSDEV
INFO => One or more non-default AWR baselines should be created for IONDEV
INFO => One or more non-default AWR baselines should be created for VERSREP
WARNING => Local archive destination does not alternate destination configured for VERSDEV
WARNING => Local archive destination does not alternate destination configured for IONDEV
WARNING => Local archive destination does not alternate destination configured for VERSREP
WARNING => System has fewer than five storage servers but does not have quorum disks configured on database servers.
INFO => Validate database security configuration using database security assessment tool for VERSS
INFO => Validate database security configuration using database security assessment tool for VERSDEV
INFO => Validate database security configuration using database security assessment tool for IONS
INFO => Validate database security configuration using database security assessment tool for IONDEV
INFO => Validate database security configuration using database security assessment tool for VERSREP
FAIL => System is exposed to Exadata Critical Issue IB5 on infiniband switch v1ex2sw-ibb01
FAIL => System is exposed to Exadata Critical Issue IB5 on infiniband switch v1ex2sw-iba01
FAIL => Oracle monitoring agent and Operating systems settings on Automatic diagnostic repository directories are not correct or not all targets have been scanned or not all diagnostic directories found
FAIL => Database parameter _parallel_adaptive_max_users is not set to recommended value on VERSDEV1 instance
FAIL => Database parameter _parallel_adaptive_max_users is not set to recommended value on IONDEV1 instance
FAIL => Database parameter _parallel_adaptive_max_users is not set to recommended value on VERSREP1 instance
FAIL => Storage Server user "CELLDIAG" should exist
FAIL => Downdelay attribute is not set to recommended value on bonded client interface
FAIL => Database control files are not configured as recommended for VERSS
FAIL => Database control files are not configured as recommended for VERSDEV
FAIL => Database control files are not configured as recommended for IONS
FAIL => Database control files are not configured as recommended for IONDEV
FAIL => Database control files are not configured as recommended for VERSREP
FAIL => One or more of SYSTEM, SYSAUX, USERS, TEMP tablespaces are not of type bigfile for VERSDEV
FAIL => One or more of SYSTEM, SYSAUX, USERS, TEMP tablespaces are not of type bigfile for IONDEV
FAIL => One or more of SYSTEM, SYSAUX, USERS, TEMP tablespaces are not of type bigfile for VERSREP
WARNING => SYS or SYSTEM objects were found to be INVALID for VERSDEV
WARNING => SYS or SYSTEM objects were found to be INVALID for VERSREP
FAIL => All disk groups should have compatible.rdbms attribute set to recommended values
FAIL => Database parameter DB_BLOCK_CHECKSUM is not set to recommended value on VERSS1 instance
FAIL => Database parameter DB_BLOCK_CHECKSUM is not set to recommended value on VERSDEV1 instance
FAIL => Database parameter DB_BLOCK_CHECKSUM is not set to recommended value on IONS1 instance
FAIL => Database parameter DB_BLOCK_CHECKSUM is not set to recommended value on IONDEV1 instance
FAIL => Database parameter DB_BLOCK_CHECKSUM is not set to recommended value on VERSREP1 instance
FAIL => Storage Server alerts are not configured to be sent via email
WARNING => filesystemio_options is not set to recommended value on VERSS1 instance
WARNING => filesystemio_options is not set to recommended value on VERSDEV1 instance
WARNING => filesystemio_options is not set to recommended value on IONS1 instance
WARNING => filesystemio_options is not set to recommended value on IONDEV1 instance
WARNING => filesystemio_options is not set to recommended value on VERSREP1 instance
FAIL => Some data or temp files are not autoextensible for IONDEV
WARNING => Key InfiniBand fabric error counters should not be present
FAIL => Database parameter DB_LOST_WRITE_PROTECT is not set to recommended value on VERSS1 instance
FAIL => Database parameter DB_LOST_WRITE_PROTECT is not set to recommended value on VERSDEV1 instance
FAIL => Database parameter DB_LOST_WRITE_PROTECT is not set to recommended value on IONS1 instance
FAIL => Database parameter DB_LOST_WRITE_PROTECT is not set to recommended value on IONDEV1 instance
FAIL => Database parameter DB_LOST_WRITE_PROTECT is not set to recommended value on VERSREP1 instance
FAIL => Database parameter GLOBAL_NAMES is not set to recommended value on VERSS1 instance
FAIL => Database parameter GLOBAL_NAMES is not set to recommended value on VERSDEV1 instance
FAIL => Database parameter GLOBAL_NAMES is not set to recommended value on IONS1 instance
FAIL => Database parameter GLOBAL_NAMES is not set to recommended value on IONDEV1 instance
FAIL => Database parameter GLOBAL_NAMES is not set to recommended value on VERSREP1 instance
FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value on VERSS1 instance
FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value on VERSDEV1 instance
FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value on IONS1 instance
FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value on IONDEV1 instance
FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value on VERSREP1 instance
FAIL => Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value on VERSS1 instance
FAIL => Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value on VERSDEV1 instance
FAIL => Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value on IONS1 instance
FAIL => Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value on VERSREP1 instance
FAIL => Database parameter OS_AUTHENT_PREFIX is not set to recommended value on VERSS1 instance
FAIL => Database parameter OS_AUTHENT_PREFIX is not set to recommended value on VERSDEV1 instance
FAIL => Database parameter OS_AUTHENT_PREFIX is not set to recommended value on IONS1 instance
FAIL => Database parameter OS_AUTHENT_PREFIX is not set to recommended value on VERSREP1 instance
FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value on VERSS1 instance
FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value on VERSDEV1 instance
FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value on IONS1 instance
FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value on IONDEV1 instance
FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value on VERSREP1 instance
FAIL => Database parameter sql92_security is not set to recommended value on VERSS1 instance
FAIL => Database parameter sql92_security is not set to recommended value on VERSDEV1 instance
FAIL => Database parameter sql92_security is not set to recommended value on IONS1 instance
FAIL => Database parameter sql92_security is not set to recommended value on IONDEV1 instance
FAIL => Database parameter sql92_security is not set to recommended value on VERSREP1 instance
FAIL => ASM parameter CLUSTER_INTERCONNECTS is NOT set to the recommended value
FAIL => Database parameter CLUSTER_INTERCONNECTS is NOT set to the recommended value for VERSDEV
FAIL => Database parameter CLUSTER_INTERCONNECTS is NOT set to the recommended value for VERSREP
FAIL => ASM processes parameter is not set to recommended value
WARNING => Database parameter DB_BLOCK_CHECKING on PRIMARY is NOT set to the recommended value. for VERSDEV
WARNING => Database parameter DB_BLOCK_CHECKING on PRIMARY is NOT set to the recommended value. for IONDEV
WARNING => Database parameter DB_BLOCK_CHECKING on PRIMARY is NOT set to the recommended value. for VERSREP
FAIL => Database parameter DB_BLOCK_CHECKING on STANDBY is NOT set to the recommended value. for VERSS
FAIL => Database parameter DB_BLOCK_CHECKING on STANDBY is NOT set to the recommended value. for IONS
FAIL => Flashback on PRIMARY is not configured for IONDEV
INFO => Operational Best Practices
INFO => Database Consolidation Best Practices
INFO => Computer failure prevention best practices
INFO => Data corruption prevention best practices
INFO => Logical corruption prevention best practices
INFO => Database/Cluster/Site failure prevention best practices
INFO => Client failover operational best practices
WARNING => fast_start_mttr_target should be greater than or equal to 300. on VERSS1 instance
WARNING => fast_start_mttr_target should be greater than or equal to 300. on VERSDEV1 instance
WARNING => fast_start_mttr_target should be greater than or equal to 300. on IONS1 instance
WARNING => fast_start_mttr_target should be greater than or equal to 300. on IONDEV1 instance
WARNING => fast_start_mttr_target should be greater than or equal to 300. on VERSREP1 instance
FAIL => ASM parameter MEMORY_TARGET should be set according to recommended value
FAIL => ASM parameter PGA_AGGREGATE_TARGET should be set according to recommended value
FAIL => ASM parameter MEMORY_MAX_TARGET should be set according to recommended value
INFO => Verify the percent of available celldisk space used by the griddisks
FAIL => Database control files are not configured as recommended for VERSS
FAIL => Database control files are not configured as recommended for VERSDEV
FAIL => Database control files are not configured as recommended for IONS
FAIL => Database control files are not configured as recommended for IONDEV
FAIL => Database control files are not configured as recommended for VERSREP
INFO => While initialization parameter LOG_ARCHIVE_CONFIG is set it should be verified for your environment on Standby Database for VERSS
INFO => While initialization parameter LOG_ARCHIVE_CONFIG is set it should be verified for your environment on Standby Database for IONS
FAIL => Table AUD$[FGA_LOG$] should use Automatic Segment Space Management for VERSDEV
FAIL => Table AUD$[FGA_LOG$] should use Automatic Segment Space Management for VERSREP
INFO => Database failure prevention best practices
FAIL => Primary database is NOT protected with Data Guard (standby database) for real-time data protection and availability for VERSDEV
FAIL => Primary database is NOT protected with Data Guard (standby database) for real-time data protection and availability for IONDEV
FAIL => Primary database is NOT protected with Data Guard (standby database) for real-time data protection and availability for VERSREP
FAIL => Database parameter LOG_BUFFER is not set to recommended value on VERSDEV1 instance
FAIL => Database parameter LOG_BUFFER is not set to recommended value on IONDEV1 instance
FAIL => Database parameter LOG_BUFFER is not set to recommended value on VERSREP1 instance
WARNING => Redo log files should be appropriately sized for IONDEV
WARNING => Redo log files should be appropriately sized for VERSREP
FAIL => No one high redundancy diskgroup configured for VERSDEV
FAIL => No one high redundancy diskgroup configured for IONDEV
FAIL => No one high redundancy diskgroup configured for VERSREP
INFO => Storage failures prevention best practices
INFO => Software maintenance best practices
FAIL => Database parameter DB_FILES should be set to a value greater than or equal to the recommended minimum. on VERSS1 instance
FAIL => Database parameter DB_FILES should be set to a value greater than or equal to the recommended minimum. on VERSDEV1 instance
FAIL => Database parameter DB_FILES should be set to a value greater than or equal to the recommended minimum. on VERSREP1 instance
FAIL => The data files should be recoverable for VERSS
FAIL => Initialization parameter LOG_ARCHIVE_MAX_PROCESSES should be configured as recommended for VERSS
FAIL => Initialization parameter LOG_ARCHIVE_MAX_PROCESSES should be configured as recommended for IONS
FAIL => FRA space management problem file types are present without an RMAN backup completion within the last 7 days. for VERSDEV
FAIL => FRA space management problem file types are present without an RMAN backup completion within the last 7 days. for IONDEV
INFO => Oracle recovery manager(rman) best practices
WARNING => RMAN controlfile autobackup should be set to ON for VERSDEV
WARNING => RMAN controlfile autobackup should be set to ON for IONDEV
INFO => Exadata Critical Issues (Doc ID 1270094.1):- DB1-DB4,DB6,DB9-DB37, EX1-EX26,EX29-EX36 and IB1-IB3,IB5
FAIL => ASM parameter SGA_TARGET is not set according to recommended value.
WARNING => Multiple Oracle database instances discovered, observe database consolidation best practices
FAIL => There should be enough freespace in all diskgroups to reestablish redundancy after a single disk failure
Collecting patch inventory on CRS HOME /u01/app/12.1.0.2/grid
Collecting patch inventory on ASM HOME /u01/app/12.1.0.2/grid
Collecting patch inventory on ORACLE_HOME /u01/app/oracle/product/12.1.0.2/dbhome_1
Collecting patch inventory on ORACLE_HOME /u01/app/oracle/product/12.1.0.2/dbhome_2

Copying results from v1ex2dbadm02 and generating report. This might take a while. Be patient.

. .
=============================================================
 Node name - v1ex2dbadm02
=============================================================
. . . . .

Collecting - CPU Information
Collecting - Clusterware and RDBMS software version
Collecting - Compute node PCI bus slot speed for infiniband HCAs
Collecting - Kernel parameters
Collecting - Maximum number of semaphore sets on system
Collecting - Maximum number of semaphores on system
Collecting - OS Packages
Collecting - Patches for Grid Infrastructure
Collecting - Patches for RDBMS Home
Collecting - RDBMS patch inventory
Collecting - number of semaphore operations per semop system call
Collecting - CRS user limits configuration
Collecting - CRS user time zone check
Collecting - Check alerthistory for non-test open stateless alerts [Database Server]
Collecting - Check alerthistory for stateful alerts not cleared [Database Server]
Collecting - Check alerthistory for test open stateless alerts [Database Server]
Collecting - Clusterware patch inventory
Collecting - Detect duplicate files in /etc/*init* directories
Collecting - Enterprise Manager agent targets
Collecting - Exadata Critical Issue DB09
Collecting - Exadata Critical Issue EX30
Collecting - Exadata software version on database server
Collecting - Exadata system model number
Collecting - Exadata version on database server
Collecting - HCA firmware version on database server
Collecting - HCA transfer rate on database server
Collecting - Infrastructure Software and Configuration for compute
Collecting - MaxStartups setting in sshd_config
Collecting - OFED Software version on database server
Collecting - Obtain hardware information
Collecting - Operating system and Kernel version on database server
Collecting - Oracle monitoring agent and/or OS settings on ADR diagnostic directories
Collecting - Raid controller bus link speed
Collecting - System Event Log
Collecting - Validate key sysctl.conf parameters on database servers
Collecting - Verify Ambient Air Temperature [Database Server]
Collecting - Verify Data Network is Separate from Management Network
Collecting - Verify Database Server Disk Controller Configuration
Collecting - Verify Database Server Physical Drive Configuration
Collecting - Verify Database Server Virtual Drive Configuration
Collecting - Verify Disk Cache Policy on database server
Collecting - Verify Hardware and Firmware on Database and Storage Servers (CheckHWnFWProfile) [Database Server]
Collecting - Verify ILOM Power Up Configuration for HOST_AUTO_POWER_ON
Collecting - Verify ILOM Power Up Configuration for HOST_LAST_POWER_STATE
Collecting - Verify IP routing configuration on database servers
Collecting - Verify InfiniBand Address Resolution Protocol (ARP) Configuration on Database Servers
Collecting - Verify InfiniBand subnet manager is not running on database server
Collecting - Verify Master (Rack) Serial Number is Set [Database Server]
Collecting - Verify NTP configuration on database servers
Collecting - Verify Quorum disks configuration
Collecting - Verify RAID Controller Battery Temperature [Database Server]
Collecting - Verify RAID disk controller CacheVault capacitor condition [Database Server]
Collecting - Verify TCP Segmentation Offload (TSO) is set to off
Collecting - Verify active kernel version matches expected version for installed Exadata Image
Collecting - Verify basic Logical Volume(LVM) system devices configuration
Collecting - Verify database server disk controllers use writeback cache
Collecting - Verify database server file systems have Check interval = 0
Collecting - Verify database server file systems have Maximum mount count = -1
Collecting - Verify imageinfo on database server
Collecting - Verify imageinfo on database server to compare systemwide
Collecting - Verify no database server kernel out of memory errors
Collecting - Verify service exachkcfg autostart status on database server
Collecting - Verify that the SDP over IB option sdp_apm_enable is set to 0
Collecting - Verify the localhost alias is pingable [Database Server]
Collecting - Verify the Name Service Cache Daemon (NSCD) is Running
Collecting - Verify the file /.updfrm_exact does not exist [Database Server]
Collecting - Verify the grid Infrastructure management database (MGMTDB) does not use hugepages
Collecting - Verify the vm.min_free_kbytes configuration
Collecting - root time zone check
Collecting - verify asr exadata configuration check via ASREXACHECK on database server

Data collections completed. Checking best practices on v1ex2dbadm02.
--------------------------------------------------------------------------------------

WARNING => Hidden ASM Initialization Parameter usage is not correct
WARNING => ASM parameter AUDIT_SYSLOG_LEVEL should be set to the recommended value
WARNING => Database parameter AUDIT_TRAIL should be set to the recommended value on VERSS2 instance
WARNING => Database parameter AUDIT_TRAIL should be set to the recommended value on IONS2 instance
FAIL => Database parameter _smm_auto_max_io_size should be set to the recommended value on VERSDEV2 instance
FAIL => Database parameter _smm_auto_max_io_size should be set to the recommended value on IONDEV2 instance
FAIL => Database parameter _smm_auto_max_io_size should be set to the recommended value on VERSREP2 instance
WARNING => ASM parameter ASM_POWER_LIMIT is not set to the default value.
INFO => Oracle GoldenGate failure prevention best practices
WARNING => Local archive destination does not alternate destination configured for VERSDEV
WARNING => Local archive destination does not alternate destination configured for IONDEV
WARNING => Local archive destination does not alternate destination configured for VERSREP
WARNING => System has fewer than five storage servers but does not have quorum disks configured on database servers.
INFO => Validate database security configuration using database security assessment tool for VERSS
INFO => Validate database security configuration using database security assessment tool for VERSDEV
INFO => Validate database security configuration using database security assessment tool for IONS
INFO => Validate database security configuration using database security assessment tool for IONDEV
INFO => Validate database security configuration using database security assessment tool for VERSREP
FAIL => Oracle monitoring agent and Operating systems settings on Automatic diagnostic repository directories are not correct or not all targets have been scanned or not all diagnostic directories found
FAIL => Database parameter _parallel_adaptive_max_users is not set to recommended value on VERSDEV2 instance
FAIL => Database parameter _parallel_adaptive_max_users is not set to recommended value on IONDEV2 instance
FAIL => Database parameter _parallel_adaptive_max_users is not set to recommended value on VERSREP2 instance
FAIL => Downdelay attribute is not set to recommended value on bonded client interface
FAIL => Database control files are not configured as recommended for VERSS
FAIL => Database control files are not configured as recommended for VERSDEV
FAIL => Database control files are not configured as recommended for IONS
FAIL => Database control files are not configured as recommended for IONDEV
FAIL => Database control files are not configured as recommended for VERSREP
FAIL => One or more of SYSTEM, SYSAUX, USERS, TEMP tablespaces are not of type bigfile for VERSDEV
FAIL => One or more of SYSTEM, SYSAUX, USERS, TEMP tablespaces are not of type bigfile for IONDEV
FAIL => One or more of SYSTEM, SYSAUX, USERS, TEMP tablespaces are not of type bigfile for VERSREP
FAIL => Database parameter DB_BLOCK_CHECKSUM is not set to recommended value on VERSS2 instance
FAIL => Database parameter DB_BLOCK_CHECKSUM is not set to recommended value on VERSDEV2 instance
FAIL => Database parameter DB_BLOCK_CHECKSUM is not set to recommended value on IONS2 instance
FAIL => Database parameter DB_BLOCK_CHECKSUM is not set to recommended value on IONDEV2 instance
FAIL => Database parameter DB_BLOCK_CHECKSUM is not set to recommended value on VERSREP2 instance
WARNING => filesystemio_options is not set to recommended value on VERSS2 instance
WARNING => filesystemio_options is not set to recommended value on VERSDEV2 instance
WARNING => filesystemio_options is not set to recommended value on IONS2 instance
WARNING => filesystemio_options is not set to recommended value on IONDEV2 instance
WARNING => filesystemio_options is not set to recommended value on VERSREP2 instance
FAIL => ASM Audit file destination file count > 100,000
FAIL => Database parameter DB_LOST_WRITE_PROTECT is not set to recommended value on VERSS2 instance
FAIL => Database parameter DB_LOST_WRITE_PROTECT is not set to recommended value on VERSDEV2 instance
FAIL => Database parameter DB_LOST_WRITE_PROTECT is not set to recommended value on IONS2 instance
FAIL => Database parameter DB_LOST_WRITE_PROTECT is not set to recommended value on IONDEV2 instance
FAIL => Database parameter DB_LOST_WRITE_PROTECT is not set to recommended value on VERSREP2 instance
FAIL => Database parameter GLOBAL_NAMES is not set to recommended value on VERSS2 instance
FAIL => Database parameter GLOBAL_NAMES is not set to recommended value on VERSDEV2 instance
FAIL => Database parameter GLOBAL_NAMES is not set to recommended value on IONS2 instance
FAIL => Database parameter GLOBAL_NAMES is not set to recommended value on IONDEV2 instance
FAIL => Database parameter GLOBAL_NAMES is not set to recommended value on VERSREP2 instance
FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value on VERSS2 instance
FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value on VERSDEV2 instance
FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value on IONS2 instance
FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value on IONDEV2 instance
FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value on VERSREP2 instance
FAIL => Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value on VERSS2 instance
FAIL => Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value on VERSDEV2 instance
FAIL => Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value on IONS2 instance
FAIL => Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value on VERSREP2 instance
FAIL => Database parameter OS_AUTHENT_PREFIX is not set to recommended value on VERSS2 instance
FAIL => Database parameter OS_AUTHENT_PREFIX is not set to recommended value on VERSDEV2 instance
FAIL => Database parameter OS_AUTHENT_PREFIX is not set to recommended value on IONS2 instance
FAIL => Database parameter OS_AUTHENT_PREFIX is not set to recommended value on VERSREP2 instance
FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value on VERSS2 instance
FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value on VERSDEV2 instance
FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value on IONS2 instance
FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value on IONDEV2 instance
FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value on VERSREP2 instance
FAIL => Database parameter sql92_security is not set to recommended value on VERSS2 instance
FAIL => Database parameter sql92_security is not set to recommended value on VERSDEV2 instance
FAIL => Database parameter sql92_security is not set to recommended value on IONS2 instance
FAIL => Database parameter sql92_security is not set to recommended value on IONDEV2 instance
FAIL => Database parameter sql92_security is not set to recommended value on VERSREP2 instance
FAIL => ASM parameter CLUSTER_INTERCONNECTS is NOT set to the recommended value
FAIL => Database parameter CLUSTER_INTERCONNECTS is NOT set to the recommended value for VERSDEV
FAIL => Database parameter CLUSTER_INTERCONNECTS is NOT set to the recommended value for VERSREP
FAIL => ASM processes parameter is not set to recommended value
WARNING => Database parameter DB_BLOCK_CHECKING on PRIMARY is NOT set to the recommended value. for VERSDEV
WARNING => Database parameter DB_BLOCK_CHECKING on PRIMARY is NOT set to the recommended value. for IONDEV
WARNING => Database parameter DB_BLOCK_CHECKING on PRIMARY is NOT set to the recommended value. for VERSREP
FAIL => Database parameter DB_BLOCK_CHECKING on STANDBY is NOT set to the recommended value. for VERSS
FAIL => Database parameter DB_BLOCK_CHECKING on STANDBY is NOT set to the recommended value. for IONS
WARNING => fast_start_mttr_target should be greater than or equal to 300. on VERSS2 instance
WARNING => fast_start_mttr_target should be greater than or equal to 300. on VERSDEV2 instance
WARNING => fast_start_mttr_target should be greater than or equal to 300. on IONS2 instance
WARNING => fast_start_mttr_target should be greater than or equal to 300. on IONDEV2 instance
WARNING => fast_start_mttr_target should be greater than or equal to 300. on VERSREP2 instance
FAIL => ASM parameter MEMORY_TARGET should be set according to recommended value
FAIL => ASM parameter PGA_AGGREGATE_TARGET should be set according to recommended value
FAIL => ASM parameter MEMORY_MAX_TARGET should be set according to recommended value
FAIL => Database control files are not configured as recommended for VERSS
FAIL => Database control files are not configured as recommended for VERSDEV
FAIL => Database control files are not configured as recommended for IONS
FAIL => Database control files are not configured as recommended for IONDEV
FAIL => Database control files are not configured as recommended for VERSREP
INFO => While initialization parameter LOG_ARCHIVE_CONFIG is set it should be verified for your environment on Standby Database for VERSS
INFO => While initialization parameter LOG_ARCHIVE_CONFIG is set it should be verified for your environment on Standby Database for IONS
FAIL => Database parameter LOG_BUFFER is not set to recommended value on VERSDEV2 instance
FAIL => Database parameter LOG_BUFFER is not set to recommended value on IONDEV2 instance
FAIL => Database parameter LOG_BUFFER is not set to recommended value on VERSREP2 instance
WARNING => Redo log files should be appropriately sized for IONDEV
WARNING => Redo log files should be appropriately sized for VERSREP
FAIL => Database parameter DB_FILES should be set to a value greater than or equal to the recommended minimum. on VERSS2 instance
FAIL => Database parameter DB_FILES should be set to a value greater than or equal to the recommended minimum. on VERSDEV2 instance
FAIL => Database parameter DB_FILES should be set to a value greater than or equal to the recommended minimum. on VERSREP2 instance
FAIL => Initialization parameter LOG_ARCHIVE_MAX_PROCESSES should be configured as recommended for VERSS
FAIL => Initialization parameter LOG_ARCHIVE_MAX_PROCESSES should be configured as recommended for IONS
FAIL => ASM parameter SGA_TARGET is not set according to recommended value.
WARNING => Multiple Oracle database instances discovered, observe database consolidation best practices
Collecting patch inventory on CRS HOME /u01/app/12.1.0.2/grid
Collecting patch inventory on ASM HOME /u01/app/12.1.0.2/grid
Collecting patch inventory on ORACLE_HOME /u01/app/oracle/product/12.1.0.2/dbhome_1
Collecting patch inventory on ORACLE_HOME /u01/app/oracle/product/12.1.0.2/dbhome_2

---------------------------------------------------------------------------------
 CLUSTERWIDE CHECKS
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------

Detailed report (html) - /home/oracle/version1/exachk/exachk/exachk_v1ex2dbadm01_VERSREP_090517_105859/exachk_v1ex2dbadm01_VERSREP_090517_105859.html
UPLOAD(if required) - /home/oracle/version1/exachk/exachk/exachk_v1ex2dbadm01_VERSREP_090517_105859.zip

[root@v1ex2dbadm01 exachk]#

Once completed, you’ll see a new folder and zip file, I recommend moving them both up a level to safe keeping:

[root@v1ex2dbadm01 exachk]# ls -ltrh
total 75M
-r-xr-xr-x 1 root root 40K Jul 22 2015 sample_user_defined_checks.xml
-r-xr-xr-x 1 root root 2.9K Oct 9 2015 user_defined_checks.xsd
-r-xr-xr-x 1 root root 4.6M Sep 15 2016 CollectionManager_App.sql
-r--r--r-- 1 root root 4.8K Mar 31 09:58 readme.txt
-r--r--r-- 1 root root 234 Apr 1 10:05 UserGuide.txt
-r-xr-xr-x 1 root root 7.9M Apr 4 12:12 Apex5_CollectionManager_App.sql
-r-xr-xr-x 1 root root 2.8M May 17 20:59 exachk
drwxr-xr-x 2 root root 4.0K Jul 19 03:17 templates
drwxr-xr-x 2 root root 4.0K Jul 19 03:17 exadiscover
-rw-r--r-- 1 root root 45M Jul 19 08:38 collections.dat
-rw-r--r-- 1 root root 6.1M Jul 19 08:38 rules.dat
-rw-r--r-- 1 root root 1.9M Jul 19 09:03 EXAchk_Health_Check_Catalog.html
drwxr-xr-x 2 root root 4.0K Sep 5 10:54 doc
drwxr-xr-x 8 root root 180K Sep 5 11:18 exachk_v1ex2dbadm01_VERSREP_090517_105859
-rw-r--r-- 1 root root 5.9M Sep 5 11:19 exachk_v1ex2dbadm01_VERSREP_090517_105859.zip
[root@v1ex2dbadm01 exachk]# mv exachk_* ..
[root@v1ex2dbadm01 exachk]# cd ..
[root@v1ex2dbadm01 exachk]# ls -ltrh
total 25M
-rw-r--r-- 1 root root 19M Sep 5 10:51 exachk.zip
drwxr-xr-x 8 root root 180K Sep 5 11:18 exachk_v1ex2dbadm01_VERSREP_090517_105859
-rw-r--r-- 1 root root 5.9M Sep 5 11:19 exachk_v1ex2dbadm01_VERSREP_090517_105859.zip
drwxr-xr-x 6 root root 4.0K Sep 5 11:29 exachk
[root@v1ex2dbadm01 exachk]#

In the new folder you’ll see a html file, which is the report produced by exachk:

[root@v1ex2dbadm01 exachk]# cd exachk_v1ex2dbadm01_VERSREP_090517_105859
[root@v1ex2dbadm01 exachk_v1ex2dbadm01_VERSREP_090517_105859]# ls -ltrh
total 6.4M
-rw-r--r-- 1 root root 762 Sep 5 11:02 targets.xsl
drwxr-xr-x 2 root root 4.0K Sep 5 11:18 upload
drwxr-xr-x 4 root root 100K Sep 5 11:18 outfiles
drwxr-xr-x 2 root root 4.0K Sep 5 11:18 reports
-rw-r--r-- 1 root root 6.2M Sep 5 11:18 exachk_v1ex2dbadm01_VERSREP_090517_105859.html
drwxr-xr-x 2 root root 48K Sep 5 11:19 scripts
drwxr-xr-x 2 root root 4.0K Sep 5 11:19 log
[root@v1ex2dbadm01 exachk_v1ex2dbadm01_VERSREP_090517_105859]#

It’s normally easier to copy the zip file off the compute node to your machine and then unzip and view the report local.

It will look like this:

exchk

Known Issues

1. Running ExaChk reset snmpd.conf and iptables on Storage Cells.  There’s a bug currently open with Oracle Support for this:
Bug 26742216 – EXACHK IS RESETTING IPTABLES AND IT IS BLOCKING SNMP CONNECTIONS UNTIL RESTART

Which hasn’t yet been fixed.  See my blog post with discuss how to fix this after Exadata Patching where this also happens:
SNMP unresponsive on Storage Cell after Exadata Patching

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)