How I Finished a Recovery From an Active Duplicate After Facing Errors ORA-19909 and ORA-01110

Posted in: Oracle, Technical Track

The other day I was doing a database cloning in 11.2.0.4 from an active duplicate, and got the following error: ORA-19909: datafile 1 belongs to an orphan incarnation and ORA-01110: data file 1.

This post explains how I solved these errors. It’s worth mentioning that what I did here also applies to 12c, 18c and 19c databases.

I first verified that I had the password file from the target database, and that I also had the corresponding TNS entries for it. I created a listener for this task only. Note: the client I was working with required that I create the listener; otherwise I could have worked with the SCAN listener.

Next I verified that I could connect to the target and auxiliary databases correctly. I created the script below to use for this refresh:

##################################################################
## Connectivity Test
##################################################################
oracle $ ls $ORACLE_HOME/dbs/orapwSTG*
/u01/app/oracle/product/11.2.0.4/dbhome_3/dbs/orapwSTG1

oracle $ rman TARGET sys/********@PROD AUXILIARY sys/********@STG_STATIC
connected to target database: PROD (DBID=3874882083)
connected to auxiliary database: STG (not mounted)

##################################################################
## STG_STATIC TNS Entry
##################################################################

STG_STATIC =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = auxiliarydbadm01)(PORT = 1523))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = STG1)
      (UR=A)
    )
  )

##################################################################
## PROD TNS Entry
##################################################################
PROD =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = prod_scan)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = PROD1)
    )
  )

##################################################################
## Listener used
##################################################################
LISTENER_REFRESH =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = auxiliarydbadm01)(PORT = 1523))
    )
  )

SID_LIST_LISTENER_REFRESH =
  (SID_LIST =
    (SID_DESC =
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0.4/dbhome_3)
      (SID_NAME = QA1)
    )
    (SID_DESC =
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0.4/dbhome_3)
      (SID_NAME = STG1)
    )
    (SID_DESC =
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0.4/dbhome_3)
      (SID_NAME = RFSH1)
    )
  )

ADR_BASE_LISTENER = /u01/app/oracle

##################################################################
## recover_from_prod.sh
##################################################################

oracle $ cat recover_from_prod.sh
#!/bin/bash
export NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS'
export ORACLE_SID=STG1
export ORAENV_ASK=NO
. /usr/local/bin/oraenv
rman TARGET sys/********@PROD AUXILIARY sys/********@STG_STATIC <<endofrman
run {
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate channel prmy3 type disk;
allocate channel prmy4 type disk;
allocate channel prmy5 type disk;
allocate channel prmy6 type disk;
allocate auxiliary channel aux1 type disk;
allocate auxiliary channel aux2 type disk;
allocate auxiliary channel aux3 type disk;
allocate auxiliary channel aux4 type disk;
allocate auxiliary channel aux5 type disk;
allocate auxiliary channel aux6 type disk;
DUPLICATE TARGET DATABASE TO 'STG' FROM ACTIVE DATABASE NOFILENAMECHECK;
}
endofrman

I knew this duplicate was going to take a while as this was a 35 TB database.

SQL> SELECT
  ( SELECT SUM(bytes)/power(1024,4) data_size FROM dba_data_files
  ) +
  ( SELECT NVL(SUM(bytes),0)/power(1024,4) temp_size FROM dba_temp_files
  ) +
  ( SELECT SUM(bytes)/power(1024,4) redo_size FROM sys.v_$log
  )                     +
  (SELECT SUM(BLOCK_SIZE*FILE_SIZE_BLKS)/power(1024,3) controlfile_size
  FROM v$controlfile
  ) "Database Size in TB"
FROM dual;

Database Size in TB
-------------------
         35.1021405

Despite the length of time it took, the restore for the duplicate database went well. However, when the recovery process began, I got the following errors:

oracle $ tail -100 recover_from_prod.log
...
Starting recover at 09-NOV-2020 08:27:59

starting media recovery
media recovery failed
Oracle instance started
...
RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed
 start until change 281698833114 using backup controlfile
ORA-00283: recovery session canceled due to errors
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '+DATAC2/stg/datafile/system.636.1056008579'

These errors primarily happened because there were other files in the ASM diskgroup with the same DBID as the auxiliary database I was cloning.

if you’re using ASM disk groups, RMAN works a particular way for an active duplicate. It catalogs everything under the disk group the db_recovery_file_dest parameter is set to if the log_archive_dest_1. parameter is not set.

This was true in my case. In the same cluster there was a standby running called proddr for the target database I was cloning.

##################################################################
## db_recovery_file_dest and log_archive_dest_1 parameter values
##################################################################
oracle $ echo "
> show parameter log_archive_dest_1;
> " | sqlplus -s -L / as sysdba

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1                   string
...

oracle $ echo "
> show parameter db_recovery_file_dest;
> " | sqlplus -s -L / as sysdba

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      +RECOC2
db_recovery_file_dest_size           big integer 20000G


##################################################################
## From the recover_from_prod.log
##################################################################
...
 "+RECOC1/prod/archivelog/2020_11_09/thread_2_seq_535909.41715.1056009955" auxiliary format
 "+RECOC2"   ;
   catalog clone start with  "+RECOC2";
   switch clone datafile all;
}
...
List of Cataloged Files
=======================
File Name: +RECOC2/proddr/CONTROLFILE/current.7901.1022257521
File Name: +RECOC2/stg/archivelog/2020_11_09/thread_2_seq_535877.5618.1056010749
...
File Name: +RECOC2/proddr/archivelog/2020_11_07/thread_2_seq_535588.2240.1055891307
File Name: +RECOC2/proddr/archivelog/2020_11_07/thread_1_seq_567337.8034.1055892763
..
datafile 1 switched to datafile copy
input datafile copy RECID=67 STAMP=1056011218 file name=+DATAC2/stg/datafile/system.636.1056008579
...
datafile 133 switched to datafile copy
input datafile copy RECID=198 STAMP=1056011261 file name=+DATAC2/stg/datafile/aud_tbs.451.1056009851
datafile 134 switched to datafile copy
input datafile copy RECID=199 STAMP=1056011262 file name=+DATAC2/stg/datafile/revenue_ods2.622.1055987265

contents of Memory Script:
{
   set until scn  281698833114;
   recover
   clone database
    delete archivelog
   ;
}

Once I’d investigated the error, I proceeded to fix it. The first thing I did was try to open STG database in mount mode to see the contents of the control file. From the log above I could see the datafile copy had switched and updated the control file, and this would help me speed up recovery of this process.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 2.5655E+10 bytes
Fixed Size		    2265224 bytes
Variable Size		 1.0402E+10 bytes
Database Buffers	 1.5099E+10 bytes
Redo Buffers		  151113728 bytes
*
ERROR at line 1:
ORA-01103: database name 'PROD' in control file is not 'STG'

From the error above, I could see the control file had the incorrect database name. I would have to recreate the control file for this.

I wanted to avoid going to ASM or the recover log to gather all the datafiles and their location. Instead, I created a small parameter file that included only the control file, the block size, the same compatible parameter and the name of the target database as database PROD as shown in the error ORA-01103 above.

Once I had the database PROD up, I backed up that database control file to trace.

oracle $ cat initprod.ora
DB_NAME=PROD
DB_UNIQUE_NAME=PROD
DB_BLOCK_SIZE=8192
*.control_files='/home/oracle/working/antunez/STG/control02.ctl'
*.compatible='11.2.0.4.0'

SQL> startup mount pfile='/home/oracle/working/antunez/initprod.ora';
ORACLE instance started.

Total System Global Area  513642496 bytes
Fixed Size                  2254624 bytes
Variable Size             402655456 bytes
Database Buffers          100663296 bytes
Redo Buffers                8069120 bytes
Database mounted.

SQL> alter database backup controlfile to trace as '/home/oracle/working/antunez/stg.sql';

Database altered.

SQL> shutdown abort
ORACLE instance shut down.

Once I had the control file trace with the proper datafile location, I modified it to leave only the section of RESETLOGS and change the line of CREATE CONTROL FILE to use the SET command.

With that done, I ran the creation of the control file in STG database.

oracle $ cat /home/oracle/working/antunez/stg.sql
CREATE CONTROLFILE REUSE SET DATABASE "STG" RESETLOGS FORCE LOGGING ARCHIVELOG
    MAXLOGFILES 192
    MAXLOGMEMBERS 3
    MAXDATAFILES 1024
    MAXINSTANCES 32
    MAXLOGHISTORY 149504
LOGFILE
  GROUP 11 (
    '+DATAC2/stg/onlinelog/group_11.3162.914669717',
...
  '+DATAC2/stg/datafile/sysaux.454.1056009483',
  '+DATAC2/stg/datafile/users.448.1056009331',
  '+DATAC2/stg/datafile/users.455.1056009819'
CHARACTER SET AL32UTF8
;
oracle $ . oraenv <<< STG1
SQL> startup nomount;
ORACLE instance started.

Total System Global Area 2.5655E+10 bytes
Fixed Size		    2265224 bytes
Variable Size		 1.0402E+10 bytes
Database Buffers	 1.5099E+10 bytes
Redo Buffers		  151113728 bytes

SQL> @/home/oracle/working/antunez/stg.sql

Control file created.

SQL> select open_mode from v$database;
OPEN_MODE
--------------------
MOUNTED

What I needed next were the archived redo logs that were going to be used for the recovery, as some of the archivelogs were not copied.

RMAN thought they were already in place for the recovery due to them being in the auxiliary host for the proddr standby database. So I followed the steps below to find the range of archived redo logs I was going to need.

If you remember the script I used, I set the NLS environment variable to this export NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS', so the log would contain the details of the times down to seconds from the RMAN output. This turned out to be useful.

I extracted the until scn and the Starting Duplicate Db outputs from the log. I then obtained the range of archived redo log sequences I was going to need from the target database called PROD.

oracle $ cat recover_from_prod.log | egrep "Starting Duplicate Db at | scn"
Starting Duplicate Db at 08-NOV-2020 17:07:35
   set until scn  281698833114;

oracle $ sqlplus sys/****@PROD as sysdba
...
SQL> select name from v$database;

NAME
---------
PROD

SQL> col scn format 999999999999999999999
SQL> select timestamp_to_scn(to_timestamp('08-11-2020 17:07:34','dd-mm-yyyy hh24:mi:ss')) scn from dual;

                   SCN
----------------------
          281674037748

SQL> select distinct thread#, sequence#, status, first_time, next_time, first_change#, next_change# from v$archived_log
where 281674037748 between first_change# and next_change# order by 1,2; 

   THREAD#  SEQUENCE# S FIRST_TIME          NEXT_TIME           FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- - ------------------- ------------------- ------------- ------------
         1     567552 A 2020-11-08 17:04:19 2020-11-08 17:07:37    2.8167E+11   2.8167E+11
         2     535731 A 2020-11-08 17:05:00 2020-11-08 17:07:36    2.8167E+11   2.8167E+11

SQL> select distinct thread#, sequence#, status, first_time, next_time, first_change#, next_change# from v$archived_log
where 281698833114 between first_change# and next_change# order by 1,2; 

   THREAD#  SEQUENCE# S FIRST_TIME          NEXT_TIME           FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- - ------------------- ------------------- ------------- ------------
         1     567681 A 2020-11-09 08:05:54 2020-11-09 08:06:09    2.8170E+11   2.8170E+11
         1     567682 A 2020-11-09 08:06:09 2020-11-09 08:10:27    2.8170E+11   2.8170E+11
         2     535910 A 2020-11-09 08:05:54 2020-11-09 08:06:09    2.8170E+11   2.8170E+11

With the data above, I ran the following to backup copy command. This allowed me to obtain the archived redo logs necessary for this recovery.

Please note I did it to a different location than the current db_recovery_file_dest and I had to connect to both PROD and STG databases for this command.

oracle $ rman TARGET sys/********@PROD AUXILIARY sys/********@STG_STATIC
RMAN> run {
      backup as copy archivelog from sequence 567552 until sequence 567682 thread 1 auxiliary format '/u02/pythian/STG/%t_%s_%r.arc';
      backup as copy archivelog from sequence 535731 until sequence 535910 thread 2 auxiliary format '/u02/pythian/STG/%t_%s_%r.arc';
    }

Once the copy of the archived redo logs were restored, I registered them to the control file of the STG database.

oracle $ . oraenv <<< STG
oracle $ rman target /
connected to target database: STG (DBID=3874882083, not open)

RMAN> catalog start with '/u02/pythian/STG/;
cataloging files...
cataloging done

List of Cataloged Files
=======================
...
File Name: /u02/pythian/STG/1056028905_128319_904050853.arc
File Name: /u02/pythian/STG/1056030309_128439_904050853.arc

The last thing I needed to do was recover the STG database to the SCN found in the recover log. I made sure not to connect to the target database called PROD, but rather only to the database called STG.

oracle $ . oraenv <<< STG1

oracle $ rman target /
connected to target database: STG (DBID=3874882083, not open)

RMAN> run {
   set until scn 281698833114;
   recover database;
}

executing command: SET until clause

Starting recover at 09-NOV-20
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=3142 device type=DISK

starting media recovery

archived log for thread 1 with sequence 567626 is already on disk as file /u02/pythian/STG/1056029933_128385_904050853.arc
archived log for thread 1 with sequence 567627 is already on disk as file /u02/pythian/STG/1056029940_128386_904050853.arc
archived log for thread 1 with sequence 567628 is already on disk as file /u02/pythian/STG/1056029941_128387_904050853.arc
archived log for thread 1 with sequence 567629 is already on disk as file /u02/pythian/STG/1056029942_128388_904050853.arc
archived log for thread 1 with sequence 567630 is already on disk as file /u02/pythian/STG/1056029943_128389_904050853.arc
archived log for thread 1 with sequence 567631 is already on disk as file /u02/pythian/STG/1056029945_128390_904050853.arc
archived log for thread 1 with sequence 567632 is already on disk as file /u02/pythian/STG/1056029952_128391_904050853.arc
...
archived log file name=/u02/pythian/STG/1056028890_128318_904050853.arc thread=2 sequence=535909
archived log file name=/u02/pythian/STG/1056030309_128439_904050853.arc thread=1 sequence=567680
archived log file name=/u02/pythian/STG/1056030310_128440_904050853.arc thread=1 sequence=567681
archived log file name=/u02/pythian/STG/1056028905_128319_904050853.arc thread=2 sequence=535910
media recovery complete, elapsed time: 00:06:35
Finished recover at 09-NOV-20

After this I simply needed to open the database as resetlogs. I also wanted the cloned database to have a new DBID and to come up as a RAC database. I verified the database and instance status using verify_data_dictionary_11g.sql.

RMAN> alter database open resetlogs;

using target database control file instead of recovery catalog
database opened

RMAN> delete archivelog all;
...
Deleted 353 objects
RMAN> shutdown immediate

database shutdown

RMAN> STARTUP MOUNT

database mounted

RMAN> exit

oracle $ nid target=sys/*******

DBNEWID: Release 11.2.0.4.0 - Production on Mon Nov 9 14:34:22 2020

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to database STG (DBID=3874882083)

Connected to server version 11.2.0

Control Files in database:
    +DATAC2/stg/controlfile/control01.ctl
    +RECOC2/stg/controlfile/control02.ctl

Change database ID of database STG? (Y/[N]) => Y

Proceeding with operation
Changing database ID from 3874882083 to 1490626863
    Control File +DATAC2/stg/controlfile/control01.ctl - modified
    Control File +RECOC2/stg/controlfile/control02.ctl - modified
    Datafile +DATAC2/stg/datafile/system.636.105600857 - dbid changed
    ...
    Datafile +DATAC2/stg/datafile/revenue_ods2.622.105598726 - dbid changed
    Control File +DATAC2/stg/controlfile/control01.ctl - dbid changed
    Control File +RECOC2/stg/controlfile/control02.ctl - dbid changed
    Instance shut down

Database ID for database STG changed to 1490626863.
All previous backups and archived redo logs for this database are unusable.
Database is not aware of previous backups and archived logs in Recovery Area.
Database has been shutdown, open database with RESETLOGS option.
Succesfully changed database ID.
DBNEWID - Completed succesfully.

oracle $ sqlplus / as sysdba
...
SQL> startup mount
ORACLE instance started.

Total System Global Area 1.6034E+11 bytes
Fixed Size                  2261848 bytes
Variable Size            2.5233E+10 bytes
Database Buffers         1.3475E+11 bytes
Redo Buffers              352444416 bytes
Database mounted.

SQL> ALTER DATABASE OPEN RESETLOGS;

Database altered.

SQL> ALTER SYSTEM SET cluster_database=TRUE SCOPE=spfile;
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

oracle $ srvctl start database -d STG
oracle $ srvctl status database -d STG
Instance STG1 is running on node auxiliarydbadm01
Instance STG2 is running on node auxiliarydbadm02

oracle $ sqlplus / as sysdba
SQL> @verify_data_dictionary_11g.sql
DATABASE NAME
=============
DBNAME
---------------
STG

================================================================================================
==   Oracle Instance Information
================================================================================================

--  IP Address   1**.***.***.30

   Cpu_Count                   24    |    Host_Name       auxiliarydbadm01
   Instance_Name             STG1    |    Database_Status           ACTIVE
   Status                    OPEN    |    Startup_Time    09-11-2020 14:43
   Version             11.2.0.4.0    |    Instance_Role   PRIMARY_INSTANCE

   Database log mode            ARCHIVELOG

   Background Dump Dest         /u01_diag/app/oracle/diag/diag/rdbms/stg/STG1/trace
   Spfile                       +DATAC2/stg/parameterfile/spfilestg.ora

   Redo size (Gb)            1.953125
   Redo size (Gb)           .09765625
-- Database Space (Gb)   35367.70    |    SGA (Gb)                149.3303 --
-- Nb. Datafiles              133    |    Nb. Tempfiles                 15 --


DBA_REGISTRY CONTENTS
================================================================

COMP_ID              COMP_NAME                                VERSION         Status
-------------------- ---------------------------------------- --------------- --------------------------------------------------
OWB                  OWB                                      11.2.0.4.0      VALID
APEX                 Oracle Application Express               3.2.1.00.12     VALID
EM                   Oracle Enterprise Manager                11.2.0.4.0      VALID
AMD                  OLAP Catalog                             11.2.0.4.0      VALID
SDO                  Spatial                                  11.2.0.4.0      VALID
ORDIM                Oracle Multimedia                        11.2.0.4.0      VALID
XDB                  Oracle XML Database                      11.2.0.4.0      VALID
CONTEXT              Oracle Text                              11.2.0.4.0      VALID
EXF                  Oracle Expression Filter                 11.2.0.4.0      VALID
RUL                  Oracle Rules Manager                     11.2.0.4.0      VALID
OWM                  Oracle Workspace Manager                 11.2.0.4.0      VALID
CATALOG              Oracle Database Catalog Views            11.2.0.4.0      VALID
CATPROC              Oracle Database Packages and Types       11.2.0.4.0      VALID
JAVAVM               JServer JAVA Virtual Machine             11.2.0.4.0      VALID
XML                  Oracle XDK                               11.2.0.4.0      VALID
CATJAVA              Oracle Database Java Packages            11.2.0.4.0      VALID
APS                  OLAP Analytic Workspace                  11.2.0.4.0      VALID
XOQ                  Oracle OLAP API                          11.2.0.4.0      VALID
RAC                  Oracle Real Application Clusters         11.2.0.4.0      VALID

19 rows selected.

LIST APPLIED PATCHES
=======================

ACTION_TIME                    ID         ACTION                         VERSION         BUNDLE                   COMMENTS
------------------------------ ---------- ------------------------------ --------------- ------------------------ --------------
24-AUG-13 12.03.45.119862 PM   0          APPLY                          11.2.0.4        PSU                      Patchset 11.2.0.2.0
17-FEB-16 01.17.34.459872 PM   0          jvmpsu.sql                     11.2.0.4                                 RAN jvmpsu.sql
17-FEB-16 01.18.26.518633 PM   20         APPLY                          11.2.0.4        EXA                      BP20
24-JUN-17 05.01.00.394556 AM   0          jvmpsu.sql                     11.2.0.4                                 RAN jvmpsu.sql
24-JUN-17 05.01.00.414355 AM   0          APPLY                          11.2.0.4                                 OJVM PSU post-instal
24-JUN-17 05.01.00.416012 AM   25434033   APPLY                                                                   Patch 25434033 appli
24-JUN-17 05.01.23.110902 AM   170418     APPLY                          11.2.0.4        EXA                      BP170418
24-JAN-19 07.48.56.741239 PM   180717     APPLY                          11.2.0.4        EXA                      BP180717
24-JAN-19 09.00.45.442572 PM   0          jvmpsu.sql                     11.2.0.4                                 RAN jvmpsu.sql
24-JAN-19 09.00.45.707068 PM   0          APPLY                          11.2.0.4                                 OJVM PSU post-instal
24-JAN-19 09.00.45.709711 PM   27923163   APPLY                                                                   Patch 27923163 appli

11 rows selected.

LIST APPLIED SQL PATCHES
=======================

COMMENTS                                                     ACTION                         ACTION_DATE          VERSION
------------------------------------------------------------ ------------------------------ -------------------- ---------------
RAN jvmpsu.sql                                               jvmpsu.sql                     17/02/16 13:17:34    11.2.0.4.5OJVMB
                                                                                                                 P

BP20                                                         APPLY                          17/02/16 13:18:26    11.2.0.4
BP180717                                                     APPLY                          24/01/19 19:48:56    11.2.0.4
RAN jvmpsu.sql                                               jvmpsu.sql                     24/01/19 21:00:45    11.2.0.4.180717
                                                                                                                 OJVMPSU

OJVM PSU post-install                                        APPLY                          24/01/19 21:00:45    11.2.0.4.180717
                                                                                                                 OJVMPSU

Patch 27923163 applied                                       APPLY                          24/01/19 21:00:45
OJVM PSU post-install                                        APPLY                          24/06/17 05:01:00    11.2.0.4.170418
                                                                                                                 OJVMPSU

RAN jvmpsu.sql                                               jvmpsu.sql                     24/06/17 05:01:00    11.2.0.4.170418
                                                                                                                 OJVMPSU

Patch 25434033 applied                                       APPLY                          24/06/17 05:01:00
BP170418                                                     APPLY                          24/06/17 05:01:23    11.2.0.4
Patchset 11.2.0.2.0                                          APPLY                          24/08/13 12:03:45    11.2.0.4

11 rows selected.

COUNT OF INVALID OBJECTS
========================

  COUNT(*)
----------
         0

1 row selected.

INVALID OBJECTS GROUPED BY OBJECT TYPE AND OWNER
================================================

no rows selected

LIST OF SYS INVALID OBJECTS
=======================

no rows selected

If you ever face the errors ORA-19909 and ORA-01110, I hope this blog post helps . It took me a while to solve this, and knowing the above would have come in handy.

Note: This was originally posted on rene-ace.com.

email

Authors

Interested in working with Rene? Schedule a tech call.

About the Author

Currently I am an Oracle ACE ; Speaker at Oracle Open World, Oracle Developers Day, OTN Tour Latin America and APAC region and IOUG Collaborate ; Co-President of ORAMEX (Mexico Oracle User Group); At the moment I am an Oracle Project Engineer at Pythian. In my free time I like to say that I'm Movie Fanatic, Music Lover and bringing the best from México (Mexihtli) to the rest of the world and in the process photographing it ;)

2 Comments. Leave new

Grzegorz Gorysz
November 20, 2020 2:23 pm

Very useful, thank You.
Regards.
G

Reply

No problem at all

René

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *