Comencemos creando una tabla en el esquema SYS. Yo en este ejemplo la creé en el tablespace SYSAUX, pero vos podés crearla en el tablespace que mejor te parezca:

CREATE TABLE sys.audit_sesiones_cliente (
    id               NUMBER GENERATED ALWAYS AS IDENTITY,
    evento           VARCHAR2(10),   -- LOGON | LOGOFF
    fecha_evento     DATE,
    sid              NUMBER,
    serial#          NUMBER,
    inst_id          NUMBER,
    username         VARCHAR2(30),
    osuser           VARCHAR2(30),
    machine          VARCHAR2(64),
    program          VARCHAR2(128),
    client_version   VARCHAR2(20)
) TABLESPACE SYSAUX;

Y ahora creamos el trigger de logon, que contemplará todas las conexiones que se realicen en todos los nodos del RAC:

CREATE TRIGGER SYS.trg_logon_cliente
AFTER LOGON ON DATABASE
BEGIN
    INSERT INTO SYS.audit_sesiones_cliente (
        evento, fecha_evento,
        sid, serial#, inst_id,
        username, osuser, machine, program,
        client_version
    )
    SELECT 'LOGON', SYSDATE,
           s.sid, s.serial#, s.inst_id,
           s.username, s.osuser, s.machine, s.program,
           c.client_version
    FROM gv$session s
    JOIN gv$session_connect_info c
      ON s.inst_id = c.inst_id
     AND s.sid     = c.sid
   WHERE s.audsid = SYS_CONTEXT('USERENV','SESSIONID');
END;
/

Listo, ahora a esperar que pase al menos un mes, para no perdernos ninguna conexión de esos procesos batches que se ejecutan una vez por mes. Si en tu entorno tenés procesos que se ejecutan semestralmente, deberás esperar 6 meses para asegurarte de no perder nada.

¡Esto es todo!

Hasta el próximo post 😀

Saludos desde Buenos Aires, Argentina

El primer paso es instalar el driver ODBC. En mi caso utilicé un servidor nuevo con el sistema operativo Oracle Linux 8 con conexión a internet:

yum install unixODBC*

Luego debemos instalar el Oracle Database Gateway for ODBC, el mismo se descarga desde aquí: https://www.oracle.com/database/technologies/oracle19c-linux-downloads.html

Mientras se descarga el archivo, preparamos el servidor para la instalación del Gateway:

yum install oracle-database-preinstall-19c
mkdir /u01/app/oracle/instalador

Una vez descargado el instalador del gateway (LINUX.X64_193000_gateways.zip), lo copiamos al directorio /u01/app/oracle/instalador y seguimos estos pasos:

cd /u01/app/oracle/instalador
unzip LINUX.X64_193000_gateways.zip
cd gateways
export CV_ASSUME_DISTID=OL8
./runInstaller

Ahora comenzamos a configurar el Gateway:

export ORACLE_HOME=/u01/app/oracle/product/19.0.0/tghome_1
cd $ORACLE_HOME/hs/admin
vi $ORACLE_HOME/hs/admin/init<SID>.ora
#####################################################################################################
vi $ORACLE_HOME/hs/admin/initpostgresUAT.ora

# This is a sample agent init file that contains the HS parameters that are
# needed for the Database Gateway for ODBC

#
# HS init parameters
#
HS_FDS_CONNECT_INFO = postgresUAT  <========= AQUI PUEDES USAR EL VALOR QUE DESEES. ESTE SERÁ TU SID
HS_FDS_TRACE_LEVEL = DEBUG
HS_FDS_SHAREABLE_NAME = /usr/lib64/libodbc.so

#
# ODBC specific environment variables
#
set ODBCINI=/etc/odbc.ini

#
# Environment variables required for the non-Oracle system
#
#set <envvar>=<value>

Ahora agregamos el SID elegido al listener:

cd $ORACLE_HOME/network/admin
cp -p listener.ora listener.ora.bkp
vi listener.ora

SID_LIST_LISTENER=
  (SID_LIST=
      (SID_DESC=
         (SID_NAME= postgresUAT) <== ESTE VALOR DEBE COINCIDIR CON EL SID ELEGIDO EN EL PUNTO ANTERIOR
         (ORACLE_HOME=/u01/app/oracle/product/19.0.0/tghome_1)
         (ENVS="LD_LIBRARY_PATH=/usr/local/lib:/usr/lib64:/u01/app/oracle/product/19.0.0/tghome_1/lib")
         (PROGRAM=dg4odbc)
      )
  )

Reiniciamos el listener para que tome el cambio anterior:

$ORACLE_HOME/bin/lsnrctl stop
$ORACLE_HOME/bin/lsnrctl start

Luego instalamos el driver PostgreSQL:

yum install postgresql*odbc
vi /etc/odbc.ini

[postgresUAT] <============= ESTE VALOR DEBE COINCIDIR CON EL SID ELEGIDO EN LOS PUNTOS ANTERIORES
Driver = PostgreSQL
Description = PostgreSQL ODBC Driver
Database = <database_name_postgres>
Servername = <hostname_postgres>
Username = <usuario_postgres>
Password = <contraseña_usuario_postgres>
Port = <puerto_postgres>
BOOLSASCHAR=No
UseDeclareFetch = 1
CommLog = /tmp/pgodbclink.log
Debug = 1

IMPORTANTE: El valor de la variable Driver, debe coincidir con el valor que aparece entre corchetes en el archivo /etc/odbcinst.ini

Luego probamos la conectividad desde el Gateway hacia la base PostgreSQL:

isql -v postgresUAT
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+

Una vez que verificamos el correcto funcionamiento de la conexión, nos dirigimos al servidor de base de datos Oracle y allí agregamos al archivo tnsnames.ora la cadena de conexión que utilizará el dblink:

GATEWAY_POSTGRES=
   (DESCRIPTION=
      (ADDRESS=
         (PROTOCOL=TCP)
         (HOST=<hostname_gateway>)  <====== ESPECIFICAR EL NOMBRE DEL SERVIDOR DEL GATEWAY
         (PORT=1521)
      )
      (CONNECT_DATA=
         (SID= postgresUAT)) <== ESTE VALOR DEBE COINCIDIR CON EL SID ELEGIDO EN LOS PUNTOS ANTERIORES
      (HS=OK)
   )

Por último nos conectamos a la base Oracle, creamos el dblink y lo probamos:

CREATE PUBLIC DATABASE LINK TEST_POSTGRES
 CONNECT TO <usuario_postgres>
 IDENTIFIED BY <contraseña_usuario_postgres>
 USING 'GATEWAY_POSTGRES';

SELECT * FROM <tabla>@TEST_POSTGRES;

¡Esto es todo!

Hasta el próximo post 😀

Saludos desde Buenos Aires, Argentina

1. Relevar las políticas habilitadas en la base origen con la siguiente consulta:

SELECT * FROM DBA_AUDIT_POLICIES WHERE ENABLED='YES'

2. Crear las políticas en la base destino con los datos obtenidos anteriormente. Esto se deberá ejecutar por cada una de las políticas que aparezca en la consulta anterior

BEGIN
  DBMS_FGA.ADD_POLICY(
    object_schema   => 'PIA', 
    object_name     => '"FN_Matri"',
    policy_name     => 'ALU_FN_MATRI',
    audit_condition => '"alumnoId"=xxxxx',
    statement_types => 'INSERT, UPDATE, DELETE',
    handler_module  => NULL,   
    enable     => TRUE,
    audit_column    => '"alumnoId"'
  );
END;
/

¡Esto es todo!

Hasta el próximo post 😀

Saludos desde Buenos Aires, Argentina

Primero descargamos el instalador del GRID con el usuario oracle:

$ cd /u01/soft/gi_19c
$ wget --http-user=xxxx@xxxx --http-password=xxxx --no-check-certificate --output-document=V982068-01.zip "https://edelivery.oracle.com/osdc/softwareDownload?fileName=V982068-01.zip&token=ejQxL3hTRllsK1Nway9QQmJCdXk2USE6OiFmaWxlSWQ9MTA0NDg4MDA5JmZpbGVTZXRDaWQ9OTAxMzI3JnJlbGVhc2VDaWRzPTg5OTMzMiZwbGF0Zm9ybUNpZHM9MzUmZG93bmxvYWRUeXBlPTk1NzY0JmFncmVlbWVudElkPTExNjgwOTE1JmVtYWlsQWRkcmVzcz1mYWdyYW5kZUB1YWRlLmVkdS5hciZ1c2VyTmFtZT1FUEQtRkFHUkFOREVAVUFERS5FRFUuQVImaXBBZGRyZXNzPTE3MC4yMzkuMTcwLjEwOCZ1c2VyQWdlbnQ9TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzEzNC4wLjAuMCBTYWZhcmkvNTM3LjM2JmNvdW50cnlDb2RlPUFSJmRscENpZHM9MTA2MzIwOQ"

Luego descargamos el último parche RU disponible, en mi caso fue el GI RELEASE UPDATE 19.26.0.0.0

$ cd /u01/soft/gi_19c/parche
$ wget --http-user=xxxx@xxxx --http-password=xxxx --no-check-certificate --output-document=p37257886_190000_Linux-x86-64.zip "https://updates.oracle.com/Orion/Services/download/p37257886_190000_Linux-x86-64.zip?aru=26041193&patch_file=p37257886_190000_Linux-x86-64.zip"

Creamos los directorios necesarios y descomprimimos los nuevos binarios 19c. Previamente debes asegurarte que tengas espacio libre en el /u01:

mkdir -p /u01/app/19.0.0/grid 
chown oracle:oinstall /u01/app/19.0.0/grid 
su - oracle
$ cp V982068-01.zip /u01/app/19.0.0/grid/ 
$ cd /u01/app/19.0.0/grid/ 
$ unzip V982068-01.zip 
$ rm V982068-01.zip

Debido a que en Oracle Linux 8 la versión del OPENSSH es 8, la validación de la conectividad SSH fallará con el siguiente error:

Para evitar este error, debemos aplicar el último RU disponible en el nuevo $GI_HOME, previo a su configuración (ejecución del root.sh) - Fuente: Nota 2555697.1

Pero previamente debemos descargar e instalar la última versión del OPatch para version 19c (Patch 6880880).

Como estamos trabajando en un Oracle Linux 8, al ejecutar el instalador aparecerá el siguiente mensaje de error:

Para evitarlo debemos configurar la variable CV_ASSUME_DISTID con el valor OEL7

$ cd /u01/soft/gi_19c/parche
$ unzip p37257886_190000_Linux-x86-64.zip
$ export CV_ASSUME_DISTID=OEL7
$ export ORACLE_HOME=/u01/app/19.0.0/grid
$ $ORACLE_HOME/gridSetup.sh -applyRU /u01/soft/gi_19c/parche/37257886

Luego verificamos que nuestro ambiente cumpla con todos los requisitos necesarios para realizar el upgrade:

$ /u01/app/19.0.0/grid/runcluvfy.sh stage -pre crsinst -upgrade -rolling -src_crshome /u01/app/12.2.0/grid -dest_crshome /u01/app/19.0.0/grid -dest_version 19.0.0.0.0 -fixupnoexec -verbose > cluverify.log

En mi caso, el cluvfy me indicó que debía descargar y aplicar el parche 27006180 en el $GI_HOME origen (12.2)

$ cd /u01/soft/parches
$ wget --http-user=xxxx@xxxx --http-password=xxxx --no-check-certificate --output-document=p27006180_122010_Linux-x86-64.zip "https://updates.oracle.com/Orion/Services/download/p27006180_122010_Linux-x86-64.zip?aru=21761216&patch_file=p27006180_122010_Linux-x86-64.zip"
$ unzip p27006180_122010_Linux-x86-64.zip

Antes de aplicar el parche, debí descargar e instalar la última versión del OPatch para 12.2

Luego aplicamos el parche con el usuario root en modo rolling (de a un nodo por vez) para evitar pérdida de servicio total:

NODO 1

yum install -y zip
export ORACLE_HOME=/u01/app/12.2.0/grid
$ORACLE_HOME/bin/crsctl stop crs => COMIENZA PERDIDA DE SERVICIO EN EL NODO 1.
(Lo bajo porque sino me devuelve este error:
OPATCHAUTO-72030: Execution mode invalid. OPATCHAUTO-72030: Cannot execute in rolling mode, as CRS home is shared. OPATCHAUTO-72030: Execute in non-rolling mode. OPatchAuto failed.)

$ORACLE_HOME/OPatch/opatchauto apply /u01/soft/parches/27006180 -oh $ORACLE_HOME -analyze
$ORACLE_HOME/OPatch/opatchauto apply /u01/soft/parches/27006180 -oh $ORACLE_HOME
$ORACLE_HOME/bin/crsctl start crs => VUELVE A DAR SERVICIO EL NODO 1.

NODO 2

yum install -y zip
$ORACLE_HOME/bin/crsctl stop crs => COMIENZA PERDIDA DE SERVICIO EN EL NODO 2.
$ORACLE_HOME/OPatch/opatchauto apply /u01/soft/parches/27006180 -oh $ORACLE_HOME -analyze
$ORACLE_HOME/OPatch/opatchauto apply /u01/soft/parches/27006180 -oh $ORACLE_HOME
$ORACLE_HOME/bin/crsctl start crs => VUELVE A DAR SERVICIO EL NODO 2.

Volvemos a ejecutar el CLUVFY para corroborar que ya no figuren errores:

$ /u01/app/19.0.0/grid/runcluvfy.sh stage -pre crsinst -upgrade -rolling -src_crshome /u01/app/12.2.0/grid -dest_crshome /u01/app/19.0.0/grid -dest_version 19.0.0.0.0 -fixupnoexec -verbose > cluverify_2.log

Si ya no se presentan errores, avanzamos con el proceso (para no hacer tan largo este artículo con las imágenes del instalador, resumo los pasos):

$ export CV_ASSUME_DISTID=OEL7 
$ /u01/app/19.0.0/grid/gridSetup.sh -dryRunForUpgrade
    - Upgrade Oracle Grid Infrastructure
    - Next
    - Next
    - Next
    - Verificar que el Oracle Base sea el correcto y luego hacer clic en Next
    - Next
    - Asegurarse que no exista ningún punto con estado Failed. Clic en Next
    - Submit 
    - Ejecutar el /u01/app/19.0.0/grid/rootupgrade.sh como root. Esto demora varios minutos

Por precaución, reinicio los nodos del RAC (de a uno por vez) antes del upgrade para asegurarme que no exista ningún problema previo y que todo levante bien.

Ahora sí, ejecutamos el proceso del upgrade, esto provocará una pérdida de servicio total de la base de datos, con lo cual se deberá realizar en una ventana de trabajo previamente coordinada con el negocio:

$ /u01/app/19.0.0/grid/gridSetup.sh

Consultamos la version del CRS

$ /u01/app/19.0.0/grid/bin/crsctl query crs activeversion

¡Listo! Ya tenemos nuestro CRS en versión 19c 😀

Hasta el próximo post 😀

Saludos desde Buenos Aires, Argentina

SELECT * FROM DBA_FEATURE_USAGE_STATISTICS;

El resultado muestra el detalle de cada feature, cuántas veces se detectó su uso, cuando y si está siendo utilizado actualmente:

Hasta el próximo post :)

Saludos desde Buenos Aires, Argentina

SELECT ROLLUP_TIMESTAMP, MAXIMUM FROM sysman.mgmt$metric_daily
WHERE UPPER(TARGET_NAME) = '<nombre_base>' 
AND COLUMN_LABEL='Allocated Space(GB)' 
ORDER BY ROLLUP_TIMESTAMP DESC;

¡Eso es todo! muy simple.

Hasta el próximo post :)

Saludos desde Buenos Aires, Argentina.

cd $OMS_BASE/gc_inst/user_projects/domains/GCDomain/
cat servers/EMGC_ADMINSERVER/security/boot.properties
username={AES256}84+JCnGGZvrlC2TsRdBYBlum4tLn4I9Cew/tCZxJw/A=
password={AES256}GZW3hhW87Fs98+mdfrC2PkDthJ2nMCc7Nhoxtlf9Dro=

Creamos un archivo java llamado recoverpassword.java que desencriptará esa contraseña

public class recoverpassword {
 public static void main(String[] args)
 {
  System.out.println(
  new weblogic.security.internal.encryption.ClearOrEncryptedService(
  weblogic.security.internal.SerializedSystemIni.getEncryptionService(args[0]
   )).decrypt(args[1]));
  }
}

Ejecutamos el archivo de la siguiente manera

javac recoverpassword.java
java -cp $CLASSPATH:. recoverpassword $DOMAIN_HOME {AES}84+JCnGGZvrlC2TsRdBYBlum4tLn4I9Cew/tCZxJw/A=
java -cp $CLASSPATH:. recoverpassword $DOMAIN_HOME {AES}GZW3hhW87Fs98+mdfrC2PkDthJ2nMCc7Nhoxtlf9Dro=

Y listo!

Hasta el próximo post :).

Saludos desde Buenos Aires, Argentina.

-rw-rw----. 1 oracle oinstall 0 Aug 14  2017 inventory.lock

Eliminarlo y luego reintentar la operación.

Fuente: https://jasonbrownsite.wordpress.com/2016/11/30/patching-issues-oracle-cpu-oct-2016-grid-patch-oui-10022-orainventory-is-in-an-invalid-state/

Hasta el próximo post.

Saludos desde Buenos Aires, Argentina.

alter session set container=<nombre_pdb>;

show parameter MAX_STRING_SIZE
alter system set MAX_STRING_SIZE=EXTENDED scope=spfile sid='*';

alter pluggable database <nombre_pdb> close immediate instances=all;
alter pluggable database <nombre_pdb> open upgrade;

show parameter MAX_STRING_SIZE
@?/rdbms/admin/utl32k.sql

¡ATENCION! - Si la ejecución del script utl32k.sql devuelve los errores ORA-38301 y ORA-01722, se deberá purgar la papelera de reciclaje completa con el siguiente comando:

PURGE DBA_RECYCLEBIN;

Luego de la aclaración, continuamos con los siguientes pasos:

shutdown immediate
startup
alter pluggable database <nombre_pdb> close immediate instances=all;
alter pluggable database <nombre_pdb> open instances=all;
exit

En caso de que tu PDB tenga más servicios, además del que viene por omisión, los deberías levantar:

srvctl status service -d <nombre_cdb>
srvctl start service -d <nombre_cdb> -s <nombre_servicio>
srvctl status service -d <nombre_cdb>

Hasta el próximo post 🙂

Saludos desde Buenos Aires, Argentina.

Para definir la compresión a nivel tablespace, se debe ejecutar lo siguiente:

ALTER TABLESPACE <tablespace_name> DEFAULT INDEX COMPRESS ADVANCED HIGH;

Esto provocará que todos los índices que se creen a futuro tendrán la compresión del tipo ADVANCED HIGH.

Para comprimir un índice en el momento, se debe ejecutar lo siguiente:

ALTER INDEX <owner>.<index_name> REBUILD COMPRESS ADVANCED HIGH ONLINE;

Esto hará que el índice en cuestión se re-cree comprimido de manera online, es decir, no provocará un bloqueo.

Si querés comprimir todos los índices de tu base, te dejo un script que te será de utilidad:

Este script relevará todos los índices no particionados:

SELECT 'ALTER INDEX '||OWNER||'.'||INDEX_NAME||' REBUILD COMPRESS ADVANCED HIGH ONLINE;' 
FROM DBA_INDEXES 
WHERE OWNER LIKE 'USR_%'
AND PARTITIONED='NO'
AND COMPRESSION = 'DISABLED'
AND INDEX_NAME NOT LIKE 'SYS%'
AND INDEX_NAME NOT LIKE 'BIN$%'
ORDER BY OWNER;

Y este relevará todos los índices particionados:

SELECT 'ALTER INDEX '||INDEX_OWNER||'.'||INDEX_NAME||' REBUILD PARTITION '||PARTITION_NAME||' COMPRESS ADVANCED HIGH ONLINE;' 
FROM DBA_IND_PARTITIONS 
WHERE INDEX_OWNER LIKE 'USR_%'
AND COMPRESSION = 'DISABLED'
AND INDEX_NAME NOT LIKE 'SYS_%'
AND INDEX_NAME NOT LIKE 'BIN$%'
ORDER BY INDEX_OWNER;

Hasta el próximo post 🙂

Saludos desde Buenos Aires, Argentina.

SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3(
    p_bucket_name => '<nombre_bucket>',
    p_directory_name => 'DATA_PUMP_DIR') 
AS TASK_ID FROM DUAL;

4. Con el ID del punto anterior, verificar que la tarea haya terminado bien con la siguiente consulta

SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-<ID>.log'));

5. Realizar la importación de los esquemas deseados

DECLARE v_hdnl NUMBER; 

BEGIN 
v_hdnl := DBMS_DATAPUMP.OPEN( 
    operation => 'IMPORT',
    job_mode => 'SCHEMA',
    job_name => '<nombre_job>'); 
DBMS_DATAPUMP.ADD_FILE(
    handle => v_hdnl,
    filename => '<dumpfile>.dmp', 
    directory => 'DATA_PUMP_DIR',
    filetype => dbms_datapump.ku$_file_type_dump_file);
DBMS_DATAPUMP.ADD_FILE(
    handle => v_hdnl,
    filename => '<nombre_archivo_log>.log',
    directory => 'DATA_PUMP_DIR',
    filetype => dbms_datapump.ku$_file_type_log_file); 
DBMS_DATAPUMP.METADATA_FILTER(v_hdnl,'SCHEMA_EXPR','LIKE ''VT%'''); 
DBMS_DATAPUMP.START_JOB(v_hdnl); 
END;
/

6. Verificar el log del import ejecutando la siguiente consulta

SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('DATA_PUMP_DIR','<nombre_archivo_log>.log'));

Hasta el próximo post 🙂

Saludos desde Buenos Aires, Argentina.

Este componente puede ser ejecutado como daemon en uno o más nodos del VM Cluster (a mi me parece mejor tenerlo en todos los nodos) del Exadata (en la nube o cloud at customer). Lo que hace es monitorear cada cierto tiempo el uso de la cpu y si la carga de la cpu supera un umbral determinado durante un periodo de tiempo, este componente automáticamente incrementará la cantidad de cpu del VM Cluster y lo hará respetando una cantidad máxima definida por vos.

Luego si la carga de la cpu disminuye por sobre un umbral determinado durante un periodo de tiempo, este componente reducirá automáticamente la cantidad de cpu del VM Cluster y lo hará hasta una cantidad mínima definida por vos.

Incluso, si tenés un ACFS configurado, el Dynamic Scaling tendrá en consideración la carga de todos los nodos del cluster y realizará el aumento o disminución de cpu en base a la carga del cluster completo.

¿Cuáles son los requerimientos para que funcione?

• OCI-client o REST-API (Yo uso REST-API porque me parece más sencillo): Para usar la REST-API necesitas descargar desde OCI una API KEY y un API KEY FINGERPRINT. Esto te lo explico en este post: ¿Cómo obtener la API KEY de un usuario en OCI?

• Los servidores deben tener acceso a internet para poder interactuar con la API. El acceso puede ser a través de un proxy que tenga tu empresa.

¿Cómo instalar esta funcionalidad?

1. Descargar el archivo .zip correspondiente a tu sistema operativo de la nota 2719916.1

2. Transferir el archivo .zip a todos los servidores del VM Cluster en el directorio /tmp

3. Descomprimir el archivo .zip

4. Instalar el archivo rpm:

    rpm -ivh /tmp/dynamicscaling-2.0.2-5.el7.x86_64.rpm
   

5. Crear un directorio compartido bajo el ACFS:

    mkdir /acfs01/.dynamicscaling
    chown opc.opc /acfs01/.dynamicscaling
   

6. Crear el directorio oculto .oci dentro del home del usuario opc, donde estarán los archivos de configuración:

    mkdir /home/opc/.oci
   

7. Conectarse a OCI y descargar la API KEY del usuario y el archivo config. Esta tarea la explico paso a paso en este post: ¿Cómo obtener la API KEY de un usuario en OCI?

8. Copiar la API KEY al directorio /home/opc/.oci y ejecutar lo siguiente:

    chmod go-rwx <nombre_key>.pem
   

9. En el directorio /home/opc/.oci crear el archivo config con las lineas obtenidas en el punto 7 y en el parámetro key_file asignarle el directorio /home/opc/.oci

Factores de incremento - Clásico vs Incremental

Esto se refiere a la velocidad con la cual el Dynamic Scaling aumentará la cantidad de cpus de tu VM Cluster.

Con el factor clásico (es el default) uno le define un valor y todas las veces que el Dynamic Scaling aumente la cantidad de cpus, lo hará con ese valor. Por ejemplo, si el valor es 4, se sumarán 4 cpus cada vez que se necesite aumentar la cantidad.

Con el factor incremental, uno le define un valor y cuando el Dynamic Scaling deba aumentar la cantidad de cpus, la primera vez lo hará con ese valor, pero la segunda vez, lo hará con el doble de ese valor, la tercera vez, lo hará con el triple de ese valor y así sucesivamente.

Es resumen, si tu VM Cluster de repente tiene mucha carga, el Factor Incremental llegará más rápido al máximo de cpu definido por vos. Pero cuidado, porque cuanto más cpu se agregue, mayor será el costo que deba pagar tu empresa. A usarlo con responsabilidad 😉.

¿Cómo registrarla como servicio de sistema operativo para que inicie automáticamente luego de un reinicio?

Sencillo, se debe crear el archivo /etc/systemd/system/dynamicscaling.service con este contenido, adaptando los valores entre <> a tu entorno:

# Copyright (c) 2020, 2021 Oracle and/or its affiliates. All rights reserved.
#
# Oracle dynamicscaling.service
[Unit]
Description=Dynamicscaling - Scale-up and Scale-down automation utility for OCI DB System
Wants=network-online.target local-fs.target
After=network-online.target local-fs.target

[Service]
User=opc
Type=simple
Environment="HTTPS_PROXY=https://<IP>:<puerto>"
Environment="https_proxy=https://<IP>:<puerto>"
Environment="PATH=/sbin:/bin:/usr/sbin:/usr/bin:/opt/dynamicscaling"
ExecStart=/bin/sh -c "/opt/dynamicscaling/dynamicscaling.bin --vm-cluster-id <ocid_vm_cluster> --ociregion <nombre_region> --tenancy-id <ocid_tenant> --user-id <ocid_usuario> --keyfingerprint <key_fingerprint> --privatekey /home/opc/.oci/<nombre_key>.pem --proxyhost <ip> --proxyport <puerto> --maxocpu 10 --minocpu 2 --ocpu 2 --acfs /acfs01/.dynamicscaling --mailx <dirección_mail> --subject <palabra de referencia> --sopnum 3"

TimeoutStartSec=300
PIDFile=/tmp/.dynamicscaling.pid
Restart=on-failure
RestartSec=5s
ExecStop=/bin/kill -s SIGINT $MAINPID

[Install]
WantedBy=multi-user.target

Luego ejecutar como root estos comandos:

systemctl daemon-reload
systemctl enable dynamicscaling.service
systemctl start dynamicscaling.service
systemctl status dynamicscaling.service

¡¡¡Y listo!!!!

Hasta el próximo post 🙂

Saludos desde Buenos Aires, Argentina.

Hasta el próximo post 🙂

Saludos desde Buenos Aires, Argentina.

Vayamos a la práctica:

Supongamos que sabemos que se han borrado filas hace menos de una hora, entonces hacemos lo siguiente:

SELECT * FROM owner.tabla_ejemplo AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL '60' MINUTE;

Dicha consulta nos traerá todas las filas que tenía la tabla_ejemplo hace una hora.

También podríamos crear una tabla_soporte que contenga todos los registros de la tabla_ejemplo hace una hora de la siguiente manera:

CREATE TABLE owner.tabla_soporte AS
       SELECT * FROM owner.tabla_ejemplo AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL '60' MINUTE;

Una desventaja de este último ejemplo es que no se crearán ni los índices ni las constraints de la tabla original.

Hasta el próximo post 🙂

Saludos desde Buenos Aires, Argentina.

Vamos por parte, si se eliminó una tabla se puede recuperar con este comando:

FLASHBACK TABLE <nombre_tabla> TO BEFORE DROP;

Si luego de haberse eliminado una tabla, alguien ya creó otra tabla con el mismo nombre, podés recuperar la tabla original con un nombre distinto con este comando:

FLASHBACK TABLE <recyclebin_name> TO BEFORE DROP RENAME TO <nombre_nuevo>;

Y para obtener el recyclebin_name puedes consultar la vista DBA_RECYCLEBIN.

Hasta el próximo post 🙂

Saludos desde Buenos Aires, Argentina.

Si sos DBA, imaginate que una persona hizo un DELETE sin un filtro por equivocación, si esa persona te avisa rápido, vos serías capaz de recuperar los datos de una manera sencilla y rápida.

Para funcionar, esta característica sólo utiliza el tablespace de UNDO.

Vayamos a la práctica

Supongamos que sabemos que se han borrado filas hace menos de una hora, entonces hacemos lo siguiente:

SELECT * FROM owner.tabla_ejemplo AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL '60' MINUTE;

Dicha consulta nos traerá todas las filas que tenía la tabla_ejemplo hace una hora.

También podríamos crear una tabla_soporte que contenga todos los registros de la tabla_ejemplo hace una hora de la siguiente manera:

CREATE TABLE owner.tabla_soporte AS
       SELECT * FROM owner.tabla_ejemplo AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL '60' MINUTE;

Una desventaja de este último ejemplo es que no se crearán ni los índices, ni las constraints de la tabla original.

Hasta el próximo post 🙂

Saludos desde Buenos Aires, Argentina.