Mostrando entradas con la etiqueta DBA. Mostrar todas las entradas
Mostrando entradas con la etiqueta DBA. Mostrar todas las entradas

09 marzo 2021

Oracle DBA: Realización de operaciones diarias

 

Desde mi punto de vista, para desempeñar correctamente el papel de administrador de bases de datos, se deberá desarrollar e implementar acciones que cubran todas las áreas de esta disciplina. Nuestras Sus tareas diarias variarán desde hacer arquitectura y diseño de alto nivel hasta realizar tareas de bajo nivel. 

Arquitectura y Diseño

Los administradores de bases de datos deben participar en la arquitectura y el diseño de nuevas aplicaciones, bases de datos e incluso cambios de infraestructura técnica. Las decisiones que se tomen aquí tendrán un gran impacto en el rendimiento y la escalabilidad de la base de datos, mientras que el conocimiento de la base de datos lo ayudará a elegir una mejor implementación técnica. Las herramientas de modelado de datos como SQL Developer Data Modeler pueden ayudar al DBA.

Planificación de capacidad

Es necesario realizar una planificación a corto y largo plazo en sus bases de datos y aplicaciones. Debe concentrarse en las características de rendimiento y tamaño de sus sistemas que ayudarán a determinar las próximas necesidades de almacenamiento, CPU, memoria y red. Esta es un área que a menudo se descuida y puede generar grandes problemas si no se realiza correctamente. Hay un cambio en los entornos de planificación para poder agregar recursos fácilmente a medida que los sistemas crecen, ya sea con entornos de virtualización o en la nube. Con los entornos de base de datos virtualizados, estas preocupaciones sobre los recursos y la planificación de la capacidad pueden ser menores en el lado del DBA, pero aquellos que ahora están planificando la capacidad del entorno virtualizado estarán preocupados por el uso general. Estos entornos tienden a escalar mejor porque hay formas de agregar recursos según sea necesario. Aún así, poder comunicar el crecimiento de la base de datos y cómo se utilizarán los diferentes recursos ayudará a administrar el entorno general.

Copia de seguridad y recuperación

Un plan de respaldo y recuperación es, por supuesto, fundamental para proteger sus datos corporativos. Debe asegurarse de que los datos se puedan recuperar rápidamente en el momento más cercano posible. También hay un aspecto de rendimiento en esto porque las copias de seguridad deben realizarse utilizando recursos mínimos mientras la base de datos está en funcionamiento, y las recuperaciones deben realizarse dentro de un límite de tiempo predefinido por los Acuerdos de nivel de servicio (SLA) desarrollados para cumplir con los requisitos de los clientes. Una implementación completa de respaldo y recuperación debe incluir recuperación local y recuperación remota, lo que también se conoce como planificación de recuperación ante desastres (DRP). Oracle 12c ofrece respaldo y recuperación a un nivel de base de datos conectable, y esto deberá tenerse en cuenta en los planes de recuperación

Seguridad

La seguridad es un área que se ha vuelto extremadamente importante debido a la cantidad de usuarios que pueden acceder a sus bases de datos y la cantidad de acceso externo basado en la web. Los usuarios de la base de datos deben estar autenticados para que sepa con certeza quién está accediendo a su base de datos. Luego, los usuarios deben tener autorización para usar los objetos en Oracle que necesitan para hacer su trabajo. Sin embargo, a pesar de esta necesidad de permisos y acceso para realizar su trabajo, una mejor práctica es otorgar solo la cantidad mínima de permisos y acceso para el rol o usuario. Esto se puede administrar con Oracle Enterprise Manager, SQL Plus, SQL Developer. 

La administración de los permisos de los usuarios es solo una parte de la seguridad en el entorno de la base de datos. El cifrado de datos, la auditoría de acceso y permisos y la observación del acceso a los datos de los usuarios del sistema en entornos de desarrollo son algunas otras áreas que necesitan atención para proporcionar un entorno de base de datos seguro.


Rendimiento y afinación

El rendimiento y el ajuste es posiblemente el área más interesante de la gestión de bases de datos. Los cambios aquí se notan casi de inmediato, y todos los administradores de bases de datos con experiencia tienen historias sobre pequeños cambios que han realizado y que se han traducido en grandes mejoras en el rendimiento. Por otro lado, cada error de rendimiento en el entorno se atribuirá a la base de datos y deberá aprender a lidiar con esto. Los informes del repositorio automático de carga de trabajo (AWR), el paquete de estadísticas, la gestión del rendimiento de OEM y las herramientas de terceros lo ayudarán en esta área. Hay mucho que aprender aquí, pero las herramientas adecuadas lo simplificarán considerablemente.

Administrar objetos de base de datos

Debe administrar todos los objetos de esquema, como tablas, índices, vistas, sinónimos, secuencias y clústeres, así como los tipos de fuentes, como paquetes, procedimientos, funciones y desencadenadores, para asegurarse de que sean válidos y estén organizados de una manera. que ofrecerá un rendimiento adecuado y contará con el espacio adecuado. Los requisitos de espacio de los objetos de esquema están directamente relacionados con los espacios de tabla y los archivos de datos que están creciendo a un ritmo increíble. SQL Developer u OEM pueden simplificar esto, algo de lo que verá ejemplos más adelante en este capítulo.

Administración de almacenamiento

Las bases de datos están creciendo a un ritmo increíble. Debe administrar el espacio con cuidado y prestar especial atención al espacio utilizado por los archivos de datos y los registros de archivo. Además, con el Área de recuperación rápida (FRA), hay áreas de respaldo que deben administrarse para su uso de espacio. Con Automatic Segment Space Management (ASSM), la necesidad de reorganizar los objetos de la base de datos ha disminuido. Las reorganizaciones también utilizan recursos considerables, por lo que debería evaluarse si un objeto debe reorganizarse o no. Hay utilidades en línea que se supone que ayudan con la reorganización de índices y tablas mientras permanecen en línea, pero no realizan estas operaciones a menos que sea necesario. 

Gestión del cambio

Poder actualizar o cambiar la base de datos es una habilidad que requiere conocimiento de muchas áreas. Las actualizaciones del esquema de la base de datos, la lógica de procedimiento en la base de datos y el software de la base de datos deben realizarse de manera controlada. Los procedimientos y herramientas de control de cambios, como el Change Management Pack de Oracle y las ofertas de terceros, lo ayudarán.

Programar trabajos

Desde Oracle Database 10g, DBMS_SCHEDULER se introdujo con el DBMS_JOBS existente. Permite que los trabajos se programen para una fecha y hora específicas, y categorizar los trabajos en clases de trabajo que luego se pueden priorizar. Esto significa que los recursos se pueden controlar por clase de trabajo. Por supuesto, se pueden utilizar otros sistemas de programación nativos como crontab en Linux y Unix, así como otras ofertas de terceros.

Los trabajos pueden incluir cualquiera de las tareas de mantenimiento de la base de datos, como copias de seguridad y scripts de supervisión. La agrupación de los trabajos de supervisión y mantenimiento en una clase de trabajo puede darles una prioridad menor que un trabajo por lotes de la aplicación que debe finalizar en un breve período de tiempo.

Administración de redes

Oracle Networking es un componente fundamental de la base de datos con el que deberá sentirse cómodo. La resolución de problemas de conexiones a la base de datos es similar a la resolución de problemas de rendimiento, porque aunque la base de datos está activa y disponible, si sus aplicaciones no pueden acceder a ella, es lo mismo que si no estuviera disponible. Las opciones de conectividad de bases de datos como tnsnames, Oracle Internet Directory (OID) y Oracle Listener requieren planificación para garantizar que se cumplan los requisitos de rendimiento y seguridad de una manera sencilla de administrar.

Alta disponibilidad

Con la información y los datos disponibles las 24 horas del día, los 7 días de la semana, la arquitectura de sistemas de alta disponibilidad ha caído en manos del administrador de la base de datos. Las opciones en el lado de la base de datos incluyen Real Application Clusters, Data Guard, replicación y opciones de recuperación rápida. También hay opciones de virtualización y hardware para proporcionar sistemas redundantes y disponibles.

... Y sobe todo: Solución de problemas

Aunque la solución de problemas puede no ser lo que consideraría un área clásica de la administración de bases de datos, es un área con la que se encontrará a diario. Necesitará herramientas que le ayuden con esto. My Oracle Support proporciona soporte técnico y es un recurso invaluable. Los registros de alerta y los archivos de volcado de Oracle también le ayudarán enormemente. La experiencia será su mayor aliado aquí y cuanto antes se sumerja en el soporte de la base de datos, más rápido progresará.

11 febrero 2021

Prácticas recomendadas de copia de seguridad y recuperación de bases de datos

 

La capacidad de restaurar bases de datos a partir de copias de seguridad válidas es una parte vital para garantizar la continuidad del negocio. La integridad de la copia de seguridad y las restauraciones son una pieza importante de los objetivos de control de TI del IT Governance Institute para Sarbanes-Oxley, 2.ª edición. En muchos casos, los auditores de TI simplemente confirman si las copias de seguridad se están realizando en disco o en cinta, sin considerar la integridad o viabilidad de los medios de copia de seguridad.

Este artículo cubre los temas relacionados con la pérdida de datos y los tipos de respaldo y recuperación de bases de datos disponibles. También se proporcionan las mejores prácticas que pueden ayudar a un auditor a evaluar la efectividad de la copia de seguridad y recuperación de la base de datos. Este artículo se centra en las tecnologías y capacidades del sistema de administración de bases de datos relacionales (RDBMS) de Oracle y Microsoft (MS) SQL Server porque, en conjunto, cubren aproximadamente el 40 por ciento de todas las instalaciones de bases de datos. 

Una de las responsabilidades clave de un administrador de bases de datos (DBA) es prepararse para la posibilidad de fallas en los medios, hardware y software, así como recuperar bases de datos durante un desastre. En caso de que ocurra alguna de estas fallas, el objetivo principal es garantizar que la base de datos esté disponible para los usuarios dentro de un período de tiempo aceptable, al tiempo que se asegura que no haya pérdida de datos. Los administradores de bases de datos deben evaluar su preparación para responder eficazmente a tales situaciones respondiendo las siguientes preguntas:

  • ¿Qué tan seguro está el DBA de que los datos de los que depende el negocio de la empresa se hayan respaldado correctamente y que los datos se pueden recuperar de estos respaldos dentro de los límites de tiempo permitidos, según un acuerdo de nivel de servicio (SLA) o el objetivo de tiempo de recuperación, como se especifica en el plan de recuperación ante desastres de la organización?
  • ¿Ha tomado el DBA medidas para redactar y probar los procedimientos para proteger y recuperar las bases de datos de numerosos tipos de fallas?
La siguiente es una lista de verificación para los procedimientos de copia de seguridad y recuperación de la base de datos que se explican a lo largo de este artículo:

  • Desarrolle un plan de respaldo integral.
  • Realice una gestión de copias de seguridad eficaz.
  • Realice pruebas periódicas de restauración de bases de datos.
  • Tener SLA de respaldo y recuperación redactados y comunicados a todas las partes interesadas.
  • Haga que se redacte y documente la parte de la base de datos del plan de recuperación ante desastres (DRP).
  • Mantenga actualizados sus conocimientos y experiencia sobre las herramientas de copia de seguridad y recuperación de bases de datos y sistemas operativos.

Plan de respaldo integral

Los DBA son responsables de elaborar un plan de respaldo integral para las bases de datos de las que son responsables. El plan de respaldo debe incluir todos los tipos de RDBMS dentro de la empresa y debe cubrir las siguientes áreas:

  • Decide qué necesitas respaldar. Es imperativo que el DBA esté al tanto de la base de datos y los componentes de aplicaciones y sistemas operativos relacionados que deben respaldarse, ya sea mediante una copia de seguridad en línea o una copia de seguridad en frío fuera de línea.
          Los siguientes son detalles de lo que se debe respaldar:            
    • Software del sistema operativo: un evento como una falla de hardware requerirá una restauración completa del sistema, comenzando con el sistema operativo, por lo que es necesario realizar una copia de seguridad del sistema operativo del servidor de base de datos inicialmente y después de cualquier actualización del sistema o cambio de configuración.
    • Software RDBMS: se debe realizar una copia de seguridad del software RDBMS inicialmente y después de cualquier parche / actualización.
    • Software de aplicación (cuando corresponda): esto se aplica especialmente a Oracle E-Business Suite, Oracle Application Server y Oracle Enterprise Manager (OEM). El administrador de bases de datos de la aplicación debe completar una copia de seguridad completa inicial de las aplicaciones en el disco utilizando un comando del sistema operativo apropiado y, luego, programar futuras copias de seguridad incrementales, por ejemplo, después de cualquier parche / actualización. Estas copias de seguridad también deben transferirse a cinta.
    • Contraseñas: se deben conservar todas las contraseñas de superusuario que puedan ser necesarias durante la recuperación. Es una buena idea asegurarse de que se cambien las contraseñas predeterminadas que vinieron con la instalación inicial del RDBMS.
    • Todos los componentes de las bases de datos de Oracle:
      • Archivo de parámetros de la base de datos: un archivo de parámetros o un archivo de parámetros del servidor (SPFILE) define los parámetros de inicialización persistentes de una base de datos, incluida la información sobre los archivos de control de la base de datos.
      • Archivo (s) de control de la base de datos: el archivo de control almacena el estado de la estructura física de la base de datos. Si deja de estar disponible, la base de datos no puede funcionar. Es imperativo que se realice una copia de seguridad de estos archivos mientras se realiza una copia de seguridad de otros componentes de la base de datos. En versiones posteriores de Oracle (9i en adelante), el DBA puede configurar la copia de seguridad automática del archivo de parámetros, así como el archivo de control, para garantizar que se realice una copia de seguridad de estos después de cada copia de seguridad y después de cualquier cambio estructural en la base de datos.
      • Archivos de datos de la base de datos: estos deben respaldarse durante la copia de seguridad en frío, así como durante la copia de seguridad en línea, utilizando el Administrador de recuperación de Oracle (RMAN) o, en las versiones de Oracle Database en las que no se introdujo RMAN, colocando los espacios de tabla en modo de copia de seguridad. El DBA debe intentar ejecutar todas las bases de datos de producción en el modo de registro de archivo para que sea posible la recuperación hasta el punto de falla.
      • Rehacer los archivos de registro y los registros de rehacer archivados: mientras realiza una copia de seguridad en frío, el DBA necesita hacer una copia de seguridad de los registros de rehacer. Cuando la base de datos se ejecuta en modo de registro de archivo y realiza una copia de seguridad en línea, el DBA necesita archivar los registros de rehacer de forma manual o automática y luego hacer una copia de seguridad de todos los registros de rehacer del archivo.
      • Archivos de red de Oracle: es importante realizar una copia de seguridad de todos los archivos de red de Oracle inicialmente y después de cualquier cambio.
      • Archivos de contraseña: los archivos de contraseña, cuando se utilizan, deben respaldarse inicialmente y después de cualquier cambio. Wallets, por ejemplo.
    • Bases de datos de MS SQL Server:
      • Realice una copia de seguridad de las bases de datos del sistema y de los usuarios.
      • Tenga un plan de mantenimiento separado para las bases de datos del sistema, es decir, maestro, modelo, msdb. Master solo admite copias de seguridad completas; La copia de seguridad de tempdb no es necesaria, ya que se reconstruye durante el inicio de SQL Server.
      • Realice una copia de seguridad de todas las bases de datos de los usuarios. Configure todas las bases de datos de usuarios para el modelo de recuperación completo y realice una copia de seguridad de los registros de transacciones y de la base de datos.
  • Determine el tipo de copia de seguridad apropiado para usar con sus datos.
    • Bases de datos de Oracle
        1. Copias de seguridad lógicas: este tipo de copia de seguridad se realiza mediante las utilidades de Oracle "exp." A partir de la versión 10g, también se puede utilizar Data Pump. Se puede realizar una copia de seguridad de toda la base de datos, esquemas individuales, tablas o espacios de tabla. La restauración se realiza mediante "imp" o Data Pump. Con tales copias de seguridad, la recuperación hasta el punto de falla no es posible.
          1. Respaldos físicos fuera de línea o en frío: la base de datos se debe cerrar y se debe realizar una copia de todos los archivos de datos esenciales y otros componentes de la base de datos.
            1. Copias de seguridad físicas en línea o en caliente: este método permite realizar copias de seguridad de la base de datos mientras la base de datos está en funcionamiento. Se deben tener en cuenta los siguientes puntos al realizar copias de seguridad en línea:
              • Ponga los espacios de tabla en modo de copia de seguridad y haga una copia de seguridad de los archivos de datos asociados mediante un comando de copia del sistema operativo, o utilice RMAN, una herramienta sólida proporcionada por Oracle para la copia de seguridad y la recuperación con la versión 8.x en adelante. Oracle agrega nueva funcionalidad a esta herramienta con cada versión. RMAN puede usar el archivo de control de la base de datos para mantener su catálogo, o el DBA puede configurar el esquema para cada base de datos, en una base de datos separada para los catálogos de RMAN.
              • El DBA debe revisar y tener en cuenta la matriz de compatibilidad de RMAN para la base de datos que se está respaldando / restaurando, así como el ejecutable de RMAN y la base de datos / esquema del catálogo de RMAN.
              • Los administradores de bases de datos deben familiarizarse con las copias de seguridad completas, incrementales y diferenciales y configurarlas mediante scripts de RMAN. Los DBA deben revisar su edición RDBMS, por ejemplo, las copias de seguridad incrementales no son posibles en las ediciones estándar anteriores a Oracle 10g. Para restaurar / recuperar una base de datos hasta el punto de falla o un punto anterior en el tiempo, el DBA debe poner la base de datos en modo de registro de archivo y hacer una copia de seguridad de todos los registros de rehacer archivados.
              • Es importante no olvidar realizar una copia de seguridad del catálogo de RMAN al final de cada copia de seguridad. Los administradores de bases de datos pueden realizar una copia de seguridad de exportación del esquema de catálogo de RMAN.
          • Base de datos Microsoft SQL Server:
            • Copias de seguridad lógicas: en SQL Server, se pueden realizar copias de seguridad de objetos de esquema individuales en archivos planos en cualquiera de los formatos de archivo admitidos. Luego, los archivos planos se pueden restaurar utilizando herramientas como la utilidad bcp, el Asistente de importación y exportación o las herramientas de SQL Server Integration Services.
            • Copias de seguridad físicas: se recomienda que todas las bases de datos de los usuarios se configuren para el modelo de recuperación completa, y que tanto la base de datos como los registros de transacciones sean respaldados para restaurar / recuperar la base de datos hasta el punto de falla. Los administradores de bases de datos deben familiarizarse a fondo con los modelos de recuperación de bases de datos y las copias de seguridad completas, diferenciales y de registro de transacciones, y configurarlas en consecuencia. La estrategia de copia de seguridad de archivos o grupos de archivos se puede utilizar si las bases de datos de las que se realizará la copia de seguridad son bases de datos muy grandes (VLDB) que están particionadas entre varios archivos.
        • Establezca una estrategia para manejar las copias de seguridad de VLDB: en Oracle, el DBA puede reducir la ventana de copia de seguridad para las VLDB asignando varios canales y ajustando las copias de seguridad, puede ahorrar espacio en disco mediante el uso de copias de seguridad comprimidas y puede bloquear el seguimiento con técnicas de copia de seguridad incrementales con lo último Versiones El DBA debe revisar la versión y edición de la base de datos para confirmar la disponibilidad de esta opción. Si esto no funciona, el DBA puede considerar configurar copias de seguridad de espejo dividido. Para SQL Server, el DBA puede dividir la base de datos entre varios archivos y utilizar la estrategia de copia de seguridad de archivos o grupos de archivos. Además, el uso de varios dispositivos de respaldo en SQL Server permite que los respaldos se escriban en todos los dispositivos en paralelo.
        • Establezca una programación y una ventana de respaldo adecuadas: es una buena práctica seleccionar una ventana de respaldo en un punto en el que la menor cantidad de actividad afecte a la base de datos para que la copia de respaldo no reduzca los recursos disponibles del servidor de base de datos y ralentice la actividad del usuario de la base de datos. El DBA puede ajustar la ventana de respaldo al paralelizar los respaldos utilizando múltiples canales; sin embargo, el DBA debe revisar la versión y edición de la base de datos para confirmar la disponibilidad de esta opción. En la gran mayoría de los casos, es mejor configurar un ciclo de respaldo semanal comenzando con respaldos completos el viernes por la noche o el sábado por la mañana y respaldos incrementales / diferenciales durante los días de semana. Las copias de seguridad del registro de transacciones / archivos se pueden programar para cada pocas horas, dependiendo de la volatilidad de la base de datos.
        • Decida dónde almacenar las copias de seguridad: se pueden realizar copias de seguridad de las bases de datos de Oracle y MS SQL Server directamente en cinta o disco (localmente o en la red), y luego las copias de seguridad se pueden archivar en cinta. Es una buena práctica realizar copias de seguridad en disco, transferirlas a cinta y almacenar cintas fuera del sitio para la recuperación de desastres (DR). Las copias de seguridad en disco son más rápidas; Los administradores de bases de datos tienen más control y pueden monitorearlos mejor y, con este método, los administradores de bases de datos mantienen dos conjuntos de copias de seguridad, una en disco y la otra en cinta. Durante la restauración, si las copias de seguridad aún están en el disco, será una restauración más rápida, reduciendo el tiempo medio de recuperación (MTTR).
        • Desarrolle una política de retención de copias de seguridad: la política de retención de copias de seguridad se relaciona con el programa de rotación del disco y la cinta y debe decidirse según el SLA establecido con la comunidad de usuarios empresariales. El propietario de los datos debe especificar el período de conservación de los datos. El período de retención puede variar de meses a años, según las leyes locales. En consecuencia, el DBA debería eliminar las copias de seguridad antiguas para crear espacio para las copias de seguridad actuales. La política de retención de datos debe elegirse con cuidado, asegurándose de que complementa la política de retención del subsistema de medios de respaldo y los requisitos para la estrategia de recuperación de respaldo. Si no utiliza un catálogo, el DBA debe asegurarse de que el parámetro de instancia de tiempo de mantenimiento de registros del archivo de control coincida con la política de retención.

        Gestión eficaz de copias de seguridad

        Después de hacer un plan de respaldo sólido y completar el trabajo inicial, el DBA debe administrar adecuadamente los respaldos, teniendo en cuenta los siguientes puntos:
        • Automatización de copias de seguridad: para Oracle, configure las copias de seguridad a través de OEM o utilice una herramienta de programación del sistema operativo, y envíe la salida a un archivo de registro que pueda revisarse en busca de errores. En SQL Server, use planes de mantenimiento para programar copias de seguridad.
        • Supervisión de copias de seguridad: configure la supervisión con las herramientas adecuadas para que el administrador de bases de datos reciba un correo electrónico o una alerta a través de un buscapersonas o teléfono celular por cualquier copia de seguridad fallida, que debe volver a ejecutarse lo antes posible.
        • Registros y catálogos de respaldo: revise los registros de respaldo y la información del catálogo de respaldo periódicamente para detectar cualquier problema. Utilice los informes de RMAN para mostrar el estado de la copia de seguridad. Para Oracle, realice una copia de seguridad de la base de datos del catálogo RMAN exportando todos los esquemas del catálogo periódicamente, así como realizando una copia de seguridad de exportación del esquema del catálogo RMAN al final de cada copia de seguridad. Para SQL Server, bases de datos del sistema de respaldo, especialmente master y msdb.
        • Mantenimiento del catálogo de la base de datos: con las bases de datos de Oracle, utilice "eliminar obsoletos" para eliminar las copias de seguridad que están fuera de la política de retención de la organización. Si no se eliminan las copias de seguridad obsoletas, el catálogo seguirá creciendo y el rendimiento se convertirá en un problema. La verificación cruzada (copia de seguridad de verificación cruzada) comprobará que el archivo de catálogo / control coincide con las copias de seguridad físicas.
        • Validación de copias de seguridad: valide y verifique las copias de seguridad sin realizar restauraciones reales.
        • Configuración de dependencias: cuando realice una copia de seguridad en disco, archive estas copias de seguridad en cinta tan pronto como se complete la copia de seguridad en disco.
        Configure un proceso para que las copias de seguridad del disco se transfieran a cinta sin pérdida de tiempo.

        Prueba de restauración de respaldo

        Imagine el siguiente escenario: una inundación ha azotado el área en la que reside la sede de una empresa y toda la infraestructura de TI se ha dañado, pero no se ha destruido. Antes del evento, los administradores de bases de datos realizaron copias de seguridad en los medios de copia de seguridad, siguiendo todos los procesos indicados anteriormente en este artículo, y los almacenaron fuera del sitio. En la auditoría de TI más reciente de la empresa, el auditor calificó el proceso de respaldo como "efectivo".

        Se recuperan y cargan los medios de respaldo del almacenamiento externo. Aparece un mensaje en la pantalla que indica que los medios de respaldo son "ilegibles" debido a problemas de integridad. ¿Lo que podría haber ocurrido?  Pueden haber pasado muchas cosas. Sin embargo, está claro que no se dio un paso crítico. La restauración desde los medios de respaldo nunca se probó realmente. El control se marcó como efectivo porque se había implementado un proceso de respaldo y se estaba realizando. Además, nunca se recibieron errores cuando la empresa realizó una copia de seguridad en los medios de copia de seguridad.

        Las copias de seguridad no sirven de nada si el equipo de TI no puede restaurar los datos en el sistema en el momento en que sea necesario. Un DBA debe formular una estrategia detallada para esta tarea:

        1. Prueba de restauración de bases de datos: debe existir un requisito para probar las restauraciones de la base de datos desde el disco y desde las copias de seguridad en cinta.
        2. Validación de restauraciones siempre que sea posible: el DBA puede validar y verificar las copias de seguridad sin realizar restauraciones reales. La validación de las copias de seguridad mediante el comando "restaurar y validar la base de datos" hará todo, excepto restaurar la base de datos. Este es el mejor método para determinar si la copia de seguridad es buena y utilizable antes de encontrarse en una situación en la que se vuelva crítica.
        3. Actualización de bases de datos que no son de producción a partir de copias de seguridad de producción: es una buena práctica crear periódicamente bases de datos que no son de producción a partir de copias de seguridad de producción utilizando los comandos de la utilidad de copia de seguridad / restauración adecuados como práctica de restauración.
        4. Realización de pruebas de restauración anuales / bianuales desde cinta como parte de la auditoría: el DBA tendrá que explicar el proceso a través de una narrativa, conservar registros y tomar capturas de pantalla para mostrar este tipo de pruebas de restauración.
        5. Restauraciones reales: durante las restauraciones reales, el DBA debe realizar una copia de seguridad de la base de datos antes de realizar la restauración. Según el tipo de pérdida y las copias de seguridad disponibles, el DBA debe decidir si opta por una recuperación completa (en un momento determinado) o incompleta. La recuperación incompleta puede basarse en el tiempo, en la cancelación o en los cambios.
        6. Estrategia para recuperarse de la corrupción de la base de datos: para las bases de datos Oracle, el DBA puede activar la verificación de bloques usando los parámetros apropiados para detectar la presencia de bloques corruptos en la base de datos. Esto tiene una ligera sobrecarga de rendimiento, pero permitirá la detección temprana de bloques corruptos causados ​​por problemas del sistema de entrada / salida (E / S), sistema de almacenamiento o disco subyacente. De forma predeterminada, RMAN también busca bloques corruptos durante la copia de seguridad. En versiones posteriores de Oracle, RMAN se puede utilizar para reparar bloques dañados en la base de datos.

        SLA de respaldo y recuperación

        El equipo de DBA debe redactar un SLA de respaldo y recuperación, que cubra los detalles de los procedimientos de respaldo e incluya un cronograma para la recuperación, y que la administración lo apruebe. El SLA no ayuda en el proceso de recuperación en sí, pero establece las expectativas de la comunidad de usuarios (y de la administración) para el proceso de recuperación, lo que puede proporcionar al equipo más tiempo para completar el proceso de restauración.

        Plan de recuperación en un desastre

        El DBA debe asegurarse de que las bases de datos se incluyan como un elemento clave en el DRP general de la empresa. Todas las partes interesadas deben comprender los elementos del plan de recuperación y en qué orden el equipo de TI restaurará las bases de datos. La empresa debe proporcionar su opinión en esta etapa para que las aplicaciones más críticas para la empresa estén disponibles lo antes posible.

        Herramientas de respaldo y recuperación de bases de datos y sistemas operativos

        Parece obvio, pero los administradores de bases de datos juegan el papel final y más importante en el proceso, ya que deben mantener actualizados sus conocimientos sobre las herramientas de copia de seguridad y recuperación para RDBMS. Durante el evento de restauración real, los administradores de bases de datos no tendrán tiempo para descubrir ningún avance en las herramientas de respaldo y recuperación.

        Conclusión

        La responsabilidad principal del equipo de administración de la base de datos es revisar todos los tipos de RDBMS en la empresa y desarrollar un plan de respaldo integral para llevar a cabo una administración de respaldo efectiva al monitorear de manera proactiva los respaldos, recibir alertas de respaldos fallidos y volver a ejecutarlos sin problemas, sin pérdida de tiempo. Es una buena práctica realizar una copia de seguridad de los datos en un disco físico y luego archivarlos en una cinta para fines de recuperación de desastres.

        Una vez que se ha establecido un enfoque, es imperativo probar la restauración de datos periódicamente como parte de la estrategia de copia de seguridad y restauración, y revisar todas las opciones antes de ejecutar la restauración / recuperación real. Es importante confirmar que el equipo de DBA está al día con las últimas herramientas de respaldo y recuperación y asegurarse de que el equipo tenga un proceso claramente documentado con responsabilidades claras. Si los administradores de bases de datos mantienen copias de seguridad adecuadas, las supervisan de forma proactiva y pueden garantizar la recuperación de los datos hasta el punto requerido por la empresa, han realizado una gran parte del trabajo para el que fueron contratados.

        Los auditores de TI pueden ayudar a los equipos de administración de datos a fortalecer sus controles y procesos de recuperación de datos validando las operaciones del DBA, incluida la prueba de la recuperación de datos. Este esfuerzo continuo, proactivo y cooperativo entre la auditoría interna y el equipo de DBA puede proporcionar seguridad a la gerencia de que, en caso de un desastre, los datos de la empresa se pueden recuperar.

        20 enero 2021

        Monitoreo de índices de bases de datos

         


        Para aquellos que no están familiarizados con él, el monitoreo de índices es la forma de Oracle de rastrear si se está utilizando un índice, lo que le permite saber si es necesario. 

        Dos cosas a tener en cuenta: 

        • No siempre marca un índice como usado, incluso si se usa. Si no se usa en un plan de ejecución, pero se usa para hacer cumplir una clave externa o restricción única, no se marcará como usado. 
        • La vista utilizada para observar el uso de índices es específica del esquema. Es posible que esté monitoreando índices, pero los índices no aparecerán en v $ object_usage a menos que inicie sesión como propietario del esquema. Es mejor ir directamente a la consulta subyacente para ver todos los índices supervisados (consulta a continuación).
        Dado que la supervisión de índices es de muy bajo costo, tiene sentido activarla para todos los índices candidatos. Los índices en FK y los índices únicos funcionan incluso si no se utilizan en los planes de ejecución, por lo que no son candidatos para descartarse. Aquí está la consulta para obtener todos los índices no únicos, que no son de FK (se supone que no hay PK concatenados; si tiene eso, la consulta se vuelve más complicada):

        SELECT 'ALTER INDEX '||ic.index_name||' MONITORING USAGE;'

          FROM all_ind_columns ic, all_indexes i

         WHERE i.uniqueness = 'NONUNIQUE' --don't monitor unique indexes

           AND i.table_owner = 'SCHEMA_OWNER_HERE'

           AND ic.index_owner = i.owner

           AND ic.index_name = i.index_name

           AND ic.position = 1

           AND NOT EXISTS (SELECT 'x' --Don't monitor indexes on FK's

                             FROM all_cons_columns cc, all_constraints c

                            WHERE ic.table_name = cc.table_name

                              AND ic.column_name = cc.column_name

                              AND c.constraint_name = cc.constraint_name

                              AND c.constraint_type IN ('R'));

        Aquí está la consulta para ver los objetos monitoreados si no ha iniciado sesión como propietario del esquema:

        select d.username, io.name, t.name,
               decode(bitand(i.flags, 65536), 0, 'NO', 'YES'),
               decode(bitand(ou.flags, 1), 0, 'NO', 'YES'),
               ou.start_monitoring,
               ou.end_monitoring 
        from sys.obj$ io, sys.obj$ t, sys.ind$ i, sys.object_usage ou,
             dba_users d
        where io.owner# = d.user_id
          AND d.username = 'SCHEMA_OWNER_HERE'
          and i.obj# = ou.obj#
          and io.obj# = ou.obj#
          and t.obj# = i.bo#;

        Y aquí hay un ejemplo de monitoreo de índices en acción, incluido el uso de índice único que no se marca:
        CREATE TABLE test_monitoring AS SELECT level id, dbms_random.value(1,1000) value FROM dual CONNECT BY LEVEL <= 5000;

        Table created.

        CREATE UNIQUE INDEX test_monitoring_idx ON test_monitoring(id);

        Index created.

        ALTER INDEX test_monitoring_idx MONITORING USAGE;

        Index altered.

        --Using index for PK enforcement - does not flag the index as used:
        INSERT INTO test_monitoring VALUES (100,0);
        INSERT INTO test_monitoring VALUES (100,0)
        *
        ERROR at line 1:
        ORA-00001: unique constraint (BAYPAS.TEST_MONITORING_IDX) violated 

        SELECT index_name, used FROM v$object_usage WHERE index_name = UPPER('test_monitoring_idx');

        INDEX_NAME                     USE                                              
        ------------------------------ ---                                              
        TEST_MONITORING_IDX            NO                                               

        --But we run a select that will use the index


        SELECT * FROM test_monitoring WHERE id = 100;

                ID      VALUE                                                           
        ---------- ----------                                                           
               100   255.5571                                                           

        --And now the index shows up as used:
        SELECT index_name, used FROM v$object_usage WHERE index_name = 'TEST_MONITORING_IDX';

        INDEX_NAME                     USE                                              
        ------------------------------ ---                                              
        TEST_MONITORING_IDX            YES

        Oracle RAC Highly Available IP (HAIP)




        Oracle 11gR2 introdujo el RAC Highly Available IP (HAIP) para la Interconexión de Clúster para ayudar a eliminar un único punto de falla. Si el nodo en el clúster solo tiene un adaptador de red para la red privada, y ese adaptador falla, entonces el nodo ya no podrá participar en las operaciones del clúster. No podrá realizar su latido con el clúster. Eventualmente, los otros nodos desalojarán el nodo defectuoso del clúster. Si el clúster solo tiene un único conmutador de red para la Interconexión de Clúster y el conmutador falla, entonces todo el clúster quedará comprometido. 

        Cada nodo del clúster tiene acceso a redes privadas duales. Los puntos únicos de falla han sido eliminados. Tenga en cuenta que los adaptadores de red duales sirven como interfaces para conmutadores de red duales.

        No se puede simplemente levantar una segunda red privada y esperar que el software de clusterware comience a utilizar ambas redes. Sin ninguna configuración adicional, solo se usaría una red privada y la otra estaría inactiva.




        Antes de Oracle 11gR2, los arquitectos de sistemas que estaban preocupados con el punto único de falla aprovecharían la agregación de enlaces. Los términos vinculación de NIC, formación de equipos de NIC o enlace de puertos también se utilizan para el mismo concepto. La idea central detrás de la agregación de enlaces es hacer que dos redes privadas actúen como una sola. Las dos redes privadas se combinan para mostrarse al sistema operativo como una unidad. Para el sistema operativo, los adaptadores de red se ven como un adaptador. Si uno de los adaptadores de red física fallara, el sistema operativo apenas notaría y el tráfico de red pasaría a través del adaptador restante.

        Este no es un artículo sobre la arquitectura de máxima disponibilidad y en este punto se estará preguntando qué tiene que ver la agregación de enlaces con la optimización del rendimiento de Oracle RAC. Además de una mayor disponibilidad para el clúster, la agregación de enlaces mejora el rendimiento de la red privada. Dos redes privadas tienen el doble de capacidad y, por lo tanto, el doble del rendimiento de una sola red privada. Cuando el tráfico en la Interconexión de Clúster satura una red privada singular, otra opción es aprovechar la agregación de enlaces para mejorar el rendimiento de la transferencia de la memoria caché global.

        Oracle Grid Infrastructure, desde la versión 11g,  proporciona RAC HAIP, que es la agregación de enlaces, movida al nivel de clusterware. En lugar de vincular los adaptadores de red en el lado del sistema operativo, se le indicó a Grid Infrastructure que use múltiples adaptadores de red. Grid Infrastructure seguirá iniciando HAIP incluso si el sistema está configurado con un solo adaptador de red privado. 

        A continuación, se muestra el nombre del recurso ora.cluster_interconnect.haip está en línea.

        Primea instalación

        Durante mi primera instalación y configuración, tuve que aprender mucho sobre los requisitos de la red para implementar la base de datos RAC. Los conceptos dirección IP, dirección VIP, SCAN y una red de interconexión privada rápida, tuvieon que hacerse presentes en mi cabeza y asimilar que era lo que tendía que hacer.

        Lo que me llamó la atención es esta extraña dirección IP en la interfaz virtual de mi red privada:

        inet 169.254.42.186/19 brd 169.254.42.255 alcance global eth2: 1

        Esto sucede cuando HAIP está activo y configurado.

        Así que comprobaré

        crsctl stat res -t -init

        ora.cluster_interconnect.haip
        1 ONLINE ONLINE srvpcaoraent1 ESTABLE

        Ok, tenía HAIP, pero ¿Qué es HAIP?

        IP de alta disponibilidad es una función que le ayuda a minimizar los desalojos de nodos debido a frecuentes eventos de caída de NIC privados, vinculación, trunking, formación de equipos o tecnología similar para hacer uso de conexiones de red redundantes entre los nodos. Oracle Clusterware ahora ofrece una solución integrada que garantiza el "uso de interconexión redundante", ya que admite la conmutación por error de IP.

        ¡Excelente!

        Leí y encontré cómo ver la dirección IP utilizada globalmente

        seleccione inst_id, name, ip_address de gv $ cluster_interconnects;

        INST_ID NAME IP_ADDRESS
        ———- ————— ———————————————-
        1 eth2: 1 169.254.31.186
        2 eth2: 1 169.254.27.70

        Y también

        oifcfg getif
        eth0 10.1.0.0 público global
        eth2 192.168.181.0 global cluster_interconnect, asm

        oifcfg le permite agregar y eliminar interfaces fácilmente

        $ oifcfg setif -global <interface> / <subnet>: cluster_interconnect>
        $ oifcfg delif -global <nombre_si>

        Según la documentación 18c
         
        De forma predeterminada, el software Oracle Grid Infrastructure utiliza todas las direcciones HAIP para la comunicación de red privada, lo que proporciona equilibrio de carga en el conjunto de interfaces que identifica para la red privada. Si una interfaz de interconexión privada falla o deja de ser comunicativa, Oracle Clusterware mueve de manera transparente la dirección HAIP  




        19 enero 2021

        ¿Cómo seguir utilizando Flash en 2021? Para poder ejecutar Oracle Database Control

         

        ¿Cómo seguir utilizando Flash en 2021?

        Lo más indicado es no utilizar Flash desde 2021 en adelante, pero sabemos que algunas empresas y organismos no han actualizado a tiempo sus sistemas para que eso sea posible. Algunos organismos públicos están enviando comunicaciones sobre cómo seguir utilizando Adobe Flash a partir del 1 de enero. 

        • Descargar un navegador que no deshabilite el funcionamiento de Flash
        • Actualización de Adobe Flash Player
        • Configurar Adobe Flash Player para que permita el acceso al servicio afectado
        Hay que tener en cuenta que, dado que uno de los pasos del proceso consiste en la actualización de Adobe Flash Player, la fecha límite para poder realizarlo es el 31 de diciembre de 2020. Lo primero es descargar Pale Moon, un navegador libre basado en el navegador Firefox que ha garantizado la continuidad del funcionamiento de Adobe Flash Player. Una vez instalado, descargado el idioma español (o el deseado), es necesario tener Adobe Flash Player actualizado a la última versión.

        Ahora crearemos un archivo con el bloc de notas y el siguiente contenido:

        EnableAllowList=1
        AllowListRootMovieOnly=1
        AllowListUrlPattern=https://LAPTOP-3RJGV85G:1158/em
        SilentAutoUpdateEnable=0
        AutoUpdateDisable=1
        EOLUninstallDisable=1

        Ese fichero lo guardaremos como mms.cfg y lo copiaremos en:

        32 bits

        • C:/Windows/system32/Macromed/Flash

        64 bits
        • C:/Windows/SysWOW64/Macromed/Flash
        • C:/Windows/system32/Macromed/Flash



        Se recomienda hacer una copia de seguridad del fichero mms.cfg original, antes de nada. En caso de necesitar acceder a otras aplicaciones flash es necesario añadir al archivo mms.cfg una línea por cada aplicación:

        AllowListUrlPattern=http[s]://[DOMINIO_APLICACION/

        Desinstalación manual y limpia de Oracle 11g Enterprise Edition para Windows

         



        Advertencia: la edición del registro puede causar problemas en su PC. Si tiene problemas al intentar desinstalar Oracle de su estación de trabajo de Windows, o no puede desinstalar las instalaciones de Oracle de manera limpia y adecuada, se pueden utilizar los siguientes pasos para desinstalar todos los productos de Oracle instalados actualmente en la estación de trabajo:

        • Desinstale todos los componentes de Oracle mediante Oracle Universal Installer (OUI).
        • Elimine la clave HKEY_LOCAL_MACHINE / SOFTWARE / ORACLE que contiene entradas de registro para todos los productos de Oracle utilizando regedit.
        • Elimine cualquier referencia a servicios / componentes de Oracle en la siguiente ubicación de registro: HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Services /. Busca entradas clave que comiencen con "Ora" que obviamente están relacionadas con Oracle.
        • Reinicie la estación de trabajo.
        • Elimina el directorio ORACLE_BASE. (es decir, C: \ Oracle)
        • Elimine el directorio C: \ Archivos de programa \ Oracle.
        • Vacíe el directorio temporal.
        • Vacía la papelera de reciclaje.
        Con esto, la computadora está más o menos libre de cualquier componente de Oracle, lo que le permite reinstalar Oracle si es necesario.

        28 noviembre 2020

        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;