impdp with parameter „cluster and parallel“ for a RAC Cluster

For using the „parallel“ parameter during an import (impdp) on a Oracle RAC Cluster you need to prepare your environment.

The „parallel“ parameter works correctly when you do the following:

– mount point were the export dump resides must be available on ALL cluster members

– create a Service on the database for the impdp job

srvctl add service -s impdp_service -d xdb1 -pdb xpdb1 -preferred xdb11,xdb12 -available xdb13

srvctl start service -s impdp_service -d xdb1

– Check that the service is running

srvctl status service -s impdp_service -d xdb1

Now you are ready to use the impdp „parallel“ parameter

Here an example with „cluster=y parallel=6

impdp system@xpdb1 directory=dump dumpfile=full_%u.dmp schemas=DB1 cluster=y parallel=6 service_name=impdp_service status=180 logfile=imp_xpdb1.log METRICS=Y logtime=all

impdp Log Parameter which are really helpful for analyzing are:

METRICS=Y

logtime=all

Extract from the Logfile

You see that there are detailed informations about the worker process for example W-1 = Worker 1

W-1 Completed by worker 1 757 TABLE objects in 38 seconds
W-1 Completed by worker 2 764 TABLE objects in 37 seconds
W-1 Completed by worker 3 765 TABLE objects in 48 seconds
W-1 Completed by worker 4 765 TABLE objects in 53 seconds
W-1 Completed by worker 5 766 TABLE objects in 34 seconds
W-1 Completed by worker 6 765 TABLE objects in 44 seconds

W-5 Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA

Worker 5 is processing TABLE_DATA

For analyzing the impdp process you get so detailed informations try the next time.

Depending on your hardware you can also use different integer values for the „parallel“ parameter but a large number will not help in every situation.

Have fun with impdp on your RAC Cluster….

 

 

 

 

Werbeanzeigen

12.2 Grid Patching lesson learned

What happend?

During the last month I updated manually the TFA Software.

I  do this update while the TFA release installed via the Patchset is an older Version. This happens while Oracle Support adds the TFA release which is available while they create the Patchset.

Last weekend I start Patching GI Software 12.2 to RU Oct 2018 on a 4 Node Exadata Cluster

As best practice I do the installation manually and not via opatchauto.

First activity is:

/u01/app/12.2.0.1/grid/crs/install/rootcrs.sh -prepatch

This ends with the following error message:

2019/03/09 13:36:12 CLSRSC-46: Error: ‚/u01/app/12.2.0.1/grid/suptools/tfa/release/tfa_home/jlib/jdev-rt.jar‘ does not exist
2019/03/09 13:36:12 CLSRSC-152: Could not set ownership on ‚/u01/app/12.2.0.1/grid/suptools/tfa/release/tfa_home/jlib/jdev-rt.jar‘
Died at /u01/app/12.2.0.1/grid/crs/install/crsutils.pm line 7573.
The command ‚/u01/app/12.2.0.1/grid/perl/bin/perl -I/u01/app/12.2.0.1/grid/perl/lib -I/u01/app/12.2.0.1/grid/crs/install /u01/app/12.2.0.1/grid/crs/install/rootcrs.pl -prepatch‘ execution failed

The following Doc ID 2409411.1 describes how to fix this by modifying two files. I should be fixed in Grid Release 18. 

$GRID_HOME/crs/sbs/crsconfig_fileperms.sbs
$GRID_HOME/crs/utl/<node>/crsconfig_fileperms

remove the following two entries.
unix %ORA_CRS_HOME%/suptools/tfa/release/tfa_home/jlib/jdev-rt.jar %HAS_USER% %ORA_DBA_GROUP% 0644
unix %ORA_CRS_HOME%/suptools/tfa/release/tfa_home/jlib/jewt4.jar %HAS_USER% %ORA_DBA_GROUP% 0644

I made the changes but it did not fix the problem. So I can’t go on with the Patching. For me it looks like a problem with the file permissions.

So next research on MOS and I found this important Doc ID 1931142.1:

„How to check and fix file permissions on Grid Infrastructure environment“

Yes, this was the solution :-)

cd /u01/app/12.2.0.1/grid/crs/install/

./rootcrs.sh -init

Using configuration parameter file: /u01/app/12.2.0.1/grid/crs/install/crsconfig_params

As an add on in the note you can check after the „-init“ the complete GI Installation with the following cluvfy command.

cluvfy comp software -n all -verbose

Verifying Software home: /u01/app/12.2.0.1/grid …2894 files verified
Verifying Software home: /u01/app/12.2.0.1/grid …PASSED

Verification of software was successful.

CVU operation performed: software
Date: Mar 11, 2019 10:10:11 AM
CVU home: /u01/app/12.2.0.1/grid/
User: oracle

This is very helpful. Finally I start the GI Patching without any problems

Lesson learned

„It is a good idea to check from time to time the status of the Software via cluvfy.“

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

exachk 18.4 does not run 12.2.0.1 database

For all of you who use exachk and have updated to exachk Version 18.4. There is a known Bug on Oracle databases 12.2.0.1.

While running exachk as root user the program try to connect to the database and this will no work.

You saw the following message:

„OS authentication is not enabled so please enter sysdba privileged user name for <User name>:- sys

Enter password for sys@<User name>:-

SELECT 1 FROM DUAL

*

ERROR at line 1:

ORA-01012: not logged on

Process ID: 0

Session ID: 0 Serial number: 0“

 

The workaround is to use „-shell“ option when calling exachk

# ./exachk -a -o v -shell

 

 

 

 

 

 

ORAchk (EXAchk) und der Collection Manager (Teil 2)

Nun geht es mit Teil 2 weiter.

Nach dem nun die APEX Installation fertig ist, geht es darum den Collection Manager zu installieren und zu konfigurieren.

Dazu empfehle ich sich für das Setup parallel die Dokumentation, also das User’s Guide „Oracle® ORAchk and EXAchk“ und hier Kapitel 1.9 Oracle Health Check Collections Manager for Oracle“ zu öffnen.

Wir melden uns nun am Admin Service an:

 

http://o1:8080/apex/apex_admin

Der neue „Workspace“ wird erstellt. Im zweiten Schritt wird festgelegt, welches Schema in der Datenbank für die Installation verwendet wird.

 

 

Unter „Manage Workspaces“ sieht man nun den Workspace „ORACHK_CM_WS“ der zukünftig genutzt wird.

Für das eigentliche Setup melde ich mich am an.

Im Folgenden können einzelne personalisierte Benutzer angelegt werden, z. B. für jeden DBA im Unternehmen.

Ich gehe einen Step weiter und beginne mit der eigentlichen Installation:

„Install Oracle Health Check Collections Manager Application“

Bevor ich mit der Installation beginne muss sichergestellt sein, das der Workspace Admin Schema Owner und der Owner des Schemas, welcher für den Import verwendet wird folgende Rechte hat:

  • create job
    • grant create job to orachk_admin
  • execute Rechte auf die Packages DBMS_RLS und UTL_SMTP
    • grant execute to dbms_rls to orachk_admin
    • grant execute on utl_smtp to orachk_admin

Damit sind die Vorbereitungen abgeschlossen.

Login beim  „Workspace Administration Services“ und den  Application Builder auswählen. Danach den Import starten.

Die folgenden Schritte bestätigen und dann beginnt die Installation.

Damit ist die Installation abgeschlossen und wir können nun den Collection Manager starten.

Nach erfolgter Anmeldung bekomme ich einen Überblick und wie könnte es anders sein aber es gibt keine Reports.

Daher lade ich nun „manuell“ einen Orachk Report.

Daten werden dann im täglichen Doing automatisch hochgeladen mit Hilfe von „setdbupload“.

Dazu wird der Setup konfiguriert bei dem der komplette Connect String benötigt wird kein tns-Alias.

UPLOAD_CONNECT_STRING = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)

(HOST=o1.localdomain)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)

(SERVICE_NAME=orachkcm.)))

RAT_UPLOAD_PASSWORD = ******

RAT_UPLOAD_USER = ORACHKCM

RAT_ZIP_UPLOAD_TABLE = RCA13_DOCS

Mit „./orachk -setdbupload all“ wird der Setup eingerichtet.

Überprüfen kann man dann die Konfiguration mit der „checkdbupload“ Funktion.

./orachk -checkdbupload

Wie weit man die Automatisierung vornehmen möchte, hängt im Weiteren stark von der eigenen Umgebung ab, daher empfehle ich hier die Dokumentation zur Hand zu nehmen und noch mal das „Kapitel 1.9.7“ durchzuarbeiten und mögliche Konfigurationen vorzunehmen.

Ich wünsche viel Spaß mit dem Collection Manager.

 

 

 

Oracle DB Upgrade 12.1 auf 12.2

Ich bin gerade dabei einige Datenbanken von 12.1 -> 12.2 upzugraden. Dazu setzte ich den DBUA ein und bin sehr positiv überrascht. Viele Checks werden im Dialog abfragt und diese werden dann während des Upgrade Prozess umgesetzt. Der Upgrade läuft reibungslos durch auch wie in meinem Fall auf RAC Datenbanken.

Möchte man den Pre-Upgrade vorab durchführen und dies per Skript steuern, dann kann man auf Metalink dazu ein Skript herunterladen. Dieses Skript sammelt die relevanten Daten, welche man dann vorab analysieren kann.

Doc ID 556610.1 – Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)

Die komplette Checklist für den Upgrade per DBUA wird dann in der folgenden Doc ID beschrieben.

Doc ID 2189854.1 – Complete Checklist for Upgrading to Oracle Database 12c Release 2 (12.2) using DBUA

Im Nachgang muss dann noch der DB Parameter „compatible“ gesetzt werden.

Hierbei muss berücksichtigt werden, dass es kein Zurück mehr gibt. Ein Downgrade ist dann nicht mehr möglich.

alter system set compatible=’12.2.0.1′ …

Der DBUA in der Version 12.2 ist aus meiner Sicht sehr gut implementiert worden und hat viele wichtige Checks und Features an Bord.

Viel Spaß bei den nächsten Upgrades :-)

 

 

 

 

 

 

Important Change for Grid 12.2 Upgrade and MGMTDB

I just did an Grid Infrastructure Update to Oracle 12.2 with the latest PSU Aug 2017.

I did my preparation with the help of the Doc ID 2111010.1

„12.2 Grid Infrastructure and Database Upgrade steps for Exadata Database Machine running 11.2.0.3 and later on Oracle Linux“

In the Post-upgrade Steps was written that the Management DB should be deconfigured

  • Post-upgrade Steps

      • Deconfigure MGMTDB

 

The deconfigure is obsolete and the MGMTDB is now part of the Update. 

Here the original text from the Doc ID.

September 28,2017
  • MGMTDB will now be part of upgrade, the flags to reove and deconfigure are removed.

 

 

For me it looks like that the revision of the document is not yet finished

So if you plan a Grid Upgrade in the near future read the document very carefully and if needed open an SR

Problems with Adaptive Features in 12.1.0.2 What’s to do?

The Adaptive Features is divided in two parts

  • Adaptive Plans
    • the possibility to change plans during execution
  • Adaptive Statistics
    • the statistics allow plans to be built from the results of previous executions

Version 12.1 

In 12.1 both components  will be managed by the parameter „optimizer_features_enable“ and is per default on „TRUE“.

Version 12.2

In 12.2 the parameter „optimizer_features_enable“ obsolete. The adaptive feature is now controlled by two parameters

  • optimizer_adaptive_statistics default „FALSE“
  • optimizer_adaptive_plans default „TRUE“

What are the recommendation for 12.1.0.2 if you do a upgrade. You should directly adopt the 12.2 default  by applying the following Patches:

  • Patch 22652097 splits the parameter optimizer_adaptive_features into two, as above, and disables adaptive statistics.
  • Patch 21171382 disables the automatic creation of extended statistics unless the optimizer preference AUTO_STAT_EXTENSIONS is set to ON.

Summary

If you Upgrade to 12.1..2 set directly the Default for Oracle 12.2.

Yes, the next Upgrade to Release 12.2 came sooner or later.

 

 

 

Oracle RU is available

Today Oracle released a very large „monster“ Upgrade. This July 2017 Update includes the first time the new RU „Release Upgrade“ and RUR „Release Update Revision“ Patches.

To be up to date read the following My Oracle Support Doc-ID’s

Actually I can’t find a FAQ but I think this will come in a few weeks.

Stay tuned :-)

rman auxiliary (for duplicate)

I just do some tests with the Oracle 12.2 Release and while doing tests it is all the time better to have a second database and that is the time for rman. So I looked around and found an easy way to duplicate a database from a Backup. Here the details:

My environment

OL 7.3 with an Oracle 12.2 + DATABASE BUNDLE PATCH: 12.2.0.1.170516 (25862693)

I setup an database via dbca and use Standards including the fast recovery area. Oh yes the FRA is a standard now

Next I did a backup and here I did a few tests with image copied and „backup as copy database“. While doing this I had a full backup on disk and that is the point to start with the duplicate.

What are the steps?

First I created a initdb2.dup

Yes, for testing I create only one controlfile
initdb2.dup
*.audit_file_dest='/u01/app/oracle/admin/db2_s1/adump'
*.audit_trail='NONE'
*.db_name='db2'
*.db_unique_name='db2_s1'
*.control_files='/u01/app/oracle/fast_recovery_area/db2_s1.ctl'
*.db_create_file_dest='/u01/app/oracle/oradata'
*.db_recovery_file_dest_size=8G
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.enable_pluggable_database=true
*.large_pool_size=256M
*.sga_target=2G

Next I created a few directories and then I started the new instance


sqlplus / as sysdba

startup nomount pfile=/u01/app/oracle/admin/db2/pfile/initd2.dup'

finally I start the duplicate from „BACKUP LOCATION“

 



rman auxiliary /

RMAN>duplicate database to db2 backup location '/u01/app/oracle/fast_recovery_area';

 

That’s it finished :-)

Keep in mind that I set my environment before starting the rman duplicate and the connection is done against the auxiliary instance. Yes, it is very easy to do a duplicate to a new database when you have a full backup on disc.