Schlagwort: database

Easy Autoupgrade/Autopatch Oracle Out-of-Place 19.20 within Sphinx Environment

If not already exists a „not used“ Oracle Home. create a new one..

dbsw_install dbs 19.EE 19.20
(19.EE is our 19.16 Prepared Image) 

Now it will create our new Home in 
/app_oracle/product/dbs/19.20

(it will prompt that you have to make an root commando, please do that)

Replace the OPatch utility with the newest Version

mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_old
unzip /app_oracle/local/tools/p6880880_210000_Linux-x86-64.zip -d $ORACLE_HOME/

Download the Patches from Oracle with WGET

Find Patchnr here:
https://support.oracle.com/knowledge/Oracle%20Database%20Products/888_1.html#19

Patch 35320081: DATABASE RELEASE UPDATE 19.20.0.0.0
Patch 35370174: COMBO OF OJVM RU COMPONENT 19.20.0.0.230718 + DB RU 19.20.0.0.230718
— Patch 35261302: DATAPUMP BUNDLE PATCH 19.19.0.0.0

ORACLE

Thx WGET its easy , i dont like the support.oracle.com Page to download Patchs..

The 19.20 DB+OJW Bundle Patch

wget --http-user=myuser@sphinx.at --http-password=Dontellu --no-check-certificate --output-document=p35370174_190000_Linux-x86-64.zip "https://updates.oracle.com/Orion/Download/download_patch/p35370174_190000_Linux-x86-64.zip"

The 19.19 DBRU Patch (which cannot be applied at the moment)
i have to wait for 19.20

wget --http-user=myuser@sphinx.at --http-password=Dontellu --no-check-certificate --output-document=p35261302_1919000DBRU_Generic.zip "https://updates.oracle.com/Orion/Download/download_patch/p35261302_1919000DBRU_Generic.zip"

Unpack the *.zip into to /app_oracle/product/dbs/19.20-patch/ (or/tmp)

Set the enviroment to the Target new home:

export ORACLE_HOME=/app_oracle/product/dbs/19.20
export PATH=/app_oracle/product/dbs/19.20/OPatch:$PATH
opatch version

cd /app_oracle/product/dbs/19.20-patch/35370174/35320081
opatch apply
cd /app_oracle/product/dbs/19.20-patch/35370174/35354406
opatch apply 
y
y
$ORACLE_HOME/OPatch/opatch lspatches

Oracle recommends to use the autoupgrade Tool to switch the home and install all correctly: You have to create an cfg to use autoupgrade correctly.

cd /app_oracle/local/tools/autoupgrade.jar

vi autoupgrade_patch_CDB.cfg

patch_C10P.log_dir=/app_oracle/log
patch_C10P.sid=C10P1
patch_C10P.source_home=/app_oracle/product/dbs/19.EE
patch_C10P.target_home=/app_oracle/product/dbs/19.20
patch_C10P.start_time=NOW
patch_C10P.run_utlrp=yes

Okay last Check – autoupgrades brings an „analyze“ with it

$ORACLE_HOME/jdk/bin/java -jar autoupgrade.jar \
-config autoupgrade_patch_CDB.cfg \
-mode analyze

cat /app_oracle/cfgtoollogs/autoupgrade/cfgtoollogs/upgrade/auto/status/status.log

looks good -- everthing fine

Okay start the upgrade- now the database is a while unavailable – if it is a singe instance


$ORACLE_HOME/jdk/bin/java -jar /app_oracle/autoupgrade/autoupgrade.jar \
-config /app_oracle/autoupgrade/autoupgrade_patch_CDB.txt \
-mode deploy

cat /app_oracle/cfgtoollogs/autoupgrade/cfgtoollogs/upgrade/auto/status/status.log

Within our Sphinx Environment now its needed to change some things


cd /app_oracle/local/etc
Copy our oraenv specific shellscript too 

cp oraenv-dbs-19.EE.sh oraenv-dbs-19.20.sh

change the .EE with the current version
vi oraenv-dbs-19.20.sh -- change .EE mit .20

Relink oraenv-default.sh

rm oraenv-default.sh
ln -s oraenv-dbs-19.20.sh oraenv-default.sh

Switch to the current environment an take a look
chenv c10p
sqlplus "sys/sx123 as sysdba"

Also change listener.ora to run on 
ORACLE_HOME=/app_oracle/product/dbs/19.20
instead of 19.EE

-- 19.20.0.0 -- all is good

Worksfine, it can be used for x Databases in one Script

SAYS MIKE DIETRICH

Oracle Security Patches

SECURITY ALERTS + LINKS TO THE PATCHES

https://www.oracle.com/security-alerts/
Stay safe and patch

We would like to inform you that it’s patching day again, even though many of our customers have their databases located behind a secure network firewall. We understand that some customers may be reluctant to regularly engage in patching due to the effort and risks involved, especially when the system is actively in use. Therefore, we recommend that Oracle patches be initially installed on development and test systems before being applied to the production system after 2-3 weeks. We would be happy to support you in managing the patching process of your Oracle environment. Our Managed Services team is available to assist you promptly, and we also recommend this approach to our customers.

TL;DR:

Introduction: Patching is an essential aspect of maintaining an Oracle environment. Keeping up with the latest patches can help ensure the security, stability, and performance of your database system. However, the patching process can be overwhelming, especially for beginners. In this blog post, we’ll provide a step-by-step guide to Oracle patching and offer some tips to help simplify the process.

Step 1: Identify the Appropriate Patches Before starting the patching process, you need to identify the appropriate patches for your environment. Oracle releases patches on a regular basis, so it’s essential to keep track of the latest patches and determine which ones are relevant to your database system. You can use Oracle’s My Oracle Support (MOS) to identify and download patches.

Step 2: Plan the Patching Process Once you have identified the appropriate patches, it’s time to plan the patching process. This involves creating a patching plan that outlines the sequence of patch installations, the estimated downtime, and the rollback strategy. It’s important to involve stakeholders in the planning process to ensure that the patching process aligns with their requirements.

Step 3: Test the Patches Before installing patches on the production environment, it’s essential to test them on a development or test environment. This can help identify any potential issues that may arise during the patching process. It’s crucial to ensure that the testing environment replicates the production environment as closely as possible.

Step 4: Install the Patches After testing the patches, it’s time to install them on the production environment. The installation process can vary depending on the type of patch, but Oracle provides detailed instructions on how to install each patch.

Step 5: Validate the Patch Installation Once the patches have been installed, it’s important to validate the patch installation to ensure that the patches have been successfully applied. You can use Oracle’s opatch utility to validate the patch installation.

Step 6: Monitor and Maintain the Patched Environment After successfully patching the environment, it’s essential to monitor and maintain the patched environment. This includes regularly checking for new patches, applying patches as needed, and testing the patches before applying them to the production environment.

Conclusion: Oracle patching can be a complex and time-consuming process, but it’s an essential aspect of maintaining a stable and secure database environment. By following these steps, you can simplify the patching process and ensure that your Oracle environment remains up-to-date and secure.

The end of the Oracle DB – Links?

Database links in Autonomous Database Shared are the past – Cloud links are the future

Hermann BAER – Oracle PRODUCT MANAGEMENT

Database links have been a popular way to let remote databases access specific tables or views in a database, but they require a lot of back and forth communication to establish the connection. However, with Oracle Autonomous Database Shared’s new feature, Cloud Links, data owners can easily register a table or view for remote access by a certain audience, without needing to set up a connection every time someone needs to access the data. This means that anyone with remote access can discover and use the data that has been made available to them without any extra hassle.

select .. from <namespace>.<name>@cloud$link;

https://blogs.oracle.com/datawarehousing/post/database-links-in-autonomous-database-shared-are-the-past—cloud-links-are-the-future

We like this Solution

SPHINX.AT

© 2024 Sphinx Blog

Theme by Anders NorenUp ↑