Copias de seguridad gestionadas por el usuario en Oracle

 

Empezaremos esta entrada en el blog, con la ortodoxia de una definición canónica de copia de seguridad (backup).

Definición: La copia de seguridad es una copia real y coherente de los datos de la base de datos que podría usarse para reconstruir los datos después de un incidente.

Hay dos tipos de respaldo

• Copia de seguridad física
• Copia de seguridad lógica

Copia de seguridad física (Physical Backup)

Copia de todos los archivos de datos físicos necesarios para realizar la restauración y recuperación de la base de datos,

Este tipo de copia de seguridad incluye una copia de los archivos siguientes

• Archivos de información
• Controlar archivos
• Archivos de parámetros
• Archivos de registro archivados

Las diferentes opciones para realizar copias de seguridad físicas son

• Técnicas gestionadas por el usuario
• RMAN (Recovery Manager)

Copia de seguridad lógica (Logical Backup)

Oracle utiliza la bomba de datos de Oracle para permitirnos generar una copia de seguridad lógica que se puede utilizar para migrar datos, incluso hacer una recuperación parcial o total de la base de datos.

• exp / expdp
• imp / impdp

Diferencia entre restauración y recuperación

Restaurar: acto que implica la restauración de todos los archivos que serán necesarios para recuperar su base de datos a un estado consistente. por ejemplo, copiando todos los archivos de respaldo desde una ubicación de respaldo como TAPE o DISK

Recuperar: es un proceso para aplicar todos los registradores de transacciones en el registro de archivo, avanzando su base de datos hasta un punto en el tiempo.

Copias de seguridad gestionadas por el usuario

Backpup en Frio

Esta es la única forma posible para que el DBA realice una copia de seguridad coherente de la base de datos independientemente del modo de la base de datos (archivelog o noarchivelog). A continuación se explican los pasos:

• Si la base de datos se está ejecutando, bájela completamente en un modo consistente (usando el apagado (solo NORMAL / INMEDIATO / TRANSACCIONAL). Esto asegurará que el encabezado de todos los archivos de la base de datos se actualice al mismo SCN
• Copia de seguridad de todos los archivos de datos, archivos de control, archivos de parámetros mediante el comando de copia del sistema operativo
• Iniciar la base de datos
• Archive todos los registros de rehacer no archivados utilizando el siguiente comando y cópielos en la ubicación de la copia de seguridad.

alter tablespace SIGE_TBS offline normal;

Copia de seguridad de datos sin conexión (Offline)

Suponga que desea realizar una copia de seguridad sin conexión de uno o más espacios de tabla, el método de copia de seguridad sin conexión le ayudará a lograr lo mismo, tenga en cuenta que el espacio de tabla SYSTEM y el espacio de tabla UNDO con deshacer activo no se pueden desconectar.

suponga que el espacio de tabla es SIGE_TBS:

• Identifique todos los archivos de datos asociados con el espacio de tabla mediante la vista dba_data_files

select tablespace_name,file_name from dba-data_files from dba_data_files where tablespace_name='SIGE_TBS';

• Ponga el espacio de tabla fuera de línea usando la prioridad normal (no use temporal e inmediato, requerirá recuperación en el momento de poner el espacio de tabla en línea)

alter tablespace SIGE_TBS offline normal;

• Haga una copia de seguridad de todos los archivos de datos relacionados con el espacio de tabla mediante el comando de copia del sistema operativo.

• Ponga el tablespace en línea.

alter tablespace SIGE_TBS online;

Archive todos los registros de rehacer no archivados y copie el registro archivado en la ubicación de la copia de seguridad.

alter system archive log current;

Backups en caliente

Esto se ha introducido en la versión 6 de Oracle, pero inicialmente estaba vinculado solo al espacio de tabla, a partir de la versión 10 también incluían toda la base de datos. Esto nos permite realizar copias de seguridad en caliente de la base de datos o el espacio de tabla sin necesidad de cerrar la base de datos.

Al realizar una copia de seguridad en caliente, Oracle deja de registrar puntos de control en todos los archivos de datos asociados.

A continuación se muestran dos cosas que suceden internamente mientras la base de datos se pone en modo BEGIN BACKUP:

• Se establece una bandera de respaldo activo en el encabezado del archivo de datos
• Se produce un punto de control, parpadeo de todos los bloques sucios de la memoria al disco, sincronizando todos los encabezados de los archivos de datos al mismo SCN y congelando los encabezados para lograr coherencia, protección y capacidad de recuperación.

Se pueden realizar copias de seguridad en caliente en toda la base de datos, el espacio de tabla o incluso a nivel de contenedor, esto requiere un proceso de recuperación después de que se restaure la copia de seguridad, por lo que siempre realice una copia de seguridad de todos los archivos de registro archivados necesarios.

Copia de seguridad en caliente de toda la base de datos

Para realizar este tipo de copia de seguridad, debemos poner nuestra base de datos en modo de copia de seguridad usando 'alter database begin backup;'

Este es el tipo más común de copia de seguridad administrada por el usuario que utiliza DBA en todo el mundo.

A continuación se muestran los pasos:

• Coloque la base de datos en modo de respaldo.

alter database begin backup;

• Haga una copia de seguridad de todos los archivos de datos y archivos de parámetros utilizando el comando de copia del sistema operativo-

• Saque la base de datos del modo de respaldo.

alter database end backup;

• Archivar todos los registros no archivados y copiarlos como respaldo.

• Crear copia del archivo de control como seguimiento.

alter system archivelog current;

• modifique el archivo de control de copia de seguridad de la base de datos a '/control_file.trc;

alter system archive log current;

Copia de seguridad en caliente de la base de datos de contenedores

Como se introdujo en Oracle 12c, puede realizar una copia de seguridad administrada por el usuario de toda la base de datos del contenedor o del único PDB raíz o individual.

Base de datos de contenedores completa:

A continuación se muestran los pasos mencionados:

• Inicie sesión en la base de datos utilizando un usuario que tenga privilegios de sysdba o sysbackup.

sqlplus /nolog

connect system@container1

• Coloque su base de datos en modo de respaldo.ç

alter database begin backup;

• Modificar la base de datos comenzar la copia de seguridad;

select file_name from dba_data_files;

• Identifique todas las bases de datos relacionadas con la base de datos del contenedor usando el siguiente comando.

select file_name from dba_data_files;

• Copie toda la base de datos usando el comando de copia del sistema operativo.

• Saque la base de datos del modo de respaldo.

alter database end backup;

• Archivar todos los registros no archivados y copiarlos como respaldo.

alter system archivelog current;

• Crear copia del archivo de control como seguimiento.

alter database backup controlfile to '/control_file.trc;

ROOT solo o PDB individual

A continuación se muestran los sencillos pasos para completar la copia de seguridad en caliente de root contenedor o base de datos conectable individual.

• Conectar a la raíz o base de datos conectable individuo con usuario tenga privilegios SYSDBA o sysbackup.

sqlplus /nolog

connect system

alter session set container= tech_pdb;

• Identifique todos los archivos de datos que forman parte de PDB usando la vista dba_data_files.

select file_name from dba_data_files;

• Coloque la base de datos conectable en modo de respaldo.

alter pluggable database tech_pdb begin backup;

• Copie todos los archivos de datos usando el comando de copia del SO.
• Saque la PDB del modo de inicio de copia de seguridad.

alter pluggable database tech_pbd end backup;

• Archivar todos los registros no archivados y copiarlos como respaldo

alter system archivelog current;

• Crear una copia del archivo de control como seguimiento

alter database backup controlfile to '/control_file.trc;

Controlar la copia de seguridad de archivos

Hay dos formas de recuperar el control

• Copia de seguridad binaria
• Copia de seguridad de archivos de texto

Tener una copia de seguridad válida del archivo de control de una base de datos es crucial para la recuperación exitosa de la base de datos.

Copia de seguridad binaria

Se puede realizar una copia binaria del archivo de control mediante una declaración SQL. Esta copia contiene información adicional, como el historial de registro de rehacer archivado, rango fuera de línea para espacios de tabla de solo lectura y fuera de línea, entradas de archivos temporales y conjuntos de respaldo de RMAN y copias de datos.

comando para tomar una copia de seguridad binaria.

alter database backup controlfile to '';

Copia de seguridad de archivos de texto

Este tipo de copia de seguridad contiene una instrucción create controlfile basada en el archivo de control actual en uso. Este tipo de copia de seguridad se puede realizar mientras la base de datos está en modo de montaje o abierto. Esto se genera como archivo de seguimiento y se puede modificar fácilmente.

A continuación se muestran algunas declaraciones utilizadas para crear una copia de seguridad basada en texto del archivo de control.

1. alter database backup controlfile to trace;

2. alter database backup controlfile to trace resetlogs;

3. alter database backup controlfile to trace noresetlogs;

4. alter database backup controlfile to trace as '';

5. alter database backup controlfile to trace as '' reuse;

6. alter database backup controlfile to trace as '' resetlogs;

7. alter database backup controlfile to trace as '' noresetlogs;

¿Hay vida más allá de Oracle? Psi-probe para Apache Tomcat

 

Psi-probe es un monitor de Apache Tomcat que nació como un fork de Lambda Probe, debido a la falta de soporte sobre el mismo y las dudas en cuanto a su futuro.

Psi-probe es un proyecto con licencia GPLv2 que, según describen en su propia documentación, permite monitorizar en remoto el estado del servidor en los siguientes aspectos:

• peticiones: dispone de un monitor de tráfico en tiempo real,
• sesiones: analizar atributos en sesión, estimar el peso de las mismas,
• jsp: navegar, ver el código fuente, recompilar!.
• fuentes de datos: analizar el uso del pool de conexiones, ejecutar queries.
• logs: ver el contenido, descargar, cambiar el nivel de trazabilidad en caliente.
• hilos: ver la pila de ejecución, «matarlos».
• conectores: ver el estado, usando gráficas.
• cluster: ver el estado, usando gráficas.
• JVM: ver el uso de memoria, lanzar el GC, reiniciar la JVM.
• Sistema: uso de CPU, memoria,…

Está documentada su instalación tanto en Apache Tomcat como en Jboss Application Server, con el objetivo de reemplazar el tomcat manager ofreciendo mucha más funcionalidad, para el primero, o simplemente de disponer de un monitor online de la salud de tu servidor, para el segundo.

• Hardware: Portátil Compaq  (2.4 GHz Intel Core i7, 4GB DDR3).
• Sistema Operativo: Windows 10 64 bits
• Apache Tomcat 9.0.13.
• Apache Maven: 3.6.3.
• psi-probe 3.5.2.

Instalación en Apache Tomcat.

Tras descargar el paquete de instalación lo único que tenemos que hacer es «tirar el war» probe.war en el directorio de despliegue de Apache Tomcat y, en función de si tenemos configurado el despliegue automático o no, configurar la aplicación web como tal, por defecto, no habría que hacer nada más que revisar la política de autenticación y autorización de tomcat definida en el fichero tomcat-users.xml del directorio conf.

Se pueden definir 4 niveles de autorización, asumiendo que manager es la más alta, con lo que si ya tenías definido un usuario con ese rol para el Tomcat Manager, no necesitas tocar nada.

Por último, si quieres acceder a toda la información de la JVM desde probe debes habilitar el acceso en remoto a la consola de JVM.

 Monitorización.

Una vez levantado el servidor y a través de la url que da acceso al contexto de la aplicación http://localhost:8080/probe podremos acceder con el usuario y contraseña configurados en Tomcat a la aplicación de monitorización.

La primera interfaz que se muestra es la de las aplicaciones instaladas en la que se puede comprobar que aparece el propio probe.

Pulsando sobre una aplicación podemos acceder a un breve detalle de toda la información que se recolecta sobre la misma:

En este caso he arrancado la demo de MyFaces Tobago. Tobago es un "framework"y una "libreria" de componentes JavaServer Faces (JSF). Que proporciona una forma cómoda de diseñar pantallas de aplicaciones similares a las de un escritorio con una apariencia y sensación coherentes. Tobago enfatiza la separación de estructura y diseño de pantallas. Próximamente haré una introducción a este "framework"

Pulsando sobre la sección correspondiente podemos analizar información sobre las sesiones activas:

se pueden eliminar las sesiones, estimar el tamaño que ocupan y pulsando sobre la misma podemos ver todos los objetos que se mantienen en la sesión del usuario en el servidor; pudiendo incluso realizar un segundo nicel de estimación del tamaño que ocupan dichos objetos en la memoria del servidor.

Existen más opciones en el menú izquierdo, entre ellas la de visualizar el contenido del descriptor de despliegue:

los servlets configurados y los parámetros de inicialización y de contexto de los servlets.

En la opción de logs podemos acceder a un listado de los ficheros que trazamos. 

y pulsando sobre uno de ellos, se puede visualizar el log, como si hiciéramos un "tail", sobre él mismo. del fichero:

Información sobre el sistema, sobre fuentes JDBC (en este ejemplo, no figuran)

Descripción del sistema

Conectores

En la pestaña de conectores podemos acceder a la monitorización de las peticiones que se realizar a través de los distintos conectores, disponiendo de información gráfica sobre número de peticiones, tiempo de proceso y volumen del tráfico de estas conexiones.

La última de las opciones es un chequeo rápido de la salud del servidor teniendo en cuenta el uso de las fuentes de datos, la memoria, el número de descriptores de fichero disponibles y si las aplicaciones están levantadas o no.

Está en vuestras manos ponerlo en producción. Si no, en cualquier entorno, incluso en el de desarrollo te puede servir como soporte de una monitorización del sistema durante pruebas de carga o estrés.

Oracle 10g: Diferencia entre usar srvctl y usar sqlplus para iniciar / detener una o más instancias de base de datos Oracle

 

El desafío

Hemos tenido algunos casos en los que parecía que iniciar bases de datos RAC 10g a través de sqlplus causaba problemas de rendimiento (alta carga en el servidor de la base de datos). Reiniciar los nodos usando srvctl pareció resolver el problema de rendimiento. Nos surgió una pregunta pregunta es

 "¿Hay alguna diferencia entre usar srvctl y usar sqlplus para iniciar o detener uno o más nodos de base de datos"?

La realidad

Existen algunas diferencias entre el uso de las utilidades SQLPLUS y SRVCTL.

• La parte común es que SRVCTL utiliza SQLPLUS para iniciar / detener las instancias.

• La herramienta SRVCTL gestiona la información de configuración que utilizan otras herramientas de Oracle. Por ejemplo, Enterprise Manager usa la información de configuración que SRVCTL genera para descubrir y monitorear nodos en su clúster.

• Tener en cuenta que el comando "srvctl start database / instance" no iniciará todos los servicios habilitados y no en ejecución que tengan las instancias enumeradas como instancias preferidas o disponibles en 10g.

• Ambos deberían resultar en el inicio de la instancia, pero Oracle siempre recomienda el uso de SRVCTL debido al hecho de que SRVCTL hace más, es decir, SRVCTL realizará un análisis de dependencia e informará sobre problemas relacionados con el clúster si existen, de una mejor manera que SQLPLUS, que puede decir simplemente que la instancia no se está iniciando. El comando SRVCTL intentará iniciar recursos dependientes (como vip / ons / listeners) en caso de que no se estén ejecutando.

• La utilidad SRVCTL siempre realiza algún tipo de pre-inicio de las instancias, como actualizar la información de OCR (Oracle cluster registry) en lugar de esperar a que el script de verificación del recurso de instancia detecte el inicio de esta instancia y actualice el OCR.

• Con SRVCTL, la configuración del sistema operativo del usuario raíz se utiliza ya que se hereda de crsd.bin que iniciará las instancias como usuario de Oracle. Con SQLPLUS, se utiliza la configuración del sistema operativo del usuario de Oracle. Tener diferentes configuraciones de usuario para root u oracle hará que el rendimiento pueda ser diferente (sga fragmentado o no, otra configuración de proyecto "solaris", ...)