Viaje a China ...




Hola...estuve mucho tiempo fuera de las canchas y no escribía nada en este blog, pero solamente era por temas de trabajo .

La independencia lleva consigo el que uno se sumerja en un mundo de trabajo, trabajo y más trabajo , que tiene claramente sus recompensas y también sus problemas.

Pero bueno, hemos hecho algo de tiempo para volver a escribir ,como lo hacía en antaño.

Lo que les voy a contar es para mí una maravilla, el 26 de Julio de este año me voy de viaje a China, en una mezcla de tema laboral (diversificando mi matriz de ingreso) y de paso, conocer Shanghai y en Beijing , tratando hacer de todo en China (bueno, casi todo :>>)

Con un agotador viaje de 36 horas, con vuelo Santiago-Houston , Houston-San Francisco , San Francisco - Shanghai (Pudong)

Así que a la vuelta les cuento que fue de mi vida allí :>>

Un abrazo desde Santiago de Chile
by Ligarius
17.07.17. 12:51:03. 157 words, 231 views. Categories: Cosas varias ,

Error al instalar Oracle Discoverer 11.1.0.7 : REP-50600:Broadcasting is disable. Please enable cosnaming for Reports Discovery



Instalando un Oracle Discoverer 11.1.0.7 aparece un error, que la verdad al mirarlo es muy extraño pero bastante fácil de solucionar

El primer error que aparece es la configuración de Fusion Middleware, en donde se ve que al momento de levantar el componente de Report Server mediante opmnctl, el instalador no es capaz de arrancarlo de buena forma



Se chequean los archivos de logs de la instalación y podemos apreciar lo mismo, problemas con el Reports Server





Se chequea la ruta el archivo de log relacionado al Reports Server




Y acá podemos encontrar el error que nos dará la gloria


Un maravilloso y explícito REP-50600:Broadcasting is disable. Please enable cosnaming for Reports Discovery


Pueden existir múltiples causas para este error , pero siempre relacionado a redes :
  • Problemas o mala definición con el Default Gateway
  • Reglas de Firewall
  • Que la IP no pueda ejecutar nslookup (mala definición)
  • Que el servidor posea DHCP
  • Puertos bloqueados
  • Todas las anteriores :)

    Pues bien, uno de los casos más frecuentes, es simplemente bloqueo de puertos por el Firewall de sistema operativo y acá la explicación y solución

    El comando iptables es una herramienta para setear y mantener tablas de IP y sus respectivos filtros , por ello al momento de ejecutar el comando iptables -L -n, muestra aquellos segmentos de red rechazados


    Para poder vaciar esta lista de rechazados, se puede hacer un FLUSHde las iptables , tal como se aprecia en la imagen


    Posterior a esto simplemente el proceso se puede retomar o comenzar desde cero y será capaz el Reports Server de levantar sin inconvenientes.

    Referencias
    New Install of iAS/iDS and Reports Server Fails with REP-50600: Broadcasting Is Disabled. (Doc ID 443448.1)


  • by Ligarius
    13.07.17. 15:20:44. 286 words, 397 views. Categories: Fusion Middleware, Oracle Discoverer ,

    El quinto número de los PSU , es ahora una fecha



    Hola... hace un tiempo atrás (6 años) comentamos lo del quinto número en una versión Oracle, el quinto número que indica el PSU que se está instalando .

    Nota asociada
    http://www.oracleyyo.com/index.php/2009/07/08/iiun-nuevo-numero-a-nuestra-version-de-o

    Pues bien, hace unos meses atrás ya no es un número correlativo (otro cambio más)



    Desde Noviembre del año pasado todos los PSU (quinto número de la versión Oracle) vienen con un formato de fecha , un ejemplo

    El parche de base de datos 11.2.0.4.9 ahora será el parche 11.2.0.4.160119

    Incluso el último PSU para un motor Oracle 12c (12.1.0.2) es la versión 12.1.0.2.160419 (19 de Abril del 2016)

    El formato del parche es el siguiente :

    YY : Año del parche
    MM : Mes del parche
    DD : Día del parche

    Los PSU seguirán saliendo al mercado de forma trimestral y para las bases de datos, para Exadata, para Midleware, es válido el mismo formato para los PSU.

    by Ligarius
    09.07.16. 17:07:42. 159 words, 21425 views. Categories: Base de datos, Parchado Oracle ,

    Oracle Golden Gate 12c : Llevando a cabo una carga inicial (INITIAL LOAD con DIRECT LOAD)



    Oracle Golden Gate es un extraordinario utilitario que tiene Oracle para llevar a cabo replicación de datos, tiene una increíble cantidad de comandos, es muy flexible y muy dúctil a la hora de trasladar datos desde una fuente a otra.



    La carga inicial de datos (INITIAL LOAD) es la etapa en donde cargamos toda la información de nuestro origen en el destino por una sola y única vez, para posteriormente comenzar a aplicar sólo los cambios al destino mediante la sincronización de EXTRACTORES con REPLICADORES.

    Oracle Golden Gate nos proporcionar una serie de mecanismos para llevar a cabo la carga inicial de estos datos (IUNITIAL LOAD), todas poseen pros y contras
    • Carga inicial de datos desde archivos al replicador (Loading Data from File to Replicat)
    • En esta forma de carga inicial el extractor genera archivos que el replicador puede aplicar en la base de datos de destino, este método es lento y sólo debiese ser ocupado para poca cantidad de registros , además posee limitaciones en los tipos de datos que puede trasladar.
    • Carga inicial de de datos mediante la generación de archivos de TRAIL(Loading Data from Trail to Replicat)
    • El extractor generará archivos de TRAIL los cuales serán leídos por el replicador para cargar la información en la base de datos de destino, mucho más rápido que el anterior caso de INITIAL LOAD
    • Carga de datos desde un archivo a utilitarios de base de datos (Loading Data from File to Database Utility)
    • Este método hace que los EXTRACTORES generen archivos planos en formato ASCII los cuales pueden ser procesados por utilitarios que cargarán la información a nivel de base de datos , por ejemplo un SQLLOADER o cualquier otro utilitario que cargue información a una base de datos (ejem: SQL Server)
    • Carga inicial de datos con carga directa entre extractores y replicadores (Loading Data with an Oracle GoldenGate Direct Load)
    • La carga inicial de datos mediante DIRECT LOAD implica que el extractor le enviará de forma directa los datos a un REPLICADOR el cual hará la carga de forma automática a la tabla que se haya indicado en la claúsula MAP del replicador sin necesidad de generar archivos de TRAIL, no está soportada la copia de tablas que posean LOBs, LONGs o datos estructurados de usuario y no carga los datos que se hayan modificado o insertado en el origen desde que se comenzó con la extracción de datos.
    • Carga inicial de datos mediante BULK LOAD con SQL Loader(Loading Data with a Direct Bulk Load to SQL*Loader)
    • Este forma especial de INITIAL LOAD solamente trabaja con Oracle SQL Loader en el destino, el EXTRACTOR saca los registros desde las tablas de origen y se las envía al REPLICADOR el cual mediante las interfaces de SQLLOADER (procedimientos almacenados) carga la información en las tablas de destino, esta carga de datos no funciona si en el origen existen datos LOBs o LONGs


    Oracle Golden Gate INITIAL LOAD con DIRECT LOAD :
    Haremos un ejercicio para realizar la INITIAL LOAD mediante la opción de DIRECT LOAD, para poder apreciar de una manera gráfica como sucede esto, les invito a ver la siguiente imagen :>>

    1) Creamos nuestra tabla en el orígen con datos que trasladaremos con DIRECT LOAD de Golden Gate

    create table tabla_inicio as 
    select *
    from (
    select rownum fila
                   from
                           (select rownum r from dual connect by rownum <= 1000) a,
                           (select rownum r from dual connect by rownum <= 1000) b,
                           (select rownum r from dual connect by rownum <= 1000) c
                   where rownum <= 100000000
    )

    Con el anterior comando , tenemos de inmediato 100 millones de filas


    2) Creamos nuestro extractor en el origen , a nivel de comando en la interfaz de Golden Gate (ggsci) ejecutamos lo siguiente

    add extract EXTINI, SOURCEISTABLE

    Donde :

    SOURCEISTABLE : Se le indica que el origen de los datos es una tabla Oracle y de allí extraerá todas las filas y columnas que las tablas posean


    3) Le proporcionamos el código a nuestro nuevo extractor , en el archivo ./dirprm/extini.prm colocamos lo siguiente

    EXTRACT EXTINI
    USERID ggorigen, PASSWORD ggorigen123
    RMTHOST 198.162.157.200, MGRPORT 7809
    RMTTASK replicat, GROUP repini
    TABLE GGORIGEN.*
    KEYCOLS (FILA);

    Donde :

    EXTRACT {nombre extractor}: Indica el nombre del extractor Golden Gate
    USERID {usuario}, PASSWORD {password} : Son las credenciales de conectividad para nuestra base de datos origen
    RMTHOST {Ip máquina}, MGRPORT {Puerto} : Se le proporciona la IP de la máquina donde estará el manager remoto al igual que el puerto donde esté último escuchará
    RMTTASK replicat, GROUP {nombre de replicador} : Acá se le indica al extractor como se llama el replicador en la máquina de destino
    TABLE {usuario}.{nombre tabla} : Este es el origen de datos, con el usuario dueño y la tabla o tablas a replicar, si usamos un * , le indicamos que tome todas las tablas que pertenecen a un usuario en partícular.
    KEYCOLS ({nombre columna}) : En el campo KEYCOLS se indica cual es la Primary Key que no posee la tabla, si esta tabla no posee PK igual, se debe indicar mediante esta claúsula que campo sirve para que Golden Gata identifique de forma única una fila.


    4) Creamos nuestro replicador en el destino , a nivel de comando en la interfaz de Golden Gate (ggsci) ejecutamos lo siguiente

    add replicat REPINI, SPECIALRUN

    Donde :

    SPECIALRUN : Con esto se le indica a Golden Gate que este replicador sólo se ejecutará una vez, que no habrá checkpoint y que sólo finalizará cuando haya trasladado todos los datos (no se lleva los cambios que se hayan producido posterior al START del extractor).


    5) Le proporcionamos el código a nuestro nuevo replicador, en el archivo ./dirprm/repini.prm colocamos lo siguiente

    REPLICAT REPINI
    USERID ggdestino, PASSWORD ggdestino123
    ASSUMETARGETDEFS
    MAP GGORIGEN.*, TARGET GGDESTINO.*;

    Donde :

    REPLICAT {nombre replicador}: Indica el nombre del replicador Golden Gate
    USERID {usuario}, PASSWORD {password} : Son las credenciales de conectividad para nuestra base de datos destino
    ASSUMETARGETDEFS : Se usa esta claúsula cuando el orígen de datos y el destino donde quedarán tienen la misma estructura .
    MAP {usuario}.{nombre tabla}, TARGET {usuario}.{nombre tabla} : Este es el mapeo de datos, con el usuario dueño y la tabla o tablas a replicar, si usamos un * , le indicamos que tome todas las tablas que pertenecen a un usuario en partícular, MAP indica como viene desde el origen y TARGET es indicativo de donde se cargarán los datos en el destino.


    6) Las tablas en el destino deben existir como estructuras de datos, o sea, deben ser creadas antes de comenzar con la replicación


    7) Chequeamos nuestro extractor y replicador

    GGSCI (oraserver1.localdomain) 3>  info extract EXTINI
    
    EXTRACT    EXTINI    Initialized   2016-06-26 14:05   Status STOPPED
    Checkpoint Lag       Not Available
    Log Read Checkpoint  Not Available
                         First Record         Record 0
    Task                 SOURCEISTABLE
    GGSCI (oraserver2.localdomain) 5> info replicat REPINI
    
    REPLICAT   REPINI    Initialized   2016-06-26 14:05   Status STOPPED
    Checkpoint Lag       00:00:00 (updated 00:00:02 ago)
    Log Read Checkpoint  Not Available
    Task                 SPECIALRUN


    8) Y ejecutamos nuestro extractor, el cual se comunicará directamente con el replicador y este a su vez insertará los registros de manera automática en la tabla que se le indico en la claúsula MAP

    GGSCI (oraserver1.localdomain) 4> start extract EXTINI
    
    Sending START request to MANAGER ...
    EXTRACT EXTINI starting


    9) Se chequea el estado del extractor y del replicador nuevamente y vemos como avanza el contador de registros leídos

    Extractor

    Replicador


    10) Y nuestra tabla en el destino comienza a cargarse con datos

    SQL> select count(*) from ggdestino.tabla_inicio;
    
      COUNT(*)
    ----------
       6478000
    
    SQL>


    Recordar que los cambios que se hagan a la tabla origen mientras se está generando la replicación no serán traspasados al destino con el INITIAL LOAD, esto se hará solamente en una replicación normal de Oracle Golden Gate


    Metalink :
    Master Note - Oracle GoldenGate: Initial Load Techniques and References (Doc ID 1311707.1)
    Goldengate : Direct Load - Initial Load Techniques (Doc ID 1457164.1)

    Espero les sirva para entender lo poderoso de Oracle Golden Gate

    by Ligarius
    25.06.16. 23:02:05. 666 words, 2057 views. Categories: Oracle Golden Gate, Golden Gate 12c ,

    Próximas certificaciones - Segundo semestre 2016



    El calendario de certificaciones se viene bastante interesante, tengo unas fechas propuestas, pero no sé si alcance a cumplirlas todas, pues me demandarán mucho tiempo.



    Además, en Agosto tengo un viaje maravilloso e impresionante, nada más ni nada menos que a Japón :>>



    Así que será un segundo semestre muy movido ;)

    by Ligarius
    16.06.16. 14:33:13. 54 words, 1599 views. Categories: Base de datos, Certificaciones ,

    1 2 3 4 5 6 7 8 9 10 11 ... 44 >>