Oracle DBA Automation using Ansible - RU 18.5 Oracle Grid Infrastructure and Database Home from Oracle 18.3

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RAC RU 18.5 Oracle Grid Infrastructure and Database Home from Oracle 18.3 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Ansible tools - easier to setup automation task instead of manually .

In this article we will go through applying RU into a Oracle GI and Database using Ansible script. Normally we need to manually run over 20 commands for patching Oracle GI and Oracle_HOME and time consuming ----but with ansible setup here I am going to execute a single command,  ansible-playbook racdatabase.yml to complete GI, RDBMS and Data Patch tasks.

 
Tasks:
main.yml 

 - pre_tasks_before_apply [prepatch_apply.yml]
     +  Backup opatch file from grid home / oracle home
  +  Update required opatch utility in grid home / Oracle home
  +  Update opatch ownership in grid home / Oracle home
  +  OPatch Conflict Check in grid home / Oracle home
  +  OPatch SystemSpace Check in grid home / Oracle home
  +  check inventory for grid home / Oracle home
  +  One-Off Patch Conflict Detection (-analyze)
  +  current patch information
  
 - RU to grid home first node
 - RU to grid home second node
 - Pause after GI patching completion to validate
 - RU to database home first node
 - RU to database home second node 
 - post_tasks_after_apply [postpatch_apply.yml]
     + Apply data patch


Here I am going to execute Apply RU into RAC GI and Oracle Home with CDB | database version 18.3 to 18.5.























hosts file entry for two nodes [ In this case First node is racdb01 and Second node racdb02]















For this task I am going to run playbook roles "racdb_patch_apply" under racdatabase.yml















Tree structure for this role is as below - 











Variables relate to this roles are as below - 















Tasks relate to this has three parts -



main.yml which has prepatch_apply.yml and postpatch_apply.yml











i. prepatch_apply.yml















ii postpatch_apply.yml















Run log -















Related log files for both GI and Oracle DB



patch log for the First node Oracle_HOME







Opatch log for the first node GI











patch log for the second node GI











patch log for Second Node Oracle_HOME















Patches information before and update patching for both GI and Oracle_HOME



















Validate from database after completion of datapatch:



set linesize 300;

column description format a55

column action_time format a30

column action format a8

column status format a8

column "patch_id" format 99999999999

column "patch_uid" format 9999999999



SQL> select patch_id, patch_uid, description, action_time, action, status

  2  from dba_registry_sqlpatch

  3  where ACTION_TIME like '%31-JAN-19%';



    PATCH_ID   PATCH_UID DESCRIPTION                                             ACTION_TIME                    ACTION   STATUS

------------ ----------- ------------------------------------------------------- ------------------------------ -------- --------

    28822489    22669539 Database Release Update : 18.5.0.0.190115 (28822489)    31-JAN-19 12.53.16.418015 PM   APPLY    SUCCESS

    28822489    22669539 Database Release Update : 18.5.0.0.190115 (28822489)    31-JAN-19 02.02.41.393758 PM   ROLLBACK SUCCESS

    28822489    22669539 Database Release Update : 18.5.0.0.190115 (28822489)    31-JAN-19 05.38.10.604816 PM   APPLY    SUCCESS





SQL> set serverout on

SQL> exec dbms_qopatch.get_sqlpatch_status;



Patch Id : 28090523

        Action : APPLY

        Action Time : 23-JAN-2019 01:02:11

        Description : Database Release Update : 18.3.0.0.180717 (28090523)

        Logfile : /u02/app/oracle/cfgtoollogs/sqlpatch/28090523/22329768/28090523_apply_PMON1_CDBROOT_2019Jan23_01_01_44.log

        Status : SUCCESS



Patch Id : 27923415

        Action : APPLY

        Action Time : 23-JAN-2019 01:06:14

        Description : OJVM RELEASE UPDATE: 18.3.0.0.180717 (27923415)

        Logfile : --



---

Patch Id : 28822489

        Action : APPLY

        Action Time : 31-JAN-2019 12:53:16

        Description : Database Release Update : 18.5.0.0.190115 (28822489)

        Logfile : /u02/app/oracle/cfgtoollogs/sqlpatch/28822489/22669539/28822489_apply_PMON1_CDBROOT_2019Jan31_12_49_33.log

        Status : SUCCESS



Patch Id : 28822489

        Action : ROLLBACK

        Action Time : 31-JAN-2019 14:02:41

        Description : Database Release Update : 18.5.0.0.190115 (28822489)

        Logfile : /u02/app/oracle/cfgtoollogs/sqlpatch/28822489/22669539/28822489_rollback_PMON1_CDBROOT_2019Jan31_13_59_04.log

        Status : SUCCESS



Patch Id : 28822489

        Action : APPLY

        Action Time : 31-JAN-2019 17:38:10

        Description : Database Release Update : 18.5.0.0.190115 (28822489)

        Logfile : /u02/app/oracle/cfgtoollogs/sqlpatch/28822489/22669539/28822489_apply_PMON1_CDBROOT_2019Jan31_17_34_21.log

        Status : SUCCESS



PL/SQL procedure successfully completed.





So this is really good. I hope as a DBA you may like this and use Ansible for making life easier.



Enjoy Automation :)











































Comments











Post a Comment



















Popular posts from this blog









Oracle DataGuard – How to resize Redo Log and Standby Redo Log





















   Oracle DataGuard – How to resize Redo Log and Standby Redo Log   set linesize 200  col dest_name for a30  select DEST_NAME,STATUS,PROTECTION_MODE,ARCHIVED_SEQ#,APPLIED_SEQ# from v$archive_dest_status;   On Standby server - make file management parameter to manual if not:  show parameter standby;  alter system set standby_file_management=manual;  ==================  +     On Primary             +  ==================   SQL> select group#,thread#,status from v$log;   col member for a60  set linesize 200  select member,group#,status from v$logfile;  SQL> select group#,thread#,status from v$log;       GROUP#    THREAD# STATUS  ---------- ---------- ----------------           1          1 ACTIVE           2       ...








Read more










Exadata - Smart Scan Testing




















Image







 Exadata - SMART SCAN testing   --------------------------------------------     Samrt scan works with cell offloading which relate to offloaded the sql processing from the database layer to the cell (storage) layer.     Smart scan is the access mechanism to offload data from storage layer. For example passing only required data blocks after applying predicate filters at the cell layer instead of sending every possible blocks from cell server to database server.                                 Figure 1: Traditional Database Storage I/O and SQL Processing Model       Process Steps:   -------------------    1.    The client issues a SELECT  statement .    2.    The database kernel maps this request to the database files and extents which contain the table data.    3.    The database kernel issues the I/Os to read all the table bloc...








Read more










Exadata Flash Cache - Management





















 Total size of Flash  CellCLI>  list flashcache attributes effectiveCacheSize           5.82122802734375T   Flashcache Mode:    [root@Cellc01-adm ~]# su - celladmin  cellcli  CellCLI>  list cell attributes flashCacheMode,status           WriteThrough    online   > list celldisk where disktype=flashdisk  > list physicaldisk FLASH_1_1 detail   List PhysicalDisk for FlashCache:   CellCLI> list physicaldisk attributes name, disktype, makemodel, physicalrpm, physicalport, status       8:0           HardDisk      "HGST    H7240AS60SUN4.0T"                              normal       8:1  ...








Read more