biemond / biemond-oradb

Puppet Oracle Database Module
Apache License 2.0
59 stars 113 forks source link

oradb.opatch - OPatchauto and NApply #274

Open umaha01 opened 4 years ago

umaha01 commented 4 years ago

Hello All, On this same subject - i have a scenario - if any of you have some insight can you please share it back.

I am using oradb.opatch module to apply patches to RAC environments.

With opatchauto command, we can just specify patches location and it will apply all the patches. PSU JAN2020 - 30501910 (Main PatchID), and associated SUB PATCHIDs -> 30557433, 30489227 I have applied patches using opatchauto of opatch.pp module @ 30501910 Level (Which applied all sub patches successfully. Following this - for all puppet runs it is reporting below messages: Info: search for patchid 30501910 Info: opatch_status for patch 30501910 command: /appl/grid/19.0.0.0/OPatch/opatch lsinventory -patch_id -oh /appl/grid/19.0.0.0 -invPtrLoc /etc/oraInst.loc Info: opatch_status output NotFound for patchId 30501910 The reason because that Parent Id is not found on the opatch lsinventory. puppet facts are as below after patching: "/appl/grid/19.0.0.0": [ { "patch_id": "30484981", "patch_desc": "OJVM RELEASE UPDATE: 19.6.0.0.200114 (30484981)" }, { "patch_id": "30557433", "patch_desc": "Database Release Update : 19.6.0.0.200114 (30557433)" }, { "patch_id": "30489227", "patch_desc": "OCW RELEASE UPDATE 19.6.0.0.0 (30489227)" } NOW MY QUESTION? How to ensure puppet moves forward without trying to apply the same patches, it is trying and giving an output "Patches are already applied". Does oradb.opatch supports NAPPLY ?

Appreciate your inputs and insights around this.

biemond commented 4 years ago

He,

30501910 is not really a patch, it is bundle which I cannot find back , So I need to find those sub patches instead. Which I do with this param bundle_sub_patch_id

oradb::opatch{'21523260_grid_patch':
  ensure                    => 'present',
  oracle_product_home       => hiera('grid_home_dir'),
  patch_id                  => '21523260',
  patch_file                => 'p21523260_121020_Linux-x86-64.zip',
  clusterware               => true,
  use_opatchauto_utility    => true,
  bundle_sub_patch_id       => '21359755', # sub patch_id of bundle patch ( else I can't detect it)
  user                      => hiera('grid_os_user'),
  group                     => 'oinstall',
  download_dir              => hiera('oracle_download_dir'),
  ocmrf                     => true,
  puppet_download_mnt_point => hiera('oracle_source'),
  require                   => Oradb::Opatchupgrade['121000_opatch_upgrade_asm'],
}
umaha01 commented 4 years ago

Thank you very much, Does this allow multiple bundle patches part of the same call or it need to be multiple calls.

umaha01 commented 4 years ago

########################################################## Hi, I have reviewed this above approach, and it will apply Bundle_Sub_patch_id in a sequence, and for every run opatchauto restarting the cluster services and also trying to execute postpatch steps part of first patch that is causing below error. ########################################################## After fixing the cause of failure Run opatchauto resume with session id "ZG6T" ] OPATCHAUTO-68061: The orchestration engine failed. OPATCHAUTO-68061: The orchestration engine failed with return code 1 OPATCHAUTO-68061: Check the log for more details. OPatchAuto failed. ########################################################## Discussed with Oracle about this issue, and they have confirmed that the post patch steps execution is causing the issue for RAC.

biemond commented 4 years ago

He you can still do the whole bundle patch in 1 go but I need 1 of the subpatches in this so I know I can skip it. So if the bundle has 2 patches you only need to provide 1 of the subpatches and I will skip it in the 2nd run