AWR to text with filter and sections

Hi,

 here bring for you a new script for get information about AWR performance, but right now applying certain filter for review only sections like: "Top Timed Foreground Events", "Database Summary", etc.. For my script i use the package DBMS_WORKLOAD_REPOSITORY.AWR_GLOBAL_REPORT_TEXT with some aggregate functions (warning before you execute this script you should care about your license, you need diagnostic pack License )

source script:
https://github.com/felipower/scripts_oracle/blob/master/FDB_Oracle_AWR_summary_filtered.sql

Example (screenshots for execution)

Enjoy the script and share it.

SQL Developer performance TIPs (MacOS)

A while ago, i have experienced problems related to sqldeveloper performance (and especially on my MacOS), for that reason i'll share some tips about that:

1.- Change Look and Feel to "Mac OS X". That option will consume less memory and will perform better: 

On SQLDeveloper Menu -> Preferences -> Environment

2.- To improve even more, disable Completion Insight.

On SQLDeveloper Menu -> Preferences -> Code Editor -> Completion Insight

3.- Disable options and Features unused.

On SQLDeveloper Menu -> Tools -> Features

4.- To adjust SQLDeveloper Options like memory consumption on the configuration file. In my case the file is stored on:

/Users/USERNAME/.sqldeveloper/19.1.0/product.conf

On that file we could modify for instance the jvm max memory consumption, add the next parameter:

AddVMOption -Xmx300m

Add32VMOption -Xmx300m

Add64VMOption -Xmx300m

And at next sqldeveloper reboot, we can see is already up with the new parameter, for example:

felipes-MacBook-Pro:19.1.0 felipedonoso$ ps -fea | grep sqldeveloper | grep Xmx

  501  2723  2307   0 10:42AM ??         5:19.18 /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java -Xbootclasspath/a:/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/lib/tools.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/lib/dt.jar -Djdeveloper.system_http_proxy=DIRECT -Djdeveloper.system_http_non_proxy_hosts= -Dsun.java2d.noddraw=true -XX:CompileCommand=quiet -XX:CompileCommand=exclude,javax/swing/text/GlyphView,getBreakSpot -Dnetbeans.home=../../ide/bin/../../netbeans/platform/ -Dnetbeans.logger.console=true -Dexcluded.modules=org.eclipse.osgi -Dide.cluster.dirs=../../ide/bin/../../netbeans/fcpbridge/:../../ide/bin/../../netbeans/ide/:../../ide/bin/../../netbeans/../ -Xverify:none -Doracle.ide.extension.HooksProcessingMode=LAZY -Dorg.eclipse.equinox.simpleconfigurator.configUrl=file:bundles.info -Dosgi.bundles.defaultStartLevel=1 -Dosgi.configuration.cascaded=false -Dosgi.noShutdown=true -Dorg.osgi.framework.bootdelegation=* -Dosgi.parentClassloader=app -Dosgi.locking=none -Dosgi.contextClassLoaderParent=app -Dosgi.classloader.type=parallel -Dosgi.bundlefile.limit=500 -Dide.feedback-server=ide.us.oracle.com -Djavax.xml.transform.TransformerFactory=oracle.ide.xml.switchable.SwitchableTransformerFactory -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory -Djavax.xml.stream.util.XMLEventAllocator=oracle.ideimpl.xml.stream.XMLEventAllocatorImpl -Doracle.ide.reportEDTViolations=bug -Doracle.ide.reportEDTViolations.exceptionsfile=../../ide/bin/swing-thread-violations.conf -Xms128M -Xmx800M -Doracle.ide.IdeFrameworkCommandLineOptions=-clean,-console,-debugmode,-migrate,-migrate:,-nomigrate,-nonag,-nondebugmode,-noreopen,-nosplash,-role:,-su -Dide.update.usage.servers=https://www.oracle.com/webfolder/technetwork/sqldeveloper/usage.xml -Doracle.ide.util.AddinPolicyUtils.OVERRIDE_FLAG=true -Dsun.java2d.ddoffscreen=false -Dwindows.shell.font.languages= -Doracle.ide.startup.features=sqldeveloper -Doracle.ide.osgi.boot.api.OJStartupHook=oracle.dbtools.raptor.startup.HomeSupport -Doracle.jdbc.mapDateToTimestamp=false -Doracle.jdbc.autoCommitSpecCompliant=false -Doracle.jdbc.useFetchSizeWithLongColumn=true -Dsun.locale.formatasdefault=true -Dorg.netbeans.CLIHandler.server=false -Doracle.xdkjava.security.resolveEntityDefault=false -Dide.AssertTracingDisabled=true -Doracle.ide.util.AddinPolicyUtils.OVERRIDE_FLAG=true -Djava.util.logging.config.file=logging.conf -Dsqldev.debug=false -Dsqldev.onsd=true -Dcom.apple.mrj.application.apple.menu.about.name=SQL_Developer -Dcom.apple.mrj.application.growbox.intrudes=false -Dcom.apple.macos.smallTabs=true -Dapple.laf.useScreenMenuBar=true -Xdock:name=Oracle SQL Developer -Xdock:icon=SQLDeveloperIcons.icns -Xmx300m -Dide.conf="/Applications/SQLDeveloper.app/Contents/Resources/sqldeveloper/sqldeveloper/bin/sqldeveloper.conf" -Duser.conf="/Users/felipedonoso/.sqldeveloper/19.1.0/product.conf" -Dtool.user.conf="/Users/felipedonoso/.sqldeveloper/19.1.0/sqldeveloper.conf" -Dide.startingcwd="/Applications/SQLDeveloper.app/Contents/Resources/sqldeveloper/sqldeveloper/bin" -Xmx300m -Xbootclasspath/p:../../ide/bin/../../rdbms/jlib/ojdi.jar -classpath ../../ide/bin/../../ide/lib/ide-boot.jar:../../ide/bin/../../netbeans/platform/lib/boot.jar:../../ide/bin/../../netbeans/platform/lib/org-openide-util-ui.jar:../../ide/bin/../../netbeans/platform/lib/org-openide-util.jar:../../ide/bin/../../netbeans/platform/lib/org-openide-util-lookup.jar:../../ide/bin/../../netbeans/platform/lib/org-openide-modules.jar:../../ide/bin/../../ide/lib/fcpboot.jar:../../ide/bin/../../ide/lib/xml-factory.jar:../../ide/bin/../../ide/lib/woodstox-core-asl-4.2.0.jar:../../ide/bin/../../ide/lib/stax2-api-3.1.1.jar:../lib/oracle.sqldeveloper.homesupport.jar oracle.ide.osgi.boot.OracleIdeLauncher

For right now that's all my tips. In the future i'ill add more tips.

Regards.

Bug 24590018 on exadata SCM0 on TOP process CPU Consumption.

First of all: Sorry for my languaje, my english is not very rich, 😔

Straight to the point ... 

Some days ago i was working in a database migration from Onprem to cloud environment (Exadata), and i could see that scm background process it was on TOP con CPU consumption (it was so weird because that database was inactive without active users on it)

TOP example:

op - 13:31:04 up 72 days, 11:01,  4 users,  load average: 13.41, 9.01, 7.45
Tasks: 5896 total,  13 running, 5870 sleeping,   0 stopped,  13 zombie
%Cpu(s): 22.0 us,  2.6 sy,  0.0 ni, 75.1 id,  0.0 wa,  0.0 hi,  0.1 si,  0.1 st
KiB Mem : 74261779+total,  5118632 free, 57913158+used, 15836755+buff/cache
KiB Swap: 16777212 total, 16776784 free,      428 used. 14184574+avail Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 74136 oracle    20   0 8299256  89592  82416 R  98.4  0.0  30840:38 ora_scm0_ctmtst
265577 oracle    20   0   79.7g 865372  85984 R  98.4  0.1   1518:56 oracle
343847 oracle    20   0   80.3g 117968  85712 R  67.7  0.0   8:10.80 oracle
 49052 odhagent  20   0   25.7g 464020  10012 S  28.8  0.1   4959:42 java
 24823 root      20   0 6273548 822004  61116 S  24.1  0.1   1526:05 ohasd.bin
  1887 oracle    20   0 8282336  99408  91092 S  22.6  0.0   0:00.72 oracle_1887_ctm
  1863 oracle    20   0 8413404  99384  91068 S  22.3  0.0   0:00.71 oracle_1863_ctm
393677 oracle    20   0   79.0g  84496  70540 S  22.3  0.0   0:02.01 oracle
396019 oracle    20   0  180680  82388  28944 S  21.9  0.0   0:04.45 rman
  1872 oracle    20   0 8413408  98800  90480 S  21.6  0.0   0:00.69 oracle_1872_ctm
  1877 oracle    20   0 8282332  98908  90572 S  21.6  0.0   0:00.69 oracle_1877_ctm
255797 oracle    -2   0 7749688  63404  59912 S  21.6  0.0   1159:44 ora_vktm_ctmts5
396710 oracle    20   0  180692  82420  28992 S  21.6  0.0   0:04.43 rman
  1867 oracle    20   0 8544480  98284  89968 S  21.3  0.0   0:00.68 oracle_1867_ctm

We can also observe that process it had 514 hrs aprox. or 21 days aprox. of CPU consumption, awesome 😳🤨

Although i had the instance running only few days ago, i cloud see that BG procces SCM it was on TOP of the list : / very weird. Well, that behaviour is a issue, specific this:
12.2 RAC DB Background process SCM0 consuming excessive CPU (Doc ID 2373451.1)

That is a bug: Bug 24590018 - RAC PERF: SCM0 PROCESS USING 100% CPU, FG'S USING ~80% SYS CPU POSTING SCM0

From the note the support mentions us the solution: 

The DLM Statistics Collection and Management slave (SCM0) is responsible for collecting and managing the statistics related to global enqueue service (GES) and global cache service (GCS). This slave exists only if DLM statistics collection is enabled.
The value is set to 1. Please go ahead and run the following command to change the value of _dlm to 0:
kill -9 <os pid of SCM0>

alter system set "_dlm_stats_collect" = 0 scope = spfile sid = '*';
This does require a reboot for changes to take effect. If a reboot is not an option, as a workaround you may kill the SCM0 process at OS level, it will respawn a new process soon.

Disabling DML STAT COLLECT has no negative impact on performance or other things on 12.2. However on 18c or 19c it should be enabled again. For the moment there are not report this negative behaviour on the last database versions.

Algunas conceptos de SQL_ID, HASH_VALUE, etc..

Una aclaración corta pero necesaria del SQL_ID.

Oracle cuando realiza parsing de una consulta, genera con un algoritmo un Hashing MD5 de 128 bits de largo para cada consulta. Luego toma los últimos 64 bits de dicho hashing y crea lo que conocemos hoy en día como SQL_ID, el cual tiene 13 caracteres de largo. Este se compone de una mezcla de números y letras (base32), es decir 32 caracteres en total que serán usados para dar forma al hashing de SQL_ID final (de 13 caracteres).

Por ejemplo si ejecutamos una simple consulta como: select * from dual ; veremos que en el interior de la shared_pool se creará un nuevo SQL_ID, seguido de un hash_value. Ejemplo:

SQL> select * from dual;

D

-

X

SQL> 

SQL> select sql_id, hash_value from v$sql

where sql_text = 'select * from dual';  2  

SQL_ID       HASH_VALUE

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

a5ks9fhw2v9s1  942515969

Lo anterior entrega el SQL_ID: a5ks9fhw2v9s1 y a partir de dicho SQL_ID oracle también crea el valor del identificador HASH_VALUE. Este valor era el que se usaba para identificar a una consulta en las versiones oracle 9i hacia atrás. Hay una diferencia eso si que cabe recalcar, en oracle9i y en oracle10g el algoritmo que se ocupa para crear ese hash_value es distinto. La vista GV$SQL o V$SQL posee la columna old_hash_value para mostrar también el valor hash_value que tendría nuestro SQL_ID pero como si fuese visto sobre un motor oracle9i o anterior.

A modo de ejemplo oracle crea el hash_value de la consulta ocupando el siguiente algoritmo (ocupando como parámetro el SQL_ID):

(la consulta original está en la página del genial TanelPoder, abajo en la bibliografia se encuentra el link original)

select
trunc(mod(sum((instr('0123456789abcdfghjkmnpqrstuvwxyz',substr(lower(trim('a5ks9fhw2v9s1')),level,1))-1)
                       *power(32,length(trim('a5ks9fhw2v9s1'))-level)),power(2,32))) hash_value
from
    dual
connect by
    level <= length(trim('a5ks9fhw2v9s1'))

Si ejecutamos la consulta usando el sql_id del ejemplo anterior para la query "select * from dual", veremos que entrega el mismo hash_value visto en la consulta anterior:

HASH_VALUE

----------

 942515969

Como mencionamos anteriormente el sql_id es una mezcla de hashing md5 y funciones Hexadecimales con 32 caracteres que retorna un número de 13 dígitos de largo. El algoritmo usado para generar lo anterior que mencionamos que da forma al SQL_ID, puede ser visto con la siguiente función que ha creado el señor Carlos Sierra (al final se encuentra el link hacia la fuente original)

CREATE OR REPLACE FUNCTION compute_sql_id (sql_text IN CLOB)
RETURN VARCHAR2 IS
 BASE_32 CONSTANT VARCHAR2(32) := '0123456789abcdfghjkmnpqrstuvwxyz';
 l_raw_128 RAW(128);
 l_hex_32 VARCHAR2(32);
 l_low_16 VARCHAR(16);
 l_q3 VARCHAR2(8);
 l_q4 VARCHAR2(8);
 l_low_16_m VARCHAR(16);
 l_number NUMBER;
 l_idx INTEGER;
 l_sql_id VARCHAR2(13);
BEGIN
 l_raw_128 := /* use md5 algorithm on sql_text and produce 128 bit hash */
 SYS.DBMS_CRYPTO.hash(TRIM(CHR(0) FROM sql_text)||CHR(0), SYS.DBMS_CRYPTO.hash_md5);
 l_hex_32 := RAWTOHEX(l_raw_128); /* 32 hex characters */
 l_low_16 := SUBSTR(l_hex_32, 17, 16); /* we only need lower 16 */
 l_q3 := SUBSTR(l_low_16, 1, 8); /* 3rd quarter (8 hex characters) */
 l_q4 := SUBSTR(l_low_16, 9, 8); /* 4th quarter (8 hex characters) */
 /* need to reverse order of each of the 4 pairs of hex characters */
 l_q3 := SUBSTR(l_q3, 7, 2)||SUBSTR(l_q3, 5, 2)||SUBSTR(l_q3, 3, 2)||SUBSTR(l_q3, 1, 2);
 l_q4 := SUBSTR(l_q4, 7, 2)||SUBSTR(l_q4, 5, 2)||SUBSTR(l_q4, 3, 2)||SUBSTR(l_q4, 1, 2);
 /* assembly back lower 16 after reversing order on each quarter */
 l_low_16_m := l_q3||l_q4;
 /* convert to number */
 SELECT TO_NUMBER(l_low_16_m, 'xxxxxxxxxxxxxxxx') INTO l_number FROM DUAL;
 /* 13 pieces base-32 (5 bits each) make 65 bits. we do have 64 bits */
 FOR i IN 1 .. 13
 LOOP
 l_idx := TRUNC(l_number / POWER(32, (13 - i))); /* index on BASE_32 */
 l_sql_id := l_sql_id||SUBSTR(BASE_32, (l_idx + 1), 1); /* stitch 13 characters */
 l_number := l_number - (l_idx * POWER(32, (13 - i))); /* for next piece */
 END LOOP;
 RETURN l_sql_id;
END compute_sql_id;
/

Si creamos esa función en nuestra BD y la ejecutamos indicando nuestro Statement completo como parámetro veremos el mismo SQL_ID que habíamos visto en la shared pool al comienzo:

SQL> SELECT compute_sql_id('select * from dual') sql_id from dual ;

SQL_ID

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

a5ks9fhw2v9s1

Ahora surge una pregunta que muchas personas pueden hacerse ¿Puede repetirse un SQL_ID para dos consultas absolutamente distintas? La respuesta es SI. Ya en el hash_value las colisiones se sabia que podían existir (y eso que el algoritmo trabaja en ese caso con un Hashing de 32bits). Para evitar eso se creo el SQL_ID basado en un algoritmo que genera un número único mucho más largo. En algunas pruebas realizadas por un DBA del Cern llamado Luca Canali (a quien recomiendo leer mucho para eso ver link de su nota al respecto en la bibliografía) se encontró que se necesitaron generar casi 10billones de pruebas con consultas de texto similares para generar algunas pocas colisiones. Eso demuestra que actualmente el SQL_ID es la manera más eficiente de asegurar la identificación única para una consulta en la base de datos.

En resumen el SQL_ID es fruto de funciones Hexadecimales y conversiones MD5 que resulta en un número de 13 digitos, y el hash_value es formado por los últimos 32bits del hashing md5 del SQL_ID.

Aquí la bibliografía que recomiendo leer Bibliografía:
https://blog.tanelpoder.com/2009/02/22/sql_id-is-just-a-fancy-representation-of-hash-value/

https://carlos-sierra.net/2013/09/12/function-to-compute-sql_id-out-of-sql_text/

https://externaltable.blogspot.com/2012/06/hash-collisions-sql-signatures-and.html

Agregar nueva tabla a un ambiente de Replicación Golden Gate Existente

Esto es el paso a paso para agregar una nueva tabla a un ambiente de replicación de Golden Gate ya existente. En este caso agregaremos dos nuevas tablas sobre un extractor, pump y replicador de Golden Gate.

Tablas a agregar:

SIEBEL.CX_ELEGIBILIDAD

SIEBEL.CX_ITEM_ELEGI

Extractores, Pump y Replicadores que editaremos:

Extractor: E_S_STG1    

PMP:   P_S_STG1    

Replicador: R_S_STG1    

1.    Primer paso es detener el replicador en el cual agregaremos nuestra tabla en el ambiente de DESTINO o TARGET:

[oracle@miscanti oragg]$ ./ggsci

Oracle GoldenGate Command Interpreter for Oracle

Version 12.1.2.1.0 OGGCORE_12.1.2.1.0_PLATFORMS_140727.2135.1_FBO

Linux, x64, 64bit (optimized), Oracle 12c on Aug 7 2014 10:21:34

Operating system character set identified as UTF-8.

Copyright (C) 1995, 2014, Oracle and/or its affiliates. All rights reserved.

GGSCI (miscanti) 1> info all

Program     Status Group       Lag at Chkpt Time Since Chkpt

MANAGER     RUNNING

REPLICAT    RUNNING R_B_STG1    00:00:40 00:00:07

REPLICAT    RUNNING R_S_STG1    00:00:00 00:00:04

GGSCI (miscanti) 2> stop R_S_STG1

Sending STOP request to REPLICAT R_S_STG1 ...

Request processed.

GGSCI (miscanti) 4> info all

Program     Status Group       Lag at Chkpt Time Since Chkpt

MANAGER     RUNNING

REPLICAT    RUNNING R_B_STG1    00:00:00 00:00:07

REPLICAT    STOPPED     R_S_STG1    00:00:00      00:04:12

Tenemos que asegurarnos de que el replicador no vuelva a subir de nuevo.

2.    Ahora en el ambiente de ORIGEN procederemos activar el supplemental logging de las tablas (usando la herramienta de ggsci y conectados a la instancia de BD):

GGSCI (edc01dbadm03.vtr.cl) 1> info all

Program     Status Group       Lag at Chkpt Time Since Chkpt

MANAGER     RUNNING

EXTRACT     RUNNING     E_S_STG1    00:00:04      00:00:09

EXTRACT     RUNNING P_S_STG1   00:00:00 00:00:06

GGSCI (edc01dbadm03.vtr.cl) 2> DBLOGIN USERID ogg_user@SBLQA, PASSWORD oracle

Successfully logged into database.

GGSCI (edc01dbadm03.vtr.cl as ogg_user@SBLQA4) 3> ADD TRANDATA SIEBEL.CX_ELEGIBILIDAD

Logging of supplemental redo data enabled for table SIEBEL.CX_ELEGIBILIDAD.

TRANDATA for scheduling columns has been added on table 'SIEBEL.CX_ELEGIBILIDAD'.

GGSCI (edc01dbadm03.vtr.cl as ogg_user@SBLQA4) 4>

GGSCI (edc01dbadm03.vtr.cl as ogg_user@SBLQA4) 4> ADD TRANDATA SIEBEL.CX_ITEM_ELEGI

Logging of supplemental redo data enabled for table SIEBEL.CX_ITEM_ELEGI.

TRANDATA for scheduling columns has been added on table 'SIEBEL.CX_ITEM_ELEGI'.

3.    Agregamos las tablas a los archivos de parámetros de extractor y pump (E_S_STG1 y P_S_STG1)

(agregamos la tabla al Extractor)

GGSCI (edc01dbadm03.vtr.cl as ogg_user@SBLQA4) 5> edit param E_S_STG1

(agregamos las siguientes tablas al final del archivo de parámetros y guardamos:)

TABLE SIEBEL.CX_ELEGIBILIDAD;

TABLE SIEBEL.CX_ITEM_ELEGI;

(agregamos la tabla al PUMP)

GGSCI (edc01dbadm03.vtr.cl as ogg_user@SBLQA4) 6> edit param P_S_STG1

(agregamos las siguientes tablas al final del archivo de parámetros y guardamos:)

TABLE SIEBEL.CX_ELEGIBILIDAD;

TABLE SIEBEL.CX_ITEM_ELEGI;

4.    Posterior detenemos el extractor y el pump:

GGSCI (edc01dbadm03.vtr.cl as ogg_user@SBLQA4) 11> stop P_S_STG1

Sending STOP request to EXTRACT P_S_STG1 ...

Request processed.

GGSCI (edc01dbadm03.vtr.cl as ogg_user@SBLQA4) 12> stop E_S_STG1

Sending STOP request to EXTRACT E_S_STG1 ...

Request processed.

GGSCI (edc01dbadm03.vtr.cl as ogg_user@SBLQA4) 13> info all

Program     Status Group       Lag at Chkpt Time Since Chkpt

MANAGER     RUNNING

EXTRACT     STOPPED     E_S_STG1    00:00:05      00:00:03

EXTRACT     STOPPED P_S_STG1    00:00:00 00:00:17

5.    Posteriormente levantamos el PUMP y luego el Extractor nuevamente (EN ESE ORDEN)

GGSCI (edc01dbadm03.vtr.cl as ogg_user@SBLQA4) 15> start P_S_STG1

Sending START request to MANAGER ...

EXTRACT P_S_STG1 starting

GGSCI (edc01dbadm03.vtr.cl as ogg_user@SBLQA4) 16> start E_S_STG1

Sending START request to MANAGER ...

EXTRACT E_S_STG1 starting

GGSCI (edc01dbadm03.vtr.cl as ogg_user@SBLQA4) 18> info all

Program     Status Group       Lag at Chkpt Time Since Chkpt

MANAGER     RUNNING

EXTRACT     RUNNING     E_S_STG1    00:00:04      00:00:04

EXTRACT     RUNNING P_S_STG1    00:00:00 00:00:02

6.    Procederemos ahora desde sqlplus a obtener el SCN actual de la base de datos de ORIGEN. Este valor será importante y lo usaremos para sacar un expdp de las tablas:

[oracle@edc01dbadm03 expdp_gg]$ sqlplus "/as sysdba"

SQL*Plus: Release 12.1.0.2.0 Production on Thu Jun 27 18:24:53 2019

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

Advanced Analytics and Real Application Testing options

SQL>  select to_char(dbms_flashback.get_system_change_number()) from dual;

TO_CHAR(DBMS_FLASHBACK.GET_SYSTEM_CHANGE

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

14977510302280

SQL> exit

Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

Advanced Analytics and Real Application Testing options

7.    Con el valor anterior (14977510302280) procederemos a exportar las tablas (con exp o expdp)

 [oracle@edc01dbadm03 expdp_gg]$ exp userid=ogg_user/oracle@SBLQA CONSISTENT=y flashback_scn=14977510302280 file=exp01.dmp log=exp01.log TABLES=SIEBEL.CX_ELEGIBILIDAD,SIEBEL.CX_ITEM_ELEGI

Export: Release 12.1.0.2.0 - Production on Thu Jun 27 18:25:28 2019

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

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

Advanced Analytics and Real Applicat

Export done in AL32UTF8 character set and AL16UTF16 NCHAR character set

About to export specified tables via Conventional Path ...

Current user changed to SIEBEL

. . exporting table                CX_ELEGIBILIDAD 286 rows exported

. . exporting table                  CX_ITEM_ELEGI 5930 rows exported

Export terminated successfully without warnings.

8.    Una vez terminada la exportación nos llevaremos el archivo DMP exp01.dmp al servidor de DESTINO donde tenemos nuestro replicador:

[oracle@edc01dbadm03 expdp_gg]$ scp /goldeng/expdp_gg/exp01.dmp USR_GOLDENG@miscanti.vtr.cl:/u01/app/expdp_gg

USR_GOLDENG@miscanti.vtr.cl's password:

exp01.dmp                                                                                                   100% 1264KB 1.2MB/s 00:00

[oracle@edc01dbadm03 expdp_gg]$

9.    En el servidor de DESTINO revisamos que el archivo se encuentre ok:

[oracle@miscanti oragg]$ cd /u01/app/expdp_gg

[oracle@miscanti expdp_gg]$ ls -lptr

total 6058504

-rw-r--r--. 1 USR_GOLDENG USR_GOLDENG    1294336 Jun 27 19:35 exp01.dmp

10.  En este  server de DESTINO procederemos a importar las tablas nuevas:

[oracle@miscanti expdp_gg]$ imp userid=ogg_user/oracle@STAGING1 file=exp01.dmp log=exp_imp01.log FROMUSER=SIEBEL TOUSER=SIEBEL TABLES=CX_ELEGIBILIDAD,CX_ITEM_ELEGI

Import: Release 12.2.0.1.0 - Production on Thu Jun 27 19:38:37 2019

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

Connected to: Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

Export file created by EXPORT:V12.01.00 via conventional path

import done in AL32UTF8 character set and AL16UTF16 NCHAR character set

. importing SIEBEL's objects into SIEBEL

. . importing table              "CX_ELEGIBILIDAD" 286rows imported

. . importing table                "CX_ITEM_ELEGI" 5930rows imported

Import terminated successfully with warnings.

11.  Ya terminado el import de las tablas, ingresamos a la herramienta de GGSCI sobre este ambiente de DESTINO y procederemos a agregar las nuevas tablas al archivo de parámetros del replicador. Pero en este caso usaremos la keyword FILTER en el archivo de parámetros, para indicar a partir de que SCN se pueden comenzar a aplicar los cambios para las nuevas tablas que vengan en los trails files. Este SCN es el mismo con el cual realizamos el export anterior desde el ORIGEN:

GGSCI (miscanti) 2> edit param R_S_STG1

--Agregamos lo siguiente al final del archivo de param.

--teniendo precaución con el valor que 

--estamos usando para el atributo CSN

MAP  SIEBEL.CX_ELEGIBILIDAD,   TARGET SIEBEL.CX_ELEGIBILIDAD ,FILTER ( @GETENV ('TRANSACTION', 'CSN') > 14977510302280);

MAP  SIEBEL.CX_ITEM_ELEGI,     TARGET SIEBEL.CX_ITEM_ELEGI   ,FILTER ( @GETENV ('TRANSACTION', 'CSN') > 14977510302280); 

12.  Subimos posteriormente el replicador en este ambiente de DESTINO:

GGSCI (miscanti) 4> start R_S_STG1

Sending START request to MANAGER ...

REPLICAT R_S_STG1 starting

GGSCI (miscanti) 6> info all

Program     Status Group       Lag at Chkpt Time Since Chkpt

MANAGER     RUNNING

REPLICAT    RUNNING R_B_STG1    00:00:52 00:00:01

REPLICAT    RUNNING     R_S_STG1 00:00:00      00:00:05

Eso es todo, ya con el replicador corriendo ya se pueden eliminar los comandos FILTER del archivo de parámetros del replicador.

Espero sea de utilidad, 

Saludos, Felipe.