Twitter

Showing posts with label ASM. Show all posts
Showing posts with label ASM. Show all posts

Exadata: resize (increase and decrease) ASM diskgroups

Disk space is scarce -- always. It is true that when one buys an Exadata for example, he is told that there is 750 TB of disk space which looks huge (almost infinite ?) at first sight but this quickly drops to only 250 TB when in HIGH redundancy and even less than that if you use some for RECO and you then often have to juggle with disk space between disk groups. Hopefully, this juggling challenge is pretty easy and, most importantely, online !

Before jumping into the procedure describing how to increase/decrease a diskgroup size, one need to understand some Exadata storage concepts and vocabulary:
  • Each storage sever (aka cell) has 12 disks (except Extreme Flash which has 8 disks) -- you can remember this one, it has been a question in any Exadata certification I took :)
  • This means that on a 5 cells configuration, you will have 5*12=60 physical disks (of 12TB each for example on a X8 thus 12*60=720 TB)
  • Each of the 12 physical disk in a cell is called a cell disk (makes sense, it is a disk in a cell :)); cell disks are numbered from 0 to 11
  • When you allocate some space on a cell disk for a diskgroup, a slice on each cell disk is taken, this is called a grid disk
  • And ASM uses theses grid disks as ASM disks in its diskgroup and manages the redundancy you want (or "the redundancy you have inherited from a default installation" may be more accurate here :))

Following my previous explanations, let's start by having a look at the available disk space on the celll disks before increasing a RECOPROD diskgroup (this has to be done from a physical database node or a dom0/KVM Host if you use virtualization):
[root@exa01db01 ]# dcli -g ~/cell_group -l root "cellcli -e list celldisk attributes name,size,status,freespace where name like \'CD_.*\'"
exa01cel01: CD_00_exa01cel01     12.4737091064453125T    normal  1.409210205078125T
exa01cel01: CD_01_exa01cel01     12.4737091064453125T    normal  1.409210205078125T
. . .
exa01cel05: CD_10_exa01cel05     12.4737091064453125T    normal  1.409210205078125T
exa01cel05: CD_11_exa01cel05     12.4737091064453125T    normal  1.409210205078125T
[root@exa01db01 ]# 
Very cool, 1.4 TB free on each cell disk, this is plenty of available space !

Note that I use the where name like syntax to only show the CD_* disks which are the Cell Disks and not the FD_* which are the Flash Disks nor the PM_* which are the Persistent memory.

Let's look at the size of the current grid disks for this diskgroup:
[root@exa01db01 ]#  dcli -g ~/cell_group -l root "cellcli -e list griddisk attributes name,size,status where name like \'RECOPROD.*\'"
exa01cel01: RECOPROD_CD_00_exa01cel01     32G    active
exa01cel01: RECOPROD_CD_01_exa01cel01     32G    active
. . .
exa01cel05: RECOPROD_CD_10_exa01cel05     32G    active
exa01cel05: RECOPROD_CD_11_exa01cel05     32G    active
[root@exa01db01 ]# 
RECOPROD currently has 32GB grid disks which means that RECOPROD (let's say it is NORMAL redundancy) is ... 32*12*5/2 = ... ? (let's use this opportunity to show a bit of bc here)
32 => each grid disk is 32 GB
12 => each cell has 12 disks
5  => our system has 5 cells
2  => we divide by 2 as the diskgroup is NORMAL redundancy
[root@exa01db01 ]#  echo "32*12*5/2" | bc
960
[root@exa01db01 ]# 
So the current size of our RECOPROD is 960 GB; it is indeed not that big. Question now is how big should each grid disk be if we would like to have a 15 TB NORNMAL redundancy RECOPROD diskgroup ?
[root@exa01db01 ]# echo "15*1024*2/5/12" | bc
512
[root@exa01db01 ]# 
512 GB it is; we know we have enough space available on the cell disks, we can increase the size of all the grid disks:
[root@exa01db01 ]# dcli -g ~/cell_group -l root "cellcli -e alter griddisk size=512G where name like \'RECOPROD.*\'"
exa01cel01: GridDisk RECOPROD_CD_00_exa01cel01 successfully altered
exa01cel01: GridDisk RECOPROD_CD_01_exa01cel01 successfully altered
. . .
exa01cel05: GridDisk RECOPROD_CD_10_exa01cel05 successfully altered
exa01cel05: GridDisk RECOPROD_CD_11_exa01cel05 successfully altered
[root@exa01db01 ]#
And then we can increase the ASM disks (this has to be done connected to the ASM instance so on a VM or on a physical database node):
[oracle@exa01db01:~]$ sqlplus / as sysasm
SQL> alter diskgroup RECOPROD resize all size 512G rebalance power 64 ;
Diskgroup altered.
Elapsed: 00:00:02.62
SQL>
Note that this will trigger a rebalance operation which you want to monitore using select * from gv$asm_operation. Also note that 64 is an aggressive rebalance power, you may want to reduce it to 8 or 16 if you are doing this live during heavy production hours. Once the rebalance is done, you are done !
[root@exa01db01 ~]# ./asmdu.sh   <== asmdu.sh available here
Instances running on exa01db01 : +ASM1, PROD1, PROD2, BLABLA1, APP1, REPORT1
        DiskGroup      Redundancy        Total TB       Usable TB        % Free
        ---------     -----------        --------       ---------        ------
        DATAPROD        HIGH              150.01          100.03          33
        RECOPROD        NORMAL             15.00            0.50          99
[root@exa01db01 ~]#
That was easy; now how can we decrease the size of this RECOPROD ? just by doing the opposite:
[oracle@exa01db01:~]$ sqlplus / as sysasm
SQL> alter diskgroup RECOPROD resize all size 32G rebalance power 64 ;
SQL> select * from gv$asm_operation ;
[root@exa01db01 ]# dcli -g ~/cell_group -l root "cellcli -e alter griddisk size=32G where name like \'RECOPROD.*\'"
That's it for today, one more string in our Exadata bow !

Grid Infrastructure Out of Place Patching (aka GI OOP)

Out of Place patching has become the standard for database patching for years now (I have described it precisely here) but for any reason, people restrain themselves for doing Out of Place patching for Grid Infrastructure and usually do In Place GI patching and Out of Place GI upgrade (you cannot do In Place upgrade :)). I will describe below how to easily perform GI OOP.

To start on the right foot, a quick reminder of the concept and the required steps of an Out of Place patching:
  1. Your system is running on a source version home let's say /u01/app/19.0.0.0/grid
  2. You prepare the future alread patched target home let's say /u01/app/19.11.0.0/grid
  3. The day of the maintenance, you stop what is running on the source home and restart on the target home
  4. If, for any reason, something goes wrong, you just have to restart everything on the source home
This can be represented with the below image:






For the purpose of this blog, I will use the below homes in the examples:
  • The source GI home: /u01/app/19.0.0.0/grid
  • The target GI Home: /u01/app/19.11.0.0/grid

1. Prepare your target home

Preparing the target home is to prepare a GI home with the patches you will want to use; here, I will go with GI 19.11 with the latest opatch, the latest GI JDK and patch 31602782. To achieve this, you can clone a source GI Home or, what I prefer and recommend, to create a gold image of your target home. Oracle has/had a note with a list of already prepared gold image per version but this note has kind of disappeared recently so I gave up on that one. Also, building your own gold image is easy and very good to know how all of that works. To build my target GI 19.11 gold image, you first need to get:
  • The base GI 19c version which is 19.3: GI_gold_193_V982068-01.zip -- from edelivery.oracle.com
  • The GI 19.11 patch: GI_1911_p32545008_190000_Linux-x86-64.zip
  • The latest opatch: opatch_p6880880_122010_Linux-x86-64.zip
  • The latest GIJDK: GIJDK_April2021_p32490416_190000_Linux-x86-64.zip (this one is no more the latest but it was the latest when I did this gold image)
  • The patch 31602782: p31602782_1911000DBRU_Linux-x86-64.zip
Note: you may want to have a look at this blog to get the notes where to download GI, the critical patches, GI JDK, etc... Note 2: you do not have to apply the latest GI JDK, it is to show that you can apply any one-off patch on top of the RUR in your target gold image -- GI tends to have many critical issues and then patches so better to be know how to deal with it. Here is what it looks like once you have the files on your server:
[root@target gioop]# pwd
/u01/stage/gioop
[root@target gioop]# ls -ltr
GI_1911_p32545008_190000_Linux-x86-64.zip               <= GI 19.11 patch
GIJDK_April2021_p32490416_190000_Linux-x86-64.zip       <= April JDK
opatch_p6880880_122010_Linux-x86-64.zip                 <= Latest opatch
GI_gold_193_V982068-01.zip                              <= GI gold image
p31602782_1911000DBRU_Linux-x86-64.zip                  <= Patch 31602782
[root@target gioop]#
Unzip the 19.3 gold image:
[root@target gioop]# mkdir temp
[root@target gioop]# unzip -q GI_gold_193_V982068-01.zip -d temp/.
[root@target gioop]#
Unzip the GI JDK and the 31602782 patch (any number of one-off patches):
[root@target gioop]# unzip -o -q GIJDK_April2021_p32490416_190000_Linux-x86-64.zip
[root@target gioop]# unzip -o -q p31602782_1911000DBRU_Linux-x86-64.zip
[root@target gioop]#
Very importantly, all needs to be done as the oracle (grid owner) user (not root) so give the correct permissions and you should have the below situation:
[root@target gioop]# chown -R oracle:oinstall /u01/stage/gioop
[root@target gioop]# ls -ltr
oracle oinstall       4096 Apr 20 07:17 32545008                                           <= GI 19.11 patch
oracle oinstall       2477 Apr 22 16:16 PatchSearch.xml
oracle oinstall 2523672126 May  7 11:28 GI_1911_p32545008_190000_Linux-x86-64.zip
oracle oinstall  125203135 May  7 11:28 GIJDK_April2021_p32490416_190000_Linux-x86-64.zip
oracle oinstall  120761121 May  7 11:28 opatch_p6880880_122010_Linux-x86-64.zip
oracle oinstall 2889184573 May  7 12:26 GI_gold_193_V982068-01.zip
oracle oinstall       4096 May  7 12:28 temp                                               <= GI gold image 
oracle oinstall       4096 May  7 12:33 32490416                                           <= GI JDK
oracle oinstall       4096 Apr 25 21:04 31602782                                           <= Patch 31602782
[root@target gioop]#
Start by upgrading opatch to the latest version:
[root@target gioop]# su - oracle
[oracle@target:]/home/oracle => cd /u01/stage/gioop/temp
[oracle@target:]/u01/stage/gioop/temp => ./OPatch/opatch version
OPatch Version: 12.2.0.1.17
OPatch succeeded.
[oracle@target:]/u01/stage/gioop/temp => unzip -o -q ../opatch_p6880880_122010_Linux-x86-64.zip
[oracle@target:]/u01/stage/gioop/temp =>./OPatch/opatch version
OPatch Version: 12.2.0.1.24
OPatch succeeded.
[oracle@target:]/u01/stage/gioop/temp =>
We can now patch the gold image with GI 19.11, the GI JDK and the patch 31602782; we can do all of this in a single command line:
[oracle@target:]/u01/stage/gioop/temp => ./gridSetup.sh -silent -printtime -waitForCompletion -noCopy -applyRU /u01/stage/gioop/32545008 -applyOneOffs /u01/stage/gioop/31602782,/u01/stage/gioop/32490416
Preparing the home to patch...
Applying the patch /u01/stage/gioop/32545008...
Successfully applied the patch.
Applying the patch /u01/stage/gioop/31602782...
Successfully applied the patch.
Applying the patch /u01/stage/gioop/32490416...
Successfully applied the patch.
The log can be found at: /u01/app/oraInventory/logs/GridSetupActions2021-05-07_01-12-59PM/installerPatchActions_2021-05-07_01-12-59PM.log
Launching Oracle Grid Infrastructure Setup Wizard...
[FATAL] [INS-40426] Grid installation option has not been specified.       <== you can ignore this error
   ACTION: Specify the valid installation option.
[oracle@target:]/u01/stage/gioop/temp =>
Before continuing, we need to temporarely attach the home to the system:
[oracle@target:]/home/oracle => /u01/app/19.0.0.0/grid/oui/bin/runInstaller -attachHome ORACLE_HOME=/u01/stage/gioop/temp ORACLE_HOME_NAME=gold_gi1911
Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB.   Actual 24575 MB    Passed
The inventory pointer is located at /etc/oraInst.loc
You can find the log of this install session at:
 /u01/app/oraInventory/logs/AttachHome2021-05-07_01-53-14PM.log
'AttachHome' was successful.
[oracle@target:]/home/oracle =>
Note that you have to attach the home to be able to use opatch and create a gold image but you cannot apply the RU nor the one-off patches if the home is attached:
[oracle@target:]/u01/stage/gioop/temp => ./gridSetup.sh -silent -printtime -waitForCompletion -noCopy -applyRU /u01/stage/gioop/32545008 -applyOneOffs /u01/stage/gioop/31602782,/u01/stage/gioop/32490416
[INS-32826] The software home (/u01/stage/gioop/temp) is already registered in the central inventory. Refer to patch readme instructions on how to apply.
[oracle@target:]/u01/stage/gioop/temp =>
We now have a prepared target home with our target version located in a temporary directory. We can verify the list of patch of our home:
[oracle@target:]/u01/stage/gioop/temp => ./OPatch/opatch lspatches -oh /u01/stage/gioop/temp
31602782;SAME INSTANCE SLAVE PARSE FAILURE FLOOD CONTROL
32490416;JDK BUNDLE PATCH 19.0.0.0.210420
32585572;DBWLM RELEASE UPDATE 19.0.0.0.0 (32585572)
32584670;TOMCAT RELEASE UPDATE 19.0.0.0.0 (32584670)
32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)
32576499;ACFS RELEASE UPDATE 19.11.0.0.0 (32576499)
32545013;Database Release Update : 19.11.0.0.210420 (32545013)

OPatch succeeded.
[oracle@target:]/u01/stage/gioop/temp =>
We will now create our own gold image which we could easily copy and deploy on all the other systems (dev, qa, dr, prod, etc ...):
[oracle@target:]/u01/stage/gioop/temp =>  ./gridSetup.sh -silent -createGoldImage -destinationLocation /u01/stage/gioop/
Launching Oracle Grid Infrastructure Setup Wizard...
Successfully Setup Software.
Gold Image location: /u01/stage/gioop/grid_home_2021-05-07_01-59-02PM.zip
[oracle@target:]/u01/stage/gioop/temp =>
You can now save the prepared gold image /u01/stage/gioop/grid_home_2021-05-07_01-59-02PM.zip on a central repository server as this is the image you will be usng on all your systems -- this is your future GI !

To keep your systems clean, let's detach the temporary home:
[oracle@target:]/u01/stage/gioop/temp => /u01/app/19.0.0.0/grid/oui/bin/runInstaller -detachHome ORACLE_HOME=/u01/stage/gioop/temp ORACLE_HOME_NAME=gold_gi1911
Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB.   Actual 24575 MB    Passed
The inventory pointer is located at /etc/oraInst.loc
[oracle@target:]/u01/stage/gioop/temp =>


2.Switch the home

Create the target GI directory on all the servers
[root@exadb01 ~]# cat ~/dbs_group
exadb01
exadb02
. . .
exadb08
[root@exadb01 ~]# dcli -g ~/dbs_group -l root "df -h /u01"
Filesystem                    Size  Used Avail Use% Mounted on
exad01: /dev/mapper/VGExaDb-LVDbOra1  250G  125G  125G  50% /u01          <= check that you have enough disk space on each node
. . .
[root@exadb01 ~]# dcli -g ~/dbs_group -l root "mkdir -p /u01/app/19.11.0.0/grid; chown -R oracle:oinstall /u01/app/19.11.0.0/grid"
[root@exadb01 ~]# 
Unzip the previously prepared goldimage (only on one node !)
[oracle@exadb01:]/home/oracle => unzip -q /u01/stage/gioop/GI_gold_1911_2021-05-07_01-59-02PM.zip -d /u01/app/19.11.0.0/grid
[oracle@exadb01:]/home/oracle => dcli -g ~/dbs_group -l oracle "du -sh /u01/app/19.11.0.0/grid"
exadb01: 9.9G      /u01/app/19.11.0.0/grid      <== your gold image unzipped here 
exadb02: 4.0K      /u01/app/19.11.0.0/grid      <== empty directory here
. . .
exadb08: 4.0K      /u01/app/19.11.0.0/grid<     <== empty directory here
[oracle@exadb01:]/home/oracle =>
Something important here to aboid issues during the patch process; verify that the ASM passwordfile and the ASM spfile is located under ASM (if not, you'll find a quick procedure here on how to move them to ASM):
[root@exadb01 ~]# . oraenv <<< +ASM1
ORACLE_SID = [root] ? The Oracle base has been set to /u01/app/oracle
[root@exadb01 ~]# asmcmd spget
+DATA/mycluster/ASMPARAMETERFILE/registry.253.1045914043
[root@exadb01 ~]# asmcmd pwget --asm
+DATA/orapwASM
[root@exadb01 ~]#
Prepare a responsefile such as this one:
[oracle@exadb01:+ASM1]/home/oracle => cat /u01/stage/gioop/1911oop_response.rsp
oracle.install.responseFileVersion=/oracle/install/rspfmt_crsinstall_response_schema_v19.0.0
oracle.install.option=CRS_SWONLY
ORACLE_BASE=/u01/app/oracle
oracle.install.asm.OSDBA=oinstall
oracle.install.asm.OSOPER=oinstall
oracle.install.asm.OSASM=oinstall
oracle.install.crs.config.ClusterConfiguration=STANDALONE
[oracle@exadb01:+ASM1]/home/oracle =>
Gridsetup, this will only copy the software across all the nodes, this will NOT modify anything else
[oracle@exadb01:]/u01/app/19.11.0.0/grid => ./gridSetup.sh -silent -responseFile /u01/stage/gioop/1911oop_response.rsp -waitForCompletion
Launching Oracle Grid Infrastructure Setup Wizard...

[WARNING] [INS-41813] OSDBA for ASM, OSOPER for ASM, and OSASM are the same OS group.
   CAUSE: The group you selected for granting the OSDBA for ASM group for database access, and the OSOPER for ASM group for startup and shutdown of Oracle ASM, is the same group as the OSASM group, whose members have SYSASM privileges on Oracle ASM.
   ACTION: Choose different groups as the OSASM, OSDBA for ASM, and OSOPER for ASM groups.
[WARNING] [INS-41874] Oracle ASM Administrator (OSASM) Group specified is same as the inventory group.
   CAUSE: Operating system group oinstall specified for OSASM Group is same as the inventory group.
   ACTION: It is not recommended to have OSASM group same as inventory group. Select any of the group other than the inventory group to avoid incorrect configuration.
The response file for this session can be found at:
 /u01/app/19.11.0.0/grid/install/response/grid_2021-05-10_10-54-29AM.rsp

You can find the log of this install session at:
 /u01/app/oraInventory/logs/GridSetupActions2021-05-10_10-54-29AM/gridSetupActions2021-05-10_10-54-29AM.log

As a root user, execute the following script(s):
        1. /u01/app/19.11.0.0/grid/root.sh

Execute /u01/app/19.11.0.0/grid/root.sh on the following nodes:
[exadb01]
As instructed, run this root.sh script:
[root@exadb01 ~]# /u01/app/19.11.0.0/grid/root.sh
Check /u01/app/19.11.0.0/grid/install/root_exadb01.domain.com_2021-05-10_11-03-09-927603750.log for the output of root script
[root@exadb01 ~]# cat /u01/app/19.11.0.0/grid/install/root_exadb01.domain.com_2021-05-10_11-03-09-927603750.log
Performing root user operation.

The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/19.11.0.0/grid
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.

To configure Grid Infrastructure for a Cluster or Grid Infrastructure for a Stand-Alone Server execute the following command as oracle user:
/u01/app/19.11.0.0/grid/gridSetup.sh
This command launches the Grid Infrastructure Setup Wizard. The wizard also supports silent operation, and the parameters can be passed through the response file that is available in the installation media.

[root@exadb01 ~]#
OK, this was the last step to be done before the real maintenance, the next steps are do be done under a window maintenance only as the GI will be switched to the new home node by node stopping all the resources running on the old GI home and restarting all the resources on the new GI home. I will recommend using the rac-status.sh script to check the status of all the resources of the cluster before switching the home -- and do the same after the home switching to ensure that your maintenance is idempotent:
[oracle@exadb01:]/home/oracle => /u01/app/19.11.0.0/grid/gridSetup.sh -silent -switchGridHome
Launching Oracle Grid Infrastructure Setup Wizard...

You can find the log of this install session at:
 /u01/app/oraInventory/logs/cloneActions2021-05-10_11-05-43AM.log

As a root user, execute the following script(s):
        1. /u01/app/19.11.0.0/grid/root.sh

Execute /u01/app/19.11.0.0/grid/root.sh on the following nodes:
[exadb01, exadb02, exadb03, exadb04, exadb05, exadb06, exadb07, exadb08]

Run the scripts on the local node first. After successful completion, run the scripts in sequence on all other nodes.

Successfully Setup Software.
[oracle@exadb01:]/home/oracle =>
Now, strictly follow the instructions and run the root.sh scripts as instructed; do NOT run them concurrently on multiple nodes; note that they will take time to run:
[root@exadb01 ~]# /u01/app/19.11.0.0/grid/root.sh
Check /u01/app/19.11.0.0/grid/install/root_exadb01.domain.com_2021-05-10_11-11-21-158300990.log for the output of root script
[root@exadb01 ~]#
And so on on all the nodes one by one ... and you are done ! hmm not exactly you need to update your /etc/oratab (on each node) as the ASM entry will be removed by the patching:
[root@exadb01 ~]# grep ASM /etc/oratab
+ASM1:/u01/app/19.11.0.0/grid:N
You can have a look at the inventory and you could see the old and new GI Home as below:
[root@exadb01 ~]# dcli -g ~/dbs_group -l root "grep -i grid /u01/app/oraInventory/ContentsXML/inventory.xml"
exadb01: <HOME NAME="OraGI19Home1" LOC="/u01/app/19.0.0.0/grid" TYPE="O" IDX="1">                     <== old
exadb01: <HOME NAME="OraGI19Home2" LOC="/u01/app/19.11.0.0/grid" TYPE="O" IDX="19" CRS="true"/>       <== new
. . .
exadb08: <HOME NAME="OraGI19Home1" LOC="/u01/app/19.0.0.0/grid" TYPE="O" IDX="1">                     <== old
exadb08: <HOME NAME="OraGI19Home2" LOC="/u01/app/19.11.0.0/grid" TYPE="O" IDX="14" CRS="true"/>       <== new
[root@exadb01 ~]#
Now you are all done ! a last check with rac-status.sh to ensure that everything is running as expected and you can use the same gold image and procedure to all your GIs !

3. The Rollback procedure

In case of something goes wrong during or after you have switched to your new home, you need to have a tested rollback procedure and the beauty of Out of Place patching is that the old home is still on the system, untouched, as it was before. You then just have to switch back to the old home.
Note that the below chown -R oracle:oinstall (or to the grid owner) is mandatory; indeed, the switch is ran as root and root.sh will later on put the correct privileges back in place.
[root@exadb01 ~]# dcli -g ~/dbs_group -l root "chown -R oracle:oinstall /u01/app/19.0.0.0/grid"           <== this is mandatory
[root@exadb01 ~]# su - oracle
[oracle@exadb01:]/home/oracle => /u01/app/19.0.0.0/grid/gridSetup.sh -silent -switchGridHome
Launching Oracle Grid Infrastructure Setup Wizard...

You can find the log of this install session at:
 /u01/app/oraInventory/logs/cloneActions2021-05-10_12-25-25PM.log

As a root user, execute the following script(s):
        1. /u01/app/19.0.0.0/grid/root.sh

Execute /u01/app/19.0.0.0/grid/root.sh on the following nodes:
[exadb01, exadb02, exadb03, exadb04, exadb05, exadb06, exadb07, exadb08]

Run the scripts on the local node first. After successful completion, run the scripts in sequence on all other nodes.

Successfully Setup Software.
[oracle@exadb01:]/home/oracle =>
Same as before, now run the root.sh script on each node one by one, do not run them concurrently.
[root@exadb01 ~]# /u01/app/19.0.0.0/grid/root.sh
Check /u01/app/19.0.0.0/grid/install/root_exadb01.domain.com_2021-05-10_12-36-17-716165992.log for the output of root script
[root@exadb01 ~]#
. . .
[root@exadb01 ~]# ssh exadb08
Last login: Mon May 10 11:44:34 2021 from exadb01.domain.com
[root@exadb08 ~]# /u01/app/19.0.0.0/grid/root.sh
Check /u01/app/19.0.0.0/grid/install/root_exadb08.domain.com_2021-05-10_12-49-56-584075655.log for the output of root script
[root@exadb08 ~]#
No, refix back your oratab, execute rac-status.sh to check that everything is back up and running as expected and you are all done !

srvctl add oraclehome

Recently I was installing some new databases homes on some Exadatas and I was wondering how the Homes were "known" by the cluster (indeed, when rac-status.sh shows the Homes, I got them as a characteristic of a database and not from a list of registered homes) and I then found this srvctl add oraclehome option. This was on a 12.2 GI and honestly I never noticed it before.

The command help looks like this:
[root@exadatadb01]# srvctl add oraclehome -h
Adds the Oracle home resource to the Oracle Clusterware.
Usage: srvctl add oraclehome -name  -path  [-type {ADMIN|POLICY}] [-node ]
    -name               Identifier for the Oracle home resource
    -path               Oracle home path
    -type               {ADMIN|POLICY}      Type of the specified Oracle home. Default is POLICY.
    -node               Comma-separated list of nodes in which the Oracle home will be available
    -help               Print usage
[root@exadatadb01]#
I then tried to add my new home in my cluster and could check it:
[oracle@exadatadb01]$ srvctl add oraclehome -name TEST -path /u01/app/oracle/product/12.2.0.1/dbhome_2 -type admin -node exadatadb01,exadatadb02
[oracle@exadatadb01]$ srvctl config oraclehome -name TEST
Oracle home path: /u01/app/oracle/product/12.2.0.1/dbhome_2
Oracle home name: test
Oracle home type: ADMIN
Node list: exadatadb01,exadatadb02
Shared: FALSE
Oracle base: /u01/app/oracle
Databases configured:
Listeners configured:
Oracle home test is enabled.
Oracle home resource is individually enabled on nodes:
Oracle home resource is individually disabled on nodes:
[oracle@exadatadb01]$
And we can have information about this home using crsctl as well:
[root@exadatadb01]# crsctl stat res -p -w "TYPE = ora.home.type"
NAME=ora.test.home
TYPE=ora.home.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTIONS=
ACTION_SCRIPT=
ACTION_TIMEOUT=60
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
. . .
Cool, huh ? now the question is "what is the use of that ?" indeed, I have checked on the other RAC/GI systems I have handy and no ORACLE_HOME is registered in the clusters, not in any configuration. We could also wonder what would be the use of having an ORACLE_HOME registered in the cluster ? an ORACLE_HOME is just some files and directories in a filesystem, what could be the value of CRS knowing about the ORACLE_HOME ? I then tried to google and MOS about this srvctl add oraclehome command and I absolutely found nothing !

As I do not like to keep things I do not understand their use, I decided to unregister my TEST ORACLE_HOME to keep a clean cluster configuration:
[oracle@exadatadb01]$ srvctl remove oraclehome -name TEST
Which worked fine. Then I thought I could do more testing on this feature and registered my home again:
[oracle@exadatadb01]$ srvctl add oraclehome -name TEST -path /u01/app/oracle/product/12.2.0.1/dbhome_2 -type admin -node exadatadb01,exadata02
PRCS-1085 : Server category test already exists 
PRCR-1086 : server category test is already registered
Which didn't work as it seems that the srvctl remove oraclehome left some categories behind which I found no way to remove (yet). A MOS SR gave me the information that I was hitting this bug:
Bug 25978527 - LNX64-12.2-SRVCTL:SRVCTL REMOVE ORACLEHOME SHOULD ALSO REMOVE CATEGORY CASCADELY 
. . . which I can acces no information about it so I don't know if there is a patch or a workaround for this.

To sum that up, I am not sure about the use of registering an ORACLE_HOME in the cluster, I found no information about this nowhere (google, MOS) and ... the remove oracle_home does not work properly so ... let's say that this feature is good to know and let's see if it becomes a real new feature in the future ! Let me know in the comments if you have a clue about a potential use of this.

An interesting point here though is that CRS not being aware of the ORACLE_HOMEs, GI is then also not aware of the versions of the ORACLE_HOMEs running there and then the pre-requisite saying that GI version has to be >= DB version cannot be enforced by GI -- which I tested and I can assure that it is indeed the case and you can run a DB Home version > GI version with no issue -- well except that it is not supported but it works with no problem as GI is not aware about the DB Home version :)

Exadata: read this before creating or moving datafiles in RECO !

Data growth looks infinite nowadays and one day or another you will face this kind of situation with your ASM diskgroups:


Output from asmdu.sh


Your DATA diskgroup is clearly under pressure here and it may take a while since you can purge or compress data to release some space (not that it is technically difficult but it usually needs to be organized, planned, decided, etc ...). It is then very tempting to create the new datafiles or even move some datafiles to RECO, right ?

Very tempting indeed but keep in mind the "too good to be true" idiom here as there are important things to know before going further with using RECO for datafiles:
  • Different redundancy:
  • In the above example, DATA has a HIGH redundancy whereas RECO has NORMAL redundancy. It would then make no sense to have some datafiles of a database on a HIGH redundancy diskgroup and other datafiles on a NORMAL redundancy database. To overcome this, you could move all the datafiles of the less important databases to RECO and keep the more important databases on DATA.

  • cachingPolicy=none:
  • From the 11.2.3.2.0 version of Exadata (which is pretty old and you may have a more recent version as I am sure you patch Exadata on a regular basis), the cachingPolicy of the RECO diskgroup is set to none meaning that the Flash Cache will not be used for any blocks stored on the diskgroup (the underlying grid disks actually). This behavior (feature) is described in note 2074156.1.

    Let's have a look at a real example:
    CellCLI> list griddisk attributes name, asmDiskgroupName, cachingPolicy
             DATA_CD_00_exacel02  DATA       default
             DATA_CD_01_exacel02  DATA       default
             DATA_CD_02_exacel02  DATA       default
             DATA_CD_03_exacel02  DATA       default
             DATA_CD_04_exacel02  DATA       default
             DATA_CD_05_exacel02  DATA       default
             DATA_CD_06_exacel02  DATA       default
             DATA_CD_07_exacel02  DATA       default
             DATA_CD_08_exacel02  DATA       default
             DATA_CD_09_exacel02  DATA       default
             DATA_CD_10_exacel02  DATA       default
             DATA_CD_11_exacel02  DATA       default
             RECO_CD_00_exacel02  RECO       none
             RECO_CD_01_exacel02  RECO       none
             RECO_CD_02_exacel02  RECO       none
             RECO_CD_03_exacel02  RECO       none
             RECO_CD_04_exacel02  RECO       none
             RECO_CD_05_exacel02  RECO       none
             RECO_CD_06_exacel02  RECO       none
             RECO_CD_07_exacel02  RECO       none
             RECO_CD_08_exacel02  RECO       none
             RECO_CD_09_exacel02  RECO       none
             RECO_CD_10_exacel02  RECO       none
             RECO_CD_11_exacel02  RECO       none
    CellCLI>
    
    Here indeed, none of the underlying grid disks used by the RECO diskgroup has a cachingPolicy set to default so none of your datafiles would use the Flash Cache which would lead to erractic performances with some datafiles able to use the Flash Cache and some not able to do so.

    So keep his feature in mind and if you really need to use RECO to store datafiles, you'll have to set the cachingPolicyto default for all the grid disks of the RECO diskgroup across all the cell storages:
    CellCLI> alter griddisk RECO_CD_00_exacel02 cachingPolicy=default
    CellCLI> alter griddisk RECO_CD_01_exacel02 cachingPolicy=default
    . . .
    

If you enjoyed this post, spread the word !

ASM: Why you must use HIGH redundancy in production

HIGH redundancy is the ASM redundancy level recommended to run on production systems as each primary file extent has 2 mirrored copies on different failgroups while with NORMAL redundancy each primary file extent has only one mirrored file extent in a different failgroup. This basically means that NORMAL redundancy protects from a single disk failure while HIGH redundancy protects from 2 simultaneous disk failures. Note that, in the specific case of Exadata, each failgroup is located on different storage servers.

A picture is worth a thousand words so let's have a look at a simple illustration:

We can see on the above image that:
  • 3 failgroups are defined here (so on 3 different cells if this is Exadata)
  • The DATA1 diskgroup (in blue) has been created with a HIGH redundancy then we can see 3 copies of a file extent on each failgroup (the blue squares)
  • The DATA2 diskgroup (in red) has been created with a NORMAL redundancy then we can see 2 copies of a file extent on each failgroup (the red squares)

To clarify the features and limitations of such configurations, let's go through a scenario:
  • 1/ We lose all the disks in the Failgroup3 (or the whole storage cell if Exadata)
  • Let's see what happens for our 2 diskgroups DATA1 and DATA2:
    • DATA1 has no issue as it still has 2 copies of each file extent on Failgroup1 and Failgroup2
    • DATA2 has no issue as it still has 1 copy of each file extent on Failgroup2
  • 2/ Now we also lose all the disks on the Failgroup2 (or the whole cell storage if Exadata)
  • And see what happens:
    • DATA1 still survives as it still has 1 copy of each file extent on Failgroup1
    • DATA2 cannot survive this second disk failure and has to be dismounted, everything running on it crashes

You'll tell me "yeah Fred OK but this would be really unfortunate to have such scenario, it never happens !" -- I wouldn't be so sure as I found myself some Exadata storage servers in very bad health when I developped cell-status.sh with asmDeactivationOutcome not set to YES due to not detected bad partner disks for example. Also, when patching Exadata as i will be showing a real life example below.

Let's have a look at this cell patching patchmgr session logs:
2018-11-30 14:28:52 -0600 Do exadatacel12 :Working: Execute plugin check for Patching ...
2018-11-30 14:28:53 -0600 Done exadatacel12 :SUCCESS: Execute plugin check for Patching.
2018-11-30 14:28:53 -0600 3 Do exadatacel12 :Working: Cell will reboot. Up to 5 minutes ...
2018-11-30 14:28:55 -0600 3 Done exadatacel12 :SUCCESS: Finalize patch on cell.
2018-11-30 14:29:12 -0600 4 Do exadatacel12 :Working: Wait for cell to reboot and come online. Between 35 minutes and 600 minutes.
2018-11-30 14:29:12 -0600        :INFO   : exadatacel12 Wait for patch finalization and reboot
2018-11-30 14:55:54 -0600 4 Done exadatacel12 :SUCCESS: Wait for cell to reboot and come online.
2018-11-30 14:55:54 -0600 5 of 5 :Working: DO: Check the state of patch on cells. Up to 5 minutes ...
2018-11-30 14:56:10 -0600 5 Done exadatacel12 :SUCCESS: Check the state of patch on cell.
2018-11-30 14:56:10 -0600 Do exadatacel12 :Working: Execute plugin check for Pre Disk Activation ...
2018-11-30 14:56:11 -0600 Done exadatacel12 :SUCCESS: Execute plugin check for Pre Disk Activation.
2018-11-30 14:56:11 -0600        :Working: DO: Activate grid disks...  Up to  600 minutes ...
2018-11-30 14:56:12 -0600        :INFO   : Wait for checking and activating grid disks
2018-11-30 15:52:52 -0600        :SUCCESS: DONE: Activate grid disks.
2018-11-30 15:52:55 -0600        :Working: DO: Execute plugin check for Post Patch ...
2018-11-30 15:52:56 -0600 Done exadatacel12 :SUCCESS: Execute plugin check for Post Patch.
2018-11-30 15:52:56 -0600 Do exadatacel13 :Working: Execute plugin check for Patching ...
2018-11-30 15:52:57 -0600 Done exadatacel13 :SUCCESS: Execute plugin check for Patching.
2018-11-30 15:52:57 -0600 3 Do exadatacel13 :Working: Cell will reboot. Up to 5 minutes ...
2018-11-30 15:52:59 -0600 3 Done exadatacel13 :SUCCESS: Finalize patch on cell.
2018-11-30 15:53:43 -0600 4 Do exadatacel13 :Working: Wait for cell to reboot and come online. Between 35 minutes and 600 minutes.
2018-11-30 15:53:43 -0600        :INFO   : exadatacel13 Wait for patch finalization and reboot
2018-11-30 16:20:12 -0600 4 Done exadatacel13 :SUCCESS: Wait for cell to reboot and come online.
2018-11-30 16:20:12 -0600 5 of 5 :Working: DO: Check the state of patch on cells. Up to 5 minutes ...
2018-11-30 16:20:25 -0600 5 Done exadatacel13 :SUCCESS: Check the state of patch on cell.
2018-11-30 16:20:25 -0600 Do exadatacel13 :Working: Execute plugin check for Pre Disk Activation ...
2018-11-30 16:20:26 -0600 Done exadatacel13 :SUCCESS: Execute plugin check for Pre Disk Activation.
2018-11-30 16:20:26 -0600        :Working: DO: Activate grid disks...  Up to  600 minutes ...
2018-11-30 16:20:27 -0600        :INFO   : Wait for checking and activating grid disks
||||| 2018-11-30 18:43:25 -0600 Minutes left 457
||||| 2018-11-30 20:51:24 -0600 Minutes left 329
If you look at the exadatacel12 timestamps, it took ~ one hour to reactivate the grid disks and exadatacel13 was stuck activating grid disks for hours; weird, right ? why those cel13 disks would be stuck after having successfully patched 12 cells already ? (and we patch this Exadata on a regular basis).

A closer look at the disks was showing the grid disks of the DATA diskgroups in an UNKNOWN status:
CellCLI> list griddisk attributes name,asmmodestatus
         DATA_CD_00_exadatacel13      UNKNOWN
         DATA_CD_01_exadatacel13      UNKNOWN
         DATA_CD_02_exadatacel13      UNKNOWN
         DATA_CD_03_exadatacel13      UNKNOWN
         DATA_CD_04_exadatacel13      UNKNOWN
         DATA_CD_05_exadatacel13      UNKNOWN
         DATA_CD_06_exadatacel13      UNKNOWN
         DATA_CD_07_exadatacel13      UNKNOWN
         DATA_CD_08_exadatacel13      UNKNOWN
         DATA_CD_09_exadatacel13      UNKNOWN
         DATA_CD_10_exadatacel13      UNKNOWN
         DATA_CD_11_exadatacel13      UNKNOWN
         RECO_CD_00_exadatacel13      ONLINE
         RECO_CD_01_exadatacel13      ONLINE
         RECO_CD_02_exadatacel13      ONLINE
         RECO_CD_03_exadatacel13      ONLINE
         RECO_CD_04_exadatacel13      ONLINE
         RECO_CD_05_exadatacel13      ONLINE
         RECO_CD_06_exadatacel13      ONLINE
         RECO_CD_07_exadatacel13      ONLINE
         RECO_CD_08_exadatacel13      ONLINE
         RECO_CD_09_exadatacel13      ONLINE
         RECO_CD_10_exadatacel13      ONLINE
         RECO_CD_11_exadatacel13      ONLINE
CellCLI>

Using rac-status.sh, we then found out that all the databases were down (I have shrunk the below output for better visibility as the real case was more dramatic as there was 80 databases running on a Full Rack, standbys as well, many more listeners, etc ...):
[oracle@exadatadb01]$ ./rac-status.sh

                Cluster exadata is a  X4-2 Full Rack HC 4TB

    Listener   |      Port     |     db01     |     db02     |     db03     |     db04     |     Type     |
-----------------------------------------------------------------------------------------------------------
    LISTENER   | TCP:1522      |    Online    |    Online    |    Online    |    Online    |   Listener   |
 LISTENER_SCAN1| TCP:1521      |       -      |    Online    |       -      |       -      |     SCAN     |
 LISTENER_SCAN2| TCP:1521      |       -      |       -      |    Online    |       -      |     SCAN     | 
 LISTENER_SCAN3| TCP:1521      |       -      |       -      |       -      |    Online    |     SCAN     |
-----------------------------------------------------------------------------------------------------------

       DB      |    Version    |     db01     |     db02     |     db03     |     db04     |    DB Type   |
-----------------------------------------------------------------------------------------------------------
  db_01        | 11.2.0.4  (1) |   Shutdown   |   Shutdown   |   Shutdown   |   Shutdown   |    RAC (P)   |
  db_02        | 11.2.0.4  (2) |   Shutdown   |   Shutdown   |   Shutdown   |   Shutdown   |    RAC (P)   |
  db_03        | 11.2.0.4  (1) |   Shutdown   |   Shutdown   |   Shutdown   |   Shutdown   |    RAC (P)   |
  db_04        | 12.1.0.2  (3) |   Shutdown   |   Shutdown   |   Shutdown   |   Shutdown   |    RAC (P)   |
  db_05        | 12.1.0.2  (3) |   Shutdown   |   Shutdown   |   Shutdown   |   Shutdown   |    RAC (P)   |
  db_06        | 12.1.0.2  (4) |   Shutdown   |   Shutdown   |   Shutdown   |   Shutdown   |    RAC (P)   |
  db_07        | 12.1.0.2  (5) |   Shutdown   |   Shutdown   |   Shutdown   |   Shutdown   |    RAC (P)   |
  db_08        | 12.1.0.2  (3) |   Shutdown   |   Shutdown   |   Shutdown   |   Shutdown   |    RAC (P)   |
  db_09        | 11.2.0.4  (2) |   Shutdown   |   Shutdown   |   Shutdown   |   Shutdown   |    RAC (P)   |
  db_10        | 11.2.0.4  (1) |   Shutdown   |   Shutdown   |   Shutdown   |   Shutdown   |    RAC (P)   |
. . .

Wow, but why these databases were down (crashed ?) as the DATA diskgroup they are having their datafiles on is a NORMAL redundancy one ?

And . . . here was the accident:
[root@exadatacel11 ~]# cellcli -e list alerthistory
                  5       2018-11-30T16:18:57-06:00       critical        "Disk controller was hung. Cell was power cycled to restore access to the cell."
[root@exadatacel11 ~]#
Yeah, cel11 controller died when cel13 was down for patching => 2 simultaneous disk failures against a NORMAL redundancy diskgroup => DG is dismounted => everything running on it crashes (it worked as designed :)) !

Bad luck here ? may be yes and I am not saying it happens often but I personally do not want to rely on luck or on controller failure statistics on production. This is why is strongly recommend to go with HIGH redundancy on production !

Deprecation of OPatch Command Option "-all_nodes"

A very important change will be happening soon (actually it has already happened) about opatch and then all the scripting you may have developed over the years. Indeed, the -all_nodes option will be deprecated and replaced as announced in Customer Recommended GI/RAC/Single Instance Announcing Deprecation of OPatch Command Option "-all_nodes" (Doc ID 2331762.1).

Details :

 This is applicable to all releases of OPatch.

 The 12.2.0.1.13 release (and later) of OPatch, which is used for all releases 12.1.0.x and later

 The 11.2.0.3.18 release (and later) of OPatch, which is used for all releases 11.2.0.1 - 11.2.0.4

 Beginning with these releases of OPatch,  OPatch will only support patching/listing inventory for local node of a RAC cluster.

 There will be no propagation to other nodes in cluster.

I first thought that this announcement was kind of awkward as we cannot imagine to have opatch to only support patching/listing inventory for local node of a RAC cluster. But it is not and after few tests, the -all_nodes option indeed does not provide any remote patch information any more in 12.2.0.1.13 which is not really nice.

Future :


Hopefully is also announced a new -remote option to replace -all_nodes but in the 12.2.0.1.14 version only :

1. In Opatch 12.2.0.1.13 and Opatch 11.2.0.3.18, OPatch command option “-all_nodes” will be no-op and existed in -help.

     If opatch command is being called with option “-all_nodes”, Opatch will print out the warning on console msg as:

     "OPatch was called with -all_nodes option. The -all_nodes option is being deprecated. Please remove it while calling OPatch."

 2.  In future release Opatch 12.2.0.1.14 (and later) and Opatch 11.2.0.3.20 (and later) , Option “-all_nodes” will be removed from -help, user will get syntax error if specify the option. 

Alternative Feature of -all_node is available  for Multi-Node GI/RAC :

$ORACLE_HOME/OPatch/opatchauto report -format xml -type patches -remote

(The remote command will get a list of patches from all nodes)


Indeed, 12.2.0.1.13 opatch now raises a warning when using the -all_nodes option :

oracle@exadatadb01> $ORACLE_HOME/OPatch/opatch lsinventory -all_nodes
Oracle Interim Patch Installer version 12.2.0.1.13
Copyright (c) 2018, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/12.2.0.1/grid
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/12.2.0.1/grid/oraInst.loc
OPatch version    : 12.2.0.1.13
OUI version       : 12.2.0.1.4
Log file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/opatch2018-06-21_21-12-23PM_1.log

Warning: OPatch was called with -all_nodes option. The -all_nodes option is being deprecated.
         Please remove it while calling OPatch.

But do NOT provide any remote patch information any more.

asmdu.sh : a far better "du" for asmcmd, version 3

It's been a while since I released asmdu version 1 and version 2. These versions were cool but few features were missing. For those who don't know what asmdu is about, it is a shell script which is meant to provide a clear output of the ASM diskgroups usage.

 

ASM disk usage : The old fashioned way

When it is about to have an ASM output about the diskgroups usage, you may use the asmcmd lsdg command and you got this kind of output :



Let's have a quick look at some interesting elements of this output :
  1. The diskgroups
  2. The diskgroups redundancy
  3. Four columns presenting some sizes are shown in the yellow shape on the above screenshot, they are interesting but not really clear IMO
This output is interesting but I see few things that would benefit from a clearer presentation :
  1.  Unit is MB and cannot be changed
  2. Then it makes the output not really clear with the big diskgroup sizes we have nowadays
  3. Also the sizes shown here are non mirrored and mirrorred sizes which makes the output perfectible. Also the "Req_mir_free_MB" column may be tricky; please have a look at this very good blog on the subject.

A new & better way with asmdu.sh

The asmdu.sh script will then try to resolve these issues by showing you in a glimpse a nice and clear output :



Let's have a look at the above screenshot's colored features :
  1. The script will show you a list of running instances on the local node; I found it very handy to have an idea on what's running on the node I am connected to
  2. The diskgroups and the redundancy are also shown in the two first coolumns
  3. You can see that the Unit is TB here which is beter for this kind of sizes.
  4. Then is shown the Total diskgroup size and the Usable size. Also note that only mirrored sizes are shown here then you can easily compare them and quickly see how much space is available for the databases.
  5. The last column shows the %Free space for each diskgroup which is a very valuable information. You can then know if a diskgroup is under space pressure in a glimpse.
  6. This % Free is presented with colored thresholds (Red, Yellow and Green) to be able to quickly identify any potential space pressure on any diskgroup. The defaut thresholds are Green < 75% < Yellow < 90%  < Red. You can customize these thresholds by modifying these values in the script :


Using different Units

As we all have different diskgroup sizes, I've added options to be able to choose the Unit you want to show the output on :
  • -m : to show in MB
  • -g : to show in GB
  • -t : to show in TB




Please note that the default Unit  (when no -m, -g nor -t is specified on the command line) is TB; you can change the default Unit by editing the script and change the DEFAULT_UNIT variable (the last uncommented value wins) :



A verbose mode

Few information that asmcmd lsdg shows are not shown by asmdu.sh by default :
  • Free_MB : Free space (in MB) in the diskgroup, this is with no redundancy
  • Req_mir_free_MB : Required size (in MB) to restore redundancy after the worst failure that can tolerate ASM

I have a bit modified this output to show the below one with the -v option  : 

  1. Raw Total is the total non mirrored size of the diskgroup
  2. Raw Free is the non mirrored free space of the diskgroup
  3. Reserved size is the amount of free space required to be available in order to restore redundancy after one or more disk failures without affecting data availability

It is then strongly recommended to not use this reserved size, the real Usable size being (Free_MB - Req_mir_free_MB) / Redundancy.


If you want to show these information by default, just edit the script  and modify this DEFAULT_VERBOSE variable (the last uncommented value wins) :



External redundancy

Please note that in case of External Redundancy the Reserved Size is 0.




Handling subdirectories

In the case you have a space shortage on a diskgroup like in the below example where only 4% left, you would need to know which database uses the most space in order to work on freeing some space.

Naturally, I would do a "du *" under asmcmd as I would do under any Unix shell and here is the accident : "du *" under asmcmd acts like a "du ." under any Unix shell (it shows the total size used on the diskgroup instead of the size used by each subdirectory)  as you can see with the below screenshot :



You would then have to do a du for each directory to finally find the biggest(s). It is not handy and may be painful if you have many databases running there as you would have to make a loop with asmcmd commands to achieve this goal :


It is indeed doable but it may not be what you want to face when you may be in a rush with a 4% free space diskgroup.


A subdirectories example

The purpose of the -d option is to easily show you all the subdirectories under a directory (it also shows you the diskgroup characteristics where resides this directory) :


You can then identify the databases that use the most space in a glimpse. "In a glimpse" is a figure of speech here; indeed this -d option id based  on the "real" asmcmd du command and as this one may be quite slow, this output may take a bit of time as well depending on how big are your databases.


Another subdirectories example

The example below is to show that the -d option also works with a whole path and not only a diskgroup name. The below screenshot shows archivelogs directories size and you will quickly notice that there's some 2012 archivelogs still using lots of space on your diskgroup. You may want to delete them to save some space.



If you want no color

If you want a non colored output (to, for example, automatically send the output by email), you can use the -n option:


 This option is compatible with any other option.
If you want a non colored output as default, edit the script and comment the default behavior you do not want:
DEFAULT_NOCOLOR="Yes"   # Print with no color
DEFAULT_NOCOLOR="No"    # Print with colors


Option -h for the syntax

To sum that up, you may want to use the -h option that will show you all the options and a description of each option :





Restrictions

There're not many restrictions that could prevent asmdu to work :

  1. oraenv has to work to set the ASM environment
  2. asmdu has to be started as the ASM owner (the GI owner)to be able to run asmcmd commands.

The code


The code is hosted and maintained on my github repository, help yourself and enjoy asmdu !



I hope you'll be enjoying this script as much as I enjoy it on a daily basis !

Any suggestion, comment or bug, please let me know in the comments sections.


OCI: Datapump between 23ai ADB and 19c ADB using database link

Now that we know how to manually create a 23ai ADB in OCI , that we also know how to create a database link between a 23ai ADB and a 19C AD...