Asignatura: Administración de Bases de Datos

Características de la Asignatura

Con la evolución de la tecnología, se han alcanzado cantidades inimaginables para los sistemas de
almacenamiento secundario. Si bien es cierto que la idea original de la administración de bases de datos
se orientó en la construcción de las estructuras ideales y algoritmos eficientes para el almacenamiento y
recuperación de los datos, actualmente esos objetivos se ven rebasados pues es necesario que, lejos de
restringir a los usuarios y aplicaciones en la forma que han de almacenar la información, se pretende
que no haya un patrón o estructura específica para el almacenamiento de la información. La información
debe almacenarse en formatos cada vez más libres y heterogéneos, mientras que la recuperación de la
misma debe seguir siendo igual de eficiente.

Esta asignatura aporta al perfil del Ingeniero en Sistemas Computacionales la capacidad para
administrar sistemas de bases de datos observando las normas internacionales de manejo y seguridad
de la información, utilizando para ello herramientas y metodologías especializadas en el manejo de
grandes volúmenes de información, con el propósito de integrar soluciones computacionales con
diferentes tecnologías, plataformas y dispositivos, basadas en sistemas de bases de datos,
observándose siempre en el desempeño de sus actividades profesionales considerando los aspectos
legales, éticos, sociales y de desarrollo sustentable.

El propósito del presente curso es el de complementar los conocimientos adquiridos en las dos
materias antecesoras (Fundamentos de Base de Datos y Taller de base de datos), con la aplicación de
diferentes aspectos de otras materias, tales como:

             Redes de Computadoras

             Fundamentos de Ingeniería del Software

             Sistemas Operativos

             Taller de sistemas operativos

Se aportan competencias a las asignaturas de Gestión de Proyectos de Software y Programación

Web, que se cursarán posteriormente y se complementa con las competencias que se desarrollan en la
materia de ingeniería de Software.

Intención Didáctica                          

A fin de obtener los resultados esperados, la materia de “Administración de bases de datos” debe
centrarse en la realización de múltiples prácticas aplicadas al entorno de negocios de la región. Es

i
 importante también, orientar al estudiante para lograr la obtención de una certificación como
ADMINISTRADOR DE BASE DE DATOS (Data Base Administrator) y preferentemente, participar en la
implementación de un proyecto conjunto con otra(s) materia(s).

Se organiza el temario, en cinco unidades. Los aspectos a considerar para seleccionar software de
base de datos, funciones del administrador de la base de datos y las nuevas tecnologías y aplicaciones
existentes se cubren en la primera unidad. La segunda unidad se destina a las características y
requerimientos para la instalación de los sistemas manejadores de base de datos. La tercera unidad
tiene que ver con la definición y configuración del espacio de almacenamiento en disco de la base de
datos, archivos de bitácora, definición de múltiples instancias, segmentos y memoria compartida. En la
cuarta unidad se abordan temas de operación y mantenibilidad de los sistemas manejadores de base de
datos. En la quinta unidad se presentan todos los aspectos relacionados con la seguridad de los
manejadores y de los datos de las organizaciones.

El enfoque sugerido para la materia requiere que las actividades prácticas promuevan el desarrollo de
habilidades para la configuración y administración de sistemas de bases de datos empresariales con
ciertos niveles de seguridad en su acceso, mediante la utilización de herramientas comerciales vigentes
en el mercado.

Asimismo, propiciar la implementación de casos de estudio reales que ofrezcan escenarios distintos,
mediante suficientes prácticas que permitan la aplicación de los conceptos y diseños, y el aprendizaje
sea más significativo para el desarrollo de las competencias.

En el desarrollo de la materia, deberán observarse:

         Que los contenidos sean abordados en su totalidad, procurando siempre que los alumnos
cuenten con el material desarrollado por el docente (objetos de aprendizaje), de forma que puedan
realizar trabajo fuera del laboratorio.
         Que el laboratorio de prácticas cuente con al menos dos SGBD que deberán utilizarse durante
el desarrollo de la materia.
         Que toda práctica diseñada por el docente, sea tomada con base al contexto de negocios de la
región donde puede aplicarse el conocimiento adquirido.
         Que los estudiantes sean capaces de utilizar estrategias de aprendizaje auto dirigido, a fin de
desarrollar el sentido de competitividad requerido en un entorno de productividad real.
         Que las evaluaciones ponderen, preferentemente, la observación de buenas prácticas de
administración y utilización de normatividad internacional.

Objetivo del Curso

Tener la capacidad de seleccionar SGBD para la implementación y administración de sistemas de

bases de datos, aplicando esquemas de seguridad, rendimiento y alta disponibilidad en distintas
plataformas, optimizando los recursos económicos y la infraestructura tecnológica disponible en las

ii
 organizaciones.

UNIDAD 1.-   Perspectiva Práctica de la Administración de Bases de Datos

        1.1.        Administrador de Base de Datos (DBA)

                1.1.1.   Funciones de un DBA
                1.1.2.   Relación del DBA con otras áreas de Sistemas.
        1.2.        Análisis de los manejadores de bases de datos
        1.3.        Consideraciones para elegir un buen DBMS
        1.4.        Nuevas tecnologías y aplicaciones de los sistemas de bases de datos

UNIDAD 2.-    Arquitectura del Gestor

        2.1.        Características del DBMS

                2.1.1.   Estructura de memoria y procesos de la instancia
                2.1.2.   Estructuras físicas de la base de datos.
                2.1.3.   Requerimientos para instalación.
                2.1.4.   Instalación del software de BD en modo transaccional
                2.1.5.   Variables de Ambiente y archivos importantes para instalación
                2.1.6.   Procedimiento general de instalación
                2.1.7.   Procedimiento para configuración
                2.1.8.   Comando generales de alta y baja del DBMS

UNIDAD 3.-    Configuración y Administración del Espacio en Disco

        3.1.        Estructuras lógicas de almacenamiento

                3.1.1.   Definición de espacio de almacenamiento
                3.1.2.   Definición y creación del espacio asignado para cada base de datos
                3.1.3.   Bitácoras
                3.1.4.   Particiones
                3.1.5.   Espacios Privados
                3.1.6.   Espacios para objetos
        3.2.        Segmentos
        3.3.        Memoria Compartida
        3.4.        Instancias Múltiples

UNIDAD 4.-    Operación y Mantenibilidad

        4.1.        Bitácoras de trabajo del DBMS

                4.1.1.   Funciones específicas de las bitácoras

iii
                 4.1.2.   Recuperación (rollback)
                4.1.3.   Permanencia (commit)
        4.2.        Definición de los modos de operación de un DBMS (alta, baja, recovery)
        4.3.        Comandos de activación de los modos de operación
        4.4.        Manejo de índices
                4.4.1.   Tipos de Índices
                4.4.2.   Reorganización de índices
                4.4.3.   Reconstrucción de índices

UNIDAD 5.-    Seguridad

        5.1.        Respaldo y Recuperación

                5.1.1.   Espejeo (mirroring)
                            5.1.1.1.       Beneficios del espejeo de Datos en un DBMS
                        5.1.1.2.       Activación de espejeo en un DBMS
                        5.1.1.3.       Creación de espacios de disco con espejo
                5.1.2.   Réplica (replication)
                        5.1.2.1.       Beneficios de la réplica de Datos en un DBMS
                5.1.3.   Métodos de respaldo de un DBMS
                        5.1.3.1.       Elementos y frecuencia de respaldo
                        5.1.3.2.       Comandos para respaldo de datos
                        5.1.3.3.       Métodos de recuperación de un DBMS
                5.1.4.   Comando para recuperación
                            5.1.4.1.       Ventajas y Desventajas de cada método      
                        5.1.4.2.       Aplicación de cada método
        5.2.        Migración de la Base de Datos
        5.3.        Monitoreo y Auditoría de la Base de Datos
                5.3.1.   Monitoreo
                        5.3.1.1.       Monitoreo general de un DBMS
                        5.3.1.2.       Monitoreo de espacio en disco
                        5.3.1.3.       Monitoreo de logs
                        5.3.1.4.       Monitoreo de Memoria compartida
                        5.3.1.5.       Monitoreo de Base de Datos
                        5.3.1.6.       Monitoreo de modos de operación
                        5.3.1.7.       Monitoreo de espacios espejeados
                5.3.2.   Auditoría
                        5.3.2.1.       Habilitar y deshabilitar el modo de auditoría
                        5.3.2.2.       Consultas de las tablas vistas con información de la auditoría
        5.4.        Herramientas de software y hardware para monitoreo y administración automática.
Unidad 1: Perspectiva Práctica de la Administración de Bases de
Datos

iv
 1.1. Administrador de Base de Datos (DBA)

Es el profesional que administra las tecnologías de la información y la comunicación,

siendo responsable de los aspectos técnicos, tecnológicos, científicos, inteligencia de
negocios y legales de bases de datos. Tiene la responsabilidad de mantener y operar
las bases de datos que conforman el sistema de información de una compañía.

Debido a la importancia de los datos que están a su cargo, el administrador de bases

de datos debe ser experto en TI (tecnología de la información), teniendo particular
conocimiento de DBMS (sistemas de administración de bases de datos) y el lenguaje de
consulta SQL. También debe tener conocimiento de varios tipos de lenguaje de
programación para poder automatizar ciertas tareas.

1.1.1     Funciones de un DBA

Función principal:

 Implementar, dar soporte y gestionar bases de datos corporativas

 Crear y configurar bases de datos relacionales

 Ser responsables de la integridad de los datos y la disponibilidad

 Diseñar, desplegar y monitorizar servidores de bases de datos

   Diseñar la distribución de los datos y las soluciones de almacenamiento

 Garantizar la seguridad de las bases de datos, incluyendo backups y

 

recuperación de desastres

   Planificar e implementar el aprovisionamiento de los datos y aplicaciones

 Diseñar planes de contingencia

   Diseñar y crear las bases de datos corporativas de soluciones avanzadas

 Analizar y reportar datos corporativos que ayuden a la toma de decisiones en la

inteligencia de negocios

 Producir diagramas de entidades relacionales y diagramas de flujos de datos,

normalización esquemática, localización lógica y física de bases de datos y
parámetros de tablas

v
 Una de sus tareas es la de asegurar la integridad del sistema de información de la
compañía. Además, es necesario que posea un buen entendimiento de DBMS para
optimizar las consultas, ajustar la configuración de DBMS o para sincronizar en forma
precisa las herramientas de control del acceso a las bases de datos.

Es posible que el administrador de bases de datos tenga que brindar asistencia técnica
a usuarios de las aplicaciones cliente o equipos de desarrollo para solucionar problemas,
dar consejos o ayudar a resolver consultas complicadas.

Al trabajar con el jefe de seguridad, el administrador de bases de datos debe crear

copias de seguridad, planes y procedimientos de restauración para preservar los datos de
los cuales es responsable.

Además de estas habilidades técnicas, el administrador de bases de datos debe

poseer un buen entendimiento de las aplicaciones de la compañía y estar dispuesto a
atender las necesidades de los usuarios cuando desarrolla o edita una base de datos. En
el mejor de los casos, debe tener experiencia en diseño de sistemas de información y
modelos UML (Lenguaje unificado de modelos).

1.1.2 Relación del DBA con Otras Áreas de los Sistemas

En sistemas muy complejos cliente/servidor y de tres capas, la base de datos es sólo

uno de los elementos que determinan la experiencia de los usuarios en línea y los
programas desatendidos. El rendimiento es una de las mayores motivaciones de los DBA
para coordinarse con los especialistas de otras áreas del sistema fuera de las líneas
burocráticas tradicionales. Uno de los deberes menos respetados por el administrador de
base de datos es el desarrollo y soporte a pruebas, mientras que algunos otros
encargados lo consideran como la responsabilidad más importante de un DBA. Las
actividades de soporte incluyen la colecta de datos de producción para llevar a cabo
pruebas con ellos; consultar a los programadores respecto al desempeño; y hacer
cambios a los diseños de tablas de manera que se puedan proporcionar nuevos tipos de
almacenamientos para las funciones de los programas.

1.2 Análisis de los Manejadores de Bases de Datos

SGBD Características Requerimientos (de instalación)

Micros SQL Server 2012 brindará a los Memoria:

oft SQL usuarios grandes avances en tres                        Mínimo: 1 GB
Server campos principales:                        Se recomienda: al menos 4 GB y
(2012) debe aumentar a medida que el tamaño de la

vi
 base de datos aumente para asegurar un
Confianza de misión crítica con rendimiento óptimo.
mayor tiempo activo, rendimiento ultra
rápido y características mejoradas de Velocidad del procesador:
seguridad para cargas de trabajo de                        Mínimo: Procesador x86: 1,0
misión crítica. GHz o Procesador x64: 1,4 GHz
                       Recomendado: 2 GHz o más
Avances innovadores con
exploración de datos de auto-servicio Procesador:
administrado y capacidades                        Procesador x64: AMD Opteron,
asombrosas e interactivas de AMD Athlon 64, Intel Xeon compatible con
visualización de datos. Intel EM64T Intel Pentium IV compatible con
EM64T
La nube en sus propios términos al                        Procesador x86: compatible con
habilitar la creación y extensión de Pentium III o superior
soluciones a lo largo de la nube en las
instalaciones y en la nube pública.  
Micros Compile bases de datos más Procesador: 500 Megahertz (MHz) o más
oft Access rápida y fácilmente que nunca. veloz.

Cree formularios e informes más Memoria (RAM): 256 Megabytes (MB) de RAM
impactantes. o más.

Obtenga acceso más fácilmente a Espacio en disco duro: 1.5 GiB.

las herramientas adecuadas en el
momento exacto. Pantalla (monitor): resolución de 1024×768 o
superior.
Agregue expresiones complejas y
automatización sin escribir ni una línea Sistema operativo: Windows XP con Service
de código. Pack 3 (SP3) (sólo 32bits) o Windows Vista SP1,
Windows 7, Windows Server 2003 R2 con
Obtenga una ubicación central para MSXML 6.0, Windows Server 2008.
los datos.

Obtenga acceso a la base de datos

de formas nuevas.
My                        Escrito en C y en C+ Suficiente espacio en disco rígido para
SQL + descomprimir, instalar, y crear las bases de datos
                       Probado con un de acuerdo a sus requisitos. Generalmente se
amplio rango de compiladores recomienda un mínimo de 200 megabytes.
diferentes
                       Funciona en Un sistema operativo Windows de 32 bits, tal

vii
 diferentes plataformas
                       Proporciona sistemas como 9x, Me, NT, 2000, XP, o Windows Server
de almacenamiento 2003.
transaccionales y no
transaccionales Soporte para protocolo TCP/IP.
                       Un sistema de
reserva de memoria muy rápido
basado en threads
                       Un sistema de
privilegios y contraseñas que es
muy flexible y seguro, y que
permite verificación basada en el
host
InterBa InterBase nos garantiza que es un Versiones soportadas de Sistema
se producto fiable y robusto, probado Operativo: Windows 95 / Windows 98 / Windows
exhaustivamente y que ofrece unos NT Workstation 4.x / Windows 2000
buenos niveles de seguridad.
Protocolos soportados: TCP/IP
Código Abierto
Instalación: Un programa de cliente "shim" es
Mantenimiento prácticamente nulo cargado en los clientes. Éste cargará los
programas apropiados del Servidor para
Bajo Coste de Desarrollo completar la instalación.

Tráfico de red reducido Hardware (Mínimo): Pentium P100 como

mínimo absoluto. 64Mb RAM., Disco Duro de
Integración en Herramientas de 500Mb o similar, Tarjeta de red
Desarrollo
Hardware (recomendado): PC Pentium PIII
1GHz, 128Mb RAM, Disco Duro de 4.0Gb, tarjeta
de red
Oracle                        Admite varias Sistema operativo: Windows 2000 Advanced
opciones de soportes de arranque. Server SP4, Windows XP SP2, Windows 2003
                       Ayuda en la Enterprise Server SP1 (32 bit), Windows 2003
instalación del sistema operativo. Enterprise Server SP1 (64 bit)
                       Proporciona un juego
específico de capacidades de Memoria mínima: 1 GB
procesador de servicio y de
configuración de Oracle ILOM. Memoria recomendada: 2 GB
                       Capacidades de
administración y de solución de Espacio en disco mínimo: 500 MB de
problemas. espacio libre

viii
 Espacio en disco recomendado: 1 GB de
espacio libre
DB2 DB2 UDB es un sistema para Sistema operativo: Windows XP
administración de bases de datos Professional,  Vista Business, Vista Enterprise,
relacionales (RDBMS) multiplataforma, Vista Ultimate, 7 Professional, 7 Enterprise, 7
especialmente diseñada para Ultimate, 8 Standard, 8 Professional
ambientes distribuídos, permitiendo
que los usuarios locales compartan Hardware: Todos los procesadores Intel y
información con los recursos AMD capaces de ejecutar los sistemas operativos
centrales. Windows.
DBase Convertir sus datos en Información •                      Windows XP SP2
valiosa. •                      Intel Pentium 4, 2.40GHz SP2
32bits
Gestiona visualmente los archivos •                      512MB de RAM
de aplicaciones. •                      25mb En el disco duro

Genera automáticamente código

SQL libre de errores.

Crear fácilmente EXE’s de 32 bits.

Agrupar y definir fácilmente las

relaciones entre componentes visuales
a través de los Contenedores de
Objetos.
Parado Contiene nuevas librerías de ayuda Windows 95, Windows 98, o Windows NT® 4.0
x especializadas para que usted cree y
ejecute el lenguaje de Consulta Procesador 486/66 DX o mayor
Estructurado (SQL) sin teclear el
código. 16 MB RAM (32 RAM recomendado)

Paradox agrega un diseñador para 65 MB de espacio en Disco Duro

crear las formas de Web en una
Plataforma independiente.

1.3. Consideraciones para Elegir un Buen DBMS

Consideración al Elegir un DBMS

Número de Usuarios: Cantidad máxima de personas que tengan todo tipo de contacto

ix
con el sistema de base de datos desde que éste se diseña, elabora, termina y se usa

Número de Transacciones: Son las cantidades de transacciones reales promovidas

por eventos como la compra de un producto, la inscripción a un curso o la realización de
un depósito.

Cantidad de Datos para Almacenar: Hace referencia a la capacidad de registros que

se puede almacenar o de recuperar su estado en un momento previo a la pérdida de
datos.

Consistencia de la Información: Impedir que exista información inconsistente o

contradictoria en la BD. Surge cuando existen varias copias del mismo dato y tras la
modificación de una de ellas, las demás no son actualizadas, o lo son pero de forma
incorrecta.

Experiencia Propia o Externa: Contar con el conocimiento necesario para la

interacción con el BDSM y de esa manera poder realizar las tareas que se nos han
presupuesto.

Que OS se Implementará: Si no se tiene un sistema operativo en base al SGBD y

esto también tendría consideraciones como la operatividad y la capacidad de
administración de un servidor en tal o cual SO y los gastos que implicarían su
mantenimiento.

1.4. Nuevas Tecnologías y Aplicaciones de los Sistemas de Bases de Datos

Los sistemas orientados a los datos se caracterizan porque los datos no son de una
aplicación sino de una Organización entera que los va a utilizar; se integran las
aplicaciones, se diferencian las estructuras lógicas y físicas. El concepto de relación cobra
importancia. Originalmente las aplicaciones cubrían necesidades muy específicas de
procesamiento, se centraban en una tarea específica. Las bases de datos evitan las
inconsistencias que se producían por la utilización de los mismos datos lógicos desde
distintos archivos a través de procesos independientes.

El mundo real considera interrelaciones entre datos y restricciones semánticas que

deben estar presentes en una base de datos. No solo debe almacenar entidades y
atributos, sino que también debe almacenar interrelaciones entre datos.

 La redundancia de datos debe ser controlada, pero si se admite cierta redundancia
física por motivos de eficiencia.

x
 Pretenden servir a toda la organización.

 La independencia de los tratamientos sobre los datos y estos mismos, ha tenido una
enorme influencia en la arquitectura de los SGBD.

La definición y descripción del conjunto de datos contenido en la base debe ser única e
integrada con los mismos datos.

La actualización y recuperación de las bases de datos debe realizarse mediante

procesos incluidos en SGBD, de modo que se mantenga la integridad, seguridad y
confidencialidad de la base.

Las limitaciones de los sistemas orientados a archivos puramente secuenciales no los

privaron de ser herramientas eficaces para producir pagos, facturas y otros informes una
o dos veces al mes. Sin embargo, para ejecutar muchas tareas rutinarias en los negocios
se necesita el acceso directo a los datos -La capacidad de tener acceso y procesar
directamente un registro dado sin ordenar primero el archivo o leer los registros en
secuencia.

Los archivos de acceso directo permiten la recuperación de los registros

aleatoriamente, a diferencia de los de acceso secuencial. Sin embargo, los archivos de
acceso directo solamente proporcionaron una solución parcial. Para lograr una solución
más completa a estos problemas fue necesario introducir los sistemas de gestión de
bases de datos.

Los usuarios cada vez necesitamos más recursos en tecnología, es por eso que surgen
las evoluciones de sistemas, y por ende de las bases de datos, es impresionante ver
como la información se procesa en microsegundos, mientras se realizan transacciones al
mismo tiempo en la misma base de datos en lugares y estados diferentes.

La importancia de la información es lo que ha llevado a que las empresas y otras

instituciones inviertan para la seguridad de sus datos, el futuro de la tecnología es incierto
debido a que algunas proyecciones de tecnología estimadas hace 5 años y proyectadas
hasta los próximos 10 años ya son una realidad, la tecnología avanza a pasos
agigantados es por eso que no debemos quedarnos atrás y apostar a las nuevas
tecnologías que sin duda harán más fácil la vida de las personas que tratamos con la
administración y seguridad de la información.

Tanto en uno como en otro papel, la tecnología de bases de datos se ve sometida a

numerosos cambios tanto desde el punto de vista empresarial como tecnológico. Las
nuevas aplicaciones están llevando hasta el límite a los sistemas de bases de datos

xi
disponibles, al incorporar documentos multimedia.

Unidad 2: Arquitectura del Gestor

2.1 Características del DBMS

Los sistemas de administración de bases de datos son usados para:

         Permitir a los usuarios acceder y manipular la base de datos proveyendo

métodos para construir sistemas de procesamiento de datos para aplicaciones que
requieran acceso a los datos.

         Proveer a los administradores las herramientas que les permitan ejecutar

tareas de mantenimiento y administración de los datos.

Algunas de sus características son:

Control de la Redundancia de Datos

Este consiste en lograr una mínima cantidad de espacio de almacenamiento para

almacenar los datos evitando la duplicación de la información. De esta manera se logran
ahorros en el tiempo de procesamiento de la información, se tendrán menos
inconsistencias, menores costos operativos y hará el mantenimiento más fácil.

Compartimiento de Datos

Una de las principales características de las bases de datos, es que los datos pueden
ser compartidos entre muchos usuarios simultáneamente, proveyendo, de esta manera,
máxima eficiencia.

Mantenimiento de la Integridad

La integridad de los datos es la que garantiza la precisión o exactitud de la

información contenida en una base de datos. Los datos interrelacionados deben siempre
representar información correcta a los usuarios.

Soporte para Control de Transacciones y Recuperación de Fallas

Se conoce como transacción toda operación que se haga sobre la base de datos. Las
transacciones deben por lo tanto ser controladas de manera que no alteren la integridad
de la base de datos. La recuperación de fallas tiene que ver con la capacidad de un
sistema DBMS de recuperar la información que se haya perdido durante una falla en el

xii
software o en el hardware.

Independencia de los Datos

En las aplicaciones basadas en archivos, el programa de aplicación debe conocer

tanto la organización de los datos como las técnicas que el permiten acceder a los datos.
En los sistemas DBMS los programas de aplicación no necesitan conocer la
organización de los datos en el disco duro. Este totalmente independiente de ello.

Seguridad

La disponibilidad de los datos puede ser restringida a ciertos usuarios. Según los
privilegios que posea cada usuario de la base de datos, podrá acceder a mayor
información que otros.

Velocidad

Los sistemas DBMS modernos poseen altas velocidades de respuesta y proceso.

Independencia del Hardware

La mayoría de los sistemas DBMS están disponibles para ser instalados en múltiples
plataformas de hardware.

2.1.1 Estructura de Memoria y Procesos de la Instancia

Introducción

Oracle utiliza la memoria para almacenar la siguiente información:

         Código del programa

         Información acerca de una sesión conectada, incluso si no se

encuentra activa.

         Información
necesaria durante la ejecución del programa(por
ejemplo, el estado de las consultas)

         La
información que comparten y con la cual se comunican los
procesos Oracle (por ejemplo, la información de bloqueo)

xiii
         La Caché de Datos

La memoria se puede estructurar en las siguientes partes:

         Área
Global del sistema (SGA), la cual se comparte entre todos los servidores
y los procesos en segundo plano.

         Áreas
globales de programas (PGA), que es privada para cada
servidor y proceso en segundo planos; a cada proceso se asigna un PGA.

         Área de Ordenaciones (Sort Areas).

         Memoria Virtual

         Área de código de Software (SCA).

                                                                                        Figura 1. Estructura de la
memoria en Oracle

Área Global del Sistema (System Global Area, SGA)

El Área Global del Sistema (SGA) es un grupo de estructuras de la memoria

compartida que contiene datos e información de control de una instancia de una BD. Si
varios usuarios se conectan de forma concurrente a la misma instancia, entonces los
datos se comparten en el SGA, por lo que también se llama shared global area.

Una instancia en Oracle se compone de un SGA y de procesos. Cuando se crea una

instancia, Oracle asigna memoria a un SGA automáticamente y esta se devuelve al

xiv
sistema operativo cuando la instancia se cierra. Por tanto, cada instancia posee su
propio SGA.

Además, es de lectura/escritura. Todos los usuarios conectados a una instancia

multiproceso pueden leer la información contenida en el SGA de la instancia y varios
procesos pueden escribir en él durante la ejecución.

Una parte del SGA contiene información general acerca del estado de la base de
datos y de la instancia, a la que los procesos en segundo plano necesitan acceder ( SGA
fija), pero no se almacenan los datos de usuario. El SGA también incluye información de
comunicación entre procesos, como la información de bloqueos. Además, si el sistema
usa una arquitectura de servidor compartido, entonces las colas de petición y respuesta
y algunos contenidos del PGA se encuentran en el SGA.

El SGA contiene la siguiente estructura de datos:

         Caché de los Buffers de la BD (Database Buffer Cache).

         Buffer del Dietario o del Registro del Rehacer (Redo Log Buffer).

         El ‘Pool’ Compartido (Shared Pool).

         Caché de Biblioteca.

         Caché del Diccionario de Datos.

         Estructuras de Control.

         Información diversa

Instancia de una Base de Datos

Cada instancia Oracle está asociada a una base de datos. Cuando se inicia una base
de datos en un servidor (independientemente del tipo de ordenador), se le asigna un
área de memoria (SGA) y lanza uno o más procesos. A la combinación del SGA y de los
procesos es lo que se llama instancia. La memoria y los procesos de una instancia
gestionan los datos de la base de datos asociada de forma eficiente y sirven a uno o
varios usuarios.

xv
                                                                                     Figura 2. Estructura de una
instancia de Oracle

La Instancia y la Base de Datos

Cuando se inicia una instancia Oracle monta la base de datos, es decir, asocia dicha
instancia a su base de datos correspondiente. En un mismo ordenador pueden
ejecutarse varias instancias simultáneamente, accediendo cada una a su propia base de
datos física.

Únicamente el administrador de la base de datos puede iniciar una instancia y abrir

una base de datos. Si una base de datos está abierta, entonces el administrador puede
cerrarla y, cuando esto ocurre, los usuarios no pueden acceder a la información que
contiene.

Estructura de Datos del SGA

Caché de los Buffers (Database Buffer Cache)

La caché de los buffers de la base de datos es una parte de la SGA que contiene
copias de los bloques de datos de lectura de las páginas. Todos los procesos de los
usuarios conectados concurrentemente a la instancia comparten el acceso a ella. Esta
caché junto con la caché compartida de SQL están lógicamente segmentadas en varios
conjuntos, lo que reduce la contención en sistemas multiprocesador.

Organización de la Caché de los Buffers

Los buffers en la caché están organizados en dos listas: la lista en espera y la lista

xvi
LRU. La lista en espera contiene los buffers en espera (dirty buffers), los cuales
contienen datos que han sido modificados pero que aún no se han escrito en disco. La
lista LRU contiene los buffers libres, buffers que están siendo accedidos actualmente
(pinned buffers) y los buffers en espera, que aún no están almacenados en la lista en
espera. Cuando un proceso Oracle accede a un buffer, este lo sitúa al final de la lista
LRU.

La primera vez que un proceso de usuario necesita un dato concreto, este los busca
en los datos almacenados en la caché de los buffers. Si el proceso encuentra el dato en
uno de estos buffers, se lee directamente de la memoria (cache hit). Si no lo encuentra,
entonces debe copiar la página en disco a un buffer de la caché antes de leerlo (cache
miss). Acceder a los datos a través de un ‘cache hit’ es más rápido que hacerlo
mediante un ‘cache miss’.

Antes de leer un bloque de datos dentro de la caché, el proceso debe encontrar

primero un buffer libre, empezando desde el menos usado recientemente de la lista
LRU. El proceso sigue buscando hasta que encuentra un buffer libre o hasta que llega al
final de la lista.

El Algoritmo LRU y la Lectura Completa de Tablas

Cuando un proceso de usuario realiza una exploración completa de la tabla, lee cada
bloque de la tabla en los buffers y los pone al final de la lista LRU. Se hace así porque
normalmente la exploración completa se necesita brevemente, por lo que los bloques
deben sacarse rápidamente para dejar espacio en la caché a los bloques que se usan
con mayor frecuencia.

Tamaño de la Caché de los buffer

Oracle soporta múltiples tamaños de bloque en una base de datos. El tamaño

estándar de bloque se especifica mediante la configuración del parámetro
DB_BLOCK_SIZE. Se admiten valores desde 2K hasta 32K.

Opcionalmente, también se puede seleccionar el tamaño de dos pool de buffer

adicionales, KEEP y RECYCLE, configurando DB_KEEP_CACHE_SIZE y
DB_RECYCLE_CACHE_SIZE. Estos tres parámetros son independientes entre sí.

Múltiples Pools de Buffer

Se puede configurar la cache del buffer con “buffer pools” distintos, en los que
cualquiera contiene datos, o están disponibles para nuevos datos tras usar los bloques

xvii
de datos. Objetos particulares del esquema (tablas, clusters, índices y particiones) se
asignan al buffer pool apropiado para controlar la forma en que los bloques de datos
“envejecen” en la cache.

         El
buffer pool KEEP conserva los bloques de datos de los objetos del
esquema en memoria.

         El
buffer pool RECYCLE elimina bloques de datos de la memoria tan
pronto como dejan de ser necesitados.

         El
buffer pool DEFAULT contiene bloques de datos de los objetos del
esquema que no son asignados a ningún buffer pool, así como los objetos del esquema
que son explícitamente asignados al pool DEFAULT.

Los parámetros que configuran los buffer pools KEEP y RECYCLE son
DB_KEEP_CACHE_SIZE y DB_RECYCLE_CACHE_SIZE.

Buffer del Registro del Rehacer (Redo Log Buffer)

El redo log buffer es un buffer circular en el SGA que contiene información sobre
cambios hechos a la base de datos, la cual se almacena en las ‘entradas redo’. Estas
entradas contienen la información necesaria para reconstruir, o rehacer cambios hechos
en la base de datos mediante las operaciones INSERT, UPDATE, DELETE, CREATE,
ALTER o DROP y se usan para la recuperación de la base de datos, si fuera necesario.

Las entradas se copian por los procesos desde el espacio de memoria del usuario al
redo log buffer en el SGA, ocupando continuamente espacio secuencial. El proceso en
segundo plano LGWR escribe el redo log buffer en el fichero redo log activo (o grupo de
ficheros) en disco.

El parámetro LOG_BUFFER determina el tamaño (en bytes) del redo log buffer.

El Pool Compartido

Es la parte del SGA que contiene la cache de biblioteca, la cache de diccionario, los
buffers para los mensajes de ejecución paralela y las estructuras de control.

El tamaño total del Pool Compartido se determina por el parámetro

SHARED_POOL_SIZE. El valor por defecto es de 8MB en plataformas de 32-bit, y de
64MB para plataformas de 64-bit. Incrementando su valor se incrementa la cantidad de
memoria reservada para el pool compartido.

xviii
 Caché de Biblioteca (Library Cache)

La cache de biblioteca incluye áreas de SQL compartidas, áreas SQL privadas (en
caso de una configuración de servidor compartido), procedimientos y paquetes PL/SQL,
y estructuras de control tales como bloqueos y el manejo de la cache de biblioteca.

Ya que las áreas de SQL compartidas son accesibles para todos los usuarios, la
caché de biblioteca está contenida en el Pool compartido dentro del SGA.

Áreas SQL Compartidas y Áreas SQL Privadas

Oracle representa cada declaración de SQL con un área SQL compartida y un área
SQL privada. Oracle reconoce cuando dos usuarios están ejecutando la misma
instrucción SQL y reutiliza el área SQL compartida para esos usuarios. Sin embargo,
cada usuario debe tener una copia separada de la declaración del área SQL privada.

Áreas SQL Compartidas

Un área SQL Compartida contiene el árbol de análisis y el plan de ejecución para una
instrucción SQL dada. Se ahorra memoria usando un solo área SQL compartida para
instrucciones SQL ejecutándose varias veces, lo cual ocurre con frecuencia cuando
varios usuarios ejecutan la misma aplicación.

Programas PL/SQL y el Pool Compartido

Oracle procesa programas PL/SQL (procedimientos, funciones, paquetes, bloques

anónimos, triggers) tanto como procesa instrucciones SQL individuales. Oracle asigna
un área compartida que contiene la forma analizada y compilada del programa. Asigna
un área privada para mantener los valores específicos de la sesión que ejecuta el
programa, incluyendo variables locales, globales y de paquete y buffers para ejecución
SQL. Si más de un usuario ejecuta el mismo programa, entonces una simple área
compartida es usada por todos los usuarios siempre que tenga una copia de su área
SQL privada, manteniendo valores específicos de su sesión.

Las instrucciones SQL individuales están contenidas en programas PL/SQL.

Large Pool

El administrador de la base de datos puede configurar un área de memoria opcional

llamado large pool que proporciona grandes cantidades de memoria para asignar:

         Memoria de la sesión para el servidor compartido y el Oracle XA interface

xix
 (usado donde las transacciones interactúan con más de una base de datos)

         Procesamiento de E/S

         Copias de seguridad y operaciones de recuperación

El large pool satisface mejor las peticiones de gran cantidad de memoria que el pool
compartido. Sin embargo, no posee una lista LRU.

Java Pool

La memoria java pool se usa en la memoria del servidor para almacenar todo el
código y datos del JVM en las sesiones. Se usa de diferentes formas, dependiendo del
modo en que se ejecute el servidor Oracle.

El asesor de estadísticas de java pool proporciona información sobre la memoria de la

cache de biblioteca usada para java y predice como pueden afectar cambios en el
tamaño del java pool en la tasa de análisis. El asesor de java pool se activa
internamente cuando el statistics_level está configurado en TYPICAL o mayor. Estas
estadísticas se reinician cuando el asesor es desactivado.

Streams Pool

En una única base de datos, se puede especificar que los flujos de memoria se
asignen desde un pool en el SGA llamado Streams pool. Para configurarlo se especifica
el tamaño del pool en bytes usando el parámetro STREAMS_POOL_SIZE. Si un
streams pool no está definido, entonces se crea automáticamente cuando los flujos se
usan por primera vez.

Si SGA_TARGET está activo, entonces la memoria del SGA para los Streams pool
viene del pool global del SGA. Si no está activo, entonces se transfiere desde la cache
del buffer, aunque solo tiene lugar después del primer uso de los flujos. La cantidad
transferida es del 10% del tamaño del pool compartido.

Caché de Diccionario (Dictionary Cache)

El diccionario de datos es una colección de tablas y vistas de la base de datos que

contienen información sobre la base de datos (sus estructuras y sus usuarios.

Oracle accede con frecuencia al diccionario de datos, por lo que tiene dos
localizaciones especiales en memoria designadas a mantenerlo. Una de ellas es la
caché del diccionario de datos, también conocida como la cache de fila porque contiene

xx
datos sobre las filas en vez de los buffers (los cuales contienen bloques de datos), y la
otra es el cache de biblioteca.

El Parámetro SGA_MAX_SIZE

El SGA comprende un número de componentes de memoria, denominados pools de

memoria, que se usan para satisfacer una clase particular de asignación de memoria.
Todos los componentes del SGA asignan y liberan espacio en unidades (módulos). El
tamaño del módulo queda determinado por el tamaño total del SGA. En la mayoría de
las plataformas el tamaño del módulo es 4MB si el tamaño total del SGA es menor de
1GB, y de 16MB para SGA mayores.

La base de datos puede configurar límites sobre cuanta memoria virtual se usa para
el SGA. Puede crear instancias con un mínimo de memoria y permitir que la instancia
use más, expandiendo la memoria asignada a los componentes del SGA, hasta un
máximo determinado por el SGA_MAX_SIZE. Si el valor es menor que la suma de
memoria asignada para todos los componentes, la base de datos ignora la configuración
de SGA_MAX_SIZE.

Para un rendimiento óptimo, en la mayoría de los sistemas, todo el SGA debería

ajustarse a la memoria real. Si no es así, y la memoria virtual es usada para almacenar
partes del SGA, entonces el rendimiento total del sistema puede decrementarse en gran
medida. La cantidad de memoria dedicada para todas las áreas compartidas en el SGA
también influye en el rendimiento.

El tamaño del SGA queda determinado por muchos parámetros, aunque son los
siguientes los que tienen un gran efecto sobre el tamaño del SGA:

Descripción
Parámetro

DB_CACHE_SIZE Tamaño de la cache de los bloques estándar.

LOG_BUFFER Número de bytes asignados al redo log buffer.

SHARED_POOL_SI Tamaño en bytes para el área dedicada al SQL

ZE compartido e instrucciones PL/SQL.

LARGE_POOL_SIZ Tamaño del large pool, por defecto es 0.

E

JAVA_POOL_SIZE Tamaño del java pool.

xxi
 Descripción
Parámetro

Gestión Automática de Memoria Compartida

En versiones anteriores el administrador de la base de datos tenía que especificar

manualmente los tamaños de los diferentes componentes del SGA configurando un
número de parámetros de inicialización, que incluían el SHARED_POOL_SIZE,
DB_CACHE_SIZE, JAVA_POOL_SIZE, y LARGE_POOL_SIZE. En la versión 10g se
incluye la gestión automática de la memoria compartida que simplifica la gestión de la
memoria del SGA. El administrador de la BD puede simplemente especificar la cantidad
total de memoria del SGA disponible para una instancia usando SGA_TARGET y la base
de datos automáticamente distribuirá esta memoria entre varios subcomponentes para
asegurar el mayor uso de memoria efectiva.

Cuando la gestión automática de memoria del SGA esta activada, el tamaño de los
diferentes componentes del SGA es flexible y pueden adaptarse a las necesidades del
trabajo sin requerir ninguna configuración adicional. La base de datos automáticamente
distribuye la memoria disponible entre varios componentes como se requiera,
permitiendo al sistema maximizar el uso de toda la memoria del SGA disponible.

Configurando un único parámetro se simplifica mucho la tarea de administración ya

que puedes especificar solo la cantidad de memoria del SGA que una instancia tiene
disponible y olvidarte de los tamaños de los componentes individuales. No se generan
errores de “out of memory” a menos que el sistema se haya quedado sin memoria.

La gestión automática del SGA puede mejorar el rendimiento sin necesidad de

recursos adicionales ni ajustes manuales. Con la configuración manual del SGA es
posible que instrucciones SQL compiladas se saquen del pool compartido debido a su
insuficiente tamaño lo que incrementa la frecuencia de análisis difíciles, que reducen el
rendimiento. Cuando la gestión automática del SGA esta activa, el algoritmo de ajuste
interno supervisa el rendimiento del trabajo, incrementando el tamaño del pool
compartido si reduce el número de análisis requeridos.

El Parámetro SGA_TARGET

El parámetro SGA_TARGET refleja el tamaño total del SGA e incluye la memoria para
los siguientes componentes:

xxii
          SGA Fija y otras asignaciones internas necesarias para la instancia.

         El log buffer

         El pool compartido

         El Java pool

         La caché del buffer

         Las cachés de los buffers keep y recycle (si son especificados)

         El tamaño de los bloques no estándar de las cachés de los buffer (si
son especificados)

         El Streams pool

Este incluye toda la memoria del SGA, en diferencia con las versiones anteriores en
las que la memoria para la SGA interna y fija se configuraba a través de otros
parámetros. En consecuencia, el SGA_TARGET da un control preciso sobre el tamaño
de la región de memoria compartida asignada por la base de datos. Si está configurado
con un valor mayor que SGA_MAX_SIZE al inicio, entonces este último se usa como
respaldo para el SGA_TARGET.

Nota: No configurar dinámicamente el SGA_TARGET. Debería ser configurado solo

al inicio.

Limitando el Tamaño de la SGA

El parámetro SGA_MAX_SIZE especifica el tamaño máximo del SGA durante la

duración de la instancia. Puedes modificar dinámicamente los parámetros que afectan al
tamaño de las caches de los buffers, del pool compartido, large pool, java pool, y
streams pool pero solo para controlar que la suma de estos tamaños y los tamaños de
los otros componentes del SGA no exceden el valor especificado por SGA_MAX_SIZE.

2.1.2 Estructuras Físicas de la Base de Datos

Áreas Globales de Programas PGA (Program Global Areas)

Un área global de programa (PGA) es una región de memoria que contiene datos e
información de control para los procesos de servidores. Es una memoria no compartida
creada por Oracle cuando un proceso de un servidor es iniciado. Solo el servidor del

xxiii
proceso puede acceder a él y se lee y escribe solamente por un código de Oracle que
actúa en nombre del proceso.

Contenido de un PGA

El contenido de la memoria de un PGA varía dependiendo de dónde se está

ejecutando la instancia y de si el tipo de servidor es compartido. Pero generalmente la
memoria del PGA puede ser clasificada de la siguiente forma:

Memoria de Sesión: La memoria de sesión (Session Memory) se asigna para

mantener las variables de una sesión (logon information) y otra información relativa a la
sesión. Para un servidor compartido, la memoria de sesión es compartida y no privada.

Área SQL Privada: Un área SQL privada contiene datos como por ejemplo consultas
de información de ejecuciones y consultas de ejecuciones en áreas de trabajo. Cada
sesión que establece una sentencia tiene un área privada de SQL. Cada usuario que
emite la misma sentencia tiene su propia área SQL privada que usa un área SQL
compartida. Aunque, muchas áreas SQL privadas pueden ser asociadas con la misma
área SQL compartida.

La ubicación de un área privada SQL depende del tipo de conexión establecida para
una sesión. Si una sesión se conecta a través de un servidor dedicado, las áreas
privadas SQL esta localizadas en el servidor del proceso del PGA. De cualquier forma, si
una sesión se conecta a través de un servidor compartido, parte del área privada SQL se
mantiene en el SGA.

Cursores y Áreas SQL

La aplicación de desarrollo de un programa precompilador Oracle o un programa OCI

puede explícitamente abrir cursores, o manejar algún área privada SQL específica, y
usarla como un recurso nombrado a través de la ejecución de un programa. Los
cursores recursivos de Oracle que emiten implícitamente algunas sentencias SQL
también usan áreas SQL.

La administración de las áreas SQL privadas son responsabilidad de los procesos del
usuario. La asignación y liberación de las áreas SQL privadas dependen de en qué
herramienta de la aplicación se usan, aunque el número de áreas SQL privadas que un
proceso de usuario puede asignar está siempre limitado el parámetro
OPEN_CURSORS. El valor por defecto de este parámetro es 50.

Un área SQL privada continua existiendo hasta que el correspondiente cursor es

xxiv
cerrado o la sentencia es liberada. Aunque Oracle libera el área de ejecución después
de que la sentencia se complete, el área persistente se mantiene en espera. Las
aplicaciones de desarrollo cierran todos los cursores abiertos que no van a ser usados
otra vez para liberar el área persistente y minimizar la cantidad de memoria requerida
por el usuario de la aplicación.

Componentes del Área SQL Privada

El área SQL privada de un cursor se divide en 2 áreas cuya duración son diferentes:

         El
área persistente (Persistent Area), que contiene, por ejemplo, información
envuelta. Es liberada solamente cuando el cursor es cerrado.

         El
área de ejecución (Run-time Area), que es liberada cuando la
ejecución, valga la redundancia, es terminada.

Oracle crea el área de ejecución en el primer paso que una ejecución es pedida. Para
una sentencia INSERT, UPDATE y DELETE Oracle libera el área de ejecución después
de que la sentencia ha sido ejecutada. Para las consultas, Oracle libera el área de
ejecución solamente cuando todas las filas han sido recorridas, o la consulta ha sido
cancelada.

Áreas de Trabajo SQL

Para las consultas complejas, una gran porción del área de ejecución es dedicada a
áreas de trabajo asignadas por operadores de memoria-intensiva como los siguientes:

         Operadores de base de clasificación “Sort-based” (order by, group by, rollup)

         Hash-join

         Bitmap merge

         Bitmap create

Por ejemplo, un operador de clasificación (sort operator) usa un área de trabajo

(algunas veces llamado área de clasificación “sort area”) para la forma de distribución de
la memoria interna (in-memory) de una serie de filas. Similarmente, un operador hash-
join usa un área de trabajo (también llamada área hash) para construir una tabla hash
desde su entrada izquierda. Si la cantidad de datos que deben ser procesados por estos
dos operadores no entran en el área de trabajo, entonces los datos de entrada son
divididos en piezas más pequeñas. Esto permite que alguna de las piezas se procesen

xxv
en la memoria mientras el resto son distribuidos en un disco temporal para ser
procesado luego. Aunque los operadores de bitmap no se distribuyen por el disco
cuando su área de trabajo es muy pequeña, su complejidad es inversamente
proporcional al tamaño de su área de trabajo. Estos operadores se ejecutan más rápido
en áreas de trabajo más grandes.

El tamaño del área de trabajo puede ser controlado y modificado. Generalmente,

áreas de bases de datos grandes pueden mejorar significativamente el rendimiento de
un operador respecto al coste de consumo de memoria. Opcionalmente, el tamaño de un
área de trabajo puede ser lo bastante grande como para almacenar los datos de
entradas y las estructuras auxiliares de memoria asignadas por el operador SQL
asociado. De lo contrario, el tiempo de respuesta aumenta, porque parte de los datos de
entrada deben ser distribuidos por un disco de almacenamiento temporal. En caso
extremo, si el tamaño del área de trabajo es muy pequeño comparado con el tamaño del
dato de entrada, múltiples procesos se ejecutan sobre la parte de los datos. Esto puede
aumentar el tiempo de respuesta de un operador considerablemente.

Administración de la Memoria del PGA para un Modo Dedicado

Se puede administrar el tamaño de las áreas de trabajo SQL globalmente y

automáticamente. El administrador de la base de datos simplemente necesita que sea
especificado el tamaño total dedicado a la memoria del PGA para las instancias de
configurando el parámetro PGA_AGGREGATE_TARGET. El número especificado (por
ejemplo 2G) es un objetivo global para la instancia, y se trata de asegurar que la
cantidad total de memoria del PGA asignada por toda la base de datos de los procesos
del servidor nunca exceda esa meta.

Con PGA_AGGREGATE_TARGET, modificar el tamaño de las áreas de trabajo para

todas las sesiones dedicadas es automático, y todos los parámetros *_AREA_SIZE se
ignoran en estas sesiones.

Área de Ordenaciones (Sort Areas)

Las áreas de ordenaciones (Sort Areas) de Oracle son las zonas de memoria en las
que se ordenan los datos, es decir el espacio en memoria que necesita la organización y
ordenación de las filas.

El tamaño por defecto, expresado en bytes, es específico de cada SO. Sin embargo,
hay muchas razones importantes por las que este tamaño influye en el rendimiento. En
el manual de Oracle 10i encontramos cuatro de ellas:

xxvi
         Aumentar el SORT_AREA_SIZE mejora la eficiencia de
ordenaciones grandes.

 Cada ordenación en una consulta puede consumir la cantidad de

 

memoria especificada en el SORT_AREA_SIZE, y pueden haber múltiples ordenaciones

en una consulta. De esta forma, si otra consulta se ejecuta en paralelo, cada ordenación
puede consumir la memoria especificada en este campo.

 El
  SORT_AREA_SIZE también se utiliza para selecciones y
actualizaciones en los índices de las tablas. Seleccionar un valor apropiado aquí, puede
dar como resultado que la tabla se actualice una única vez en cada operación DML,
pudiendo incluso haber cambiado varias filas a la vez.

      Grandes
valores en este campo nos permitirán realizar mayores
búsquedas en memoria. Si se necesitase más espacio para la ordenación del que
tenemos, los datos se dividirán en trozos y se utilizarán segmentos de disco temporales
como apoyo en la ordenación.

En éste último caso, en el que los datos a ordenar no quepan en el área de

ordenaciones, se dividen en trozos que sí quepan, se ordenan y se mezclan (merge). A
esto hace referencia también el manual de Oracle9i, que si bien lo hace en trozos
separados, a continuación se muestran las dos referencias juntas:

         Para
un mejor rendimiento del SGBD, la mayoría de las ordenaciones
deberían tener lugar únicamente en memoria ya que en caso de tener que escribir a
disco, obtendremos un claro efecto adverso sobre éste. Si las aplicaciones que acceden
a la base de datos suelen realizar búsquedas que no caben en el área de ordenaciones,
o incluso si las aplicaciones realizan demasiadas búsquedas innecesarias, entonces
sería conveniente modificar el parámetro de SORT_AREA SIZE.

  El SORT_AREA_SIZE es un parámetro que se puede inicializar y

      

modificar dinámicamente y que especifica la cantidad de memoria que se tiene

disponible al realizar las ordenaciones. Si una cantidad importante de ordenaciones
requiere acceso a disco para almacenar segmentos temporales, entonces la aplicación
se verá claramente beneficiada al ampliar el SORT_AREA_SIZE. De forma alternativa,
en un entorno DSS, aumentar este parámetro no tiene por qué hacer que la ordenación
se realice únicamente en memoria, pero sí es cierto que dependiendo del valor actual y
del nuevo elegido, se puede aumentar drásticamente la velocidad de la ordenación.

Por lo tanto, como conclusión, alterar este parámetro, se puede considerar como un
paso importante para asegurarnos el rendimiento en ciertas circunstancias y situaciones.

xxvii
Sin embargo, determinar qué valor es el más apropiado, es por supuesto, la parte más
complicada.

Memoria Virtual en Oracle

Oracle puede utilizar la memoria virtual proporcionada por el SO para simular

memoria a base de algún dispositivo de almacenamiento como el disco duro.

La memoria virtual está mapeada en la RAM. Cuando no hay suficiente memoria con
ésta para ejecutar los programas (en caso de Oracle las sentencias, búsquedas, etc) se
necesita un espacio auxiliar que normalmente suele ser el disco duro. Para el traspaso
de información se utilizan dos técnicas principales: el Paging o paginación y el
Swapping.

Paginación

La paginación consiste en dividir los programas en pequeños bloques o páginas, de

manera que sea más fácil moverlos de memoria a disco y viceversa. De la misma forma,
la memoria se divide en marcos de página. De esta forma, la cantidad de memoria
desperdiciada por un proceso es el final de su última página, minimizando así la
fragmentación interna y evitando la externa.

En un momento cualquiera, la memoria se encuentra ocupada con páginas de

diferentes procesos, mientras que algunos marcos están disponibles para su uso. El
sistema operativo mantiene una lista de estos últimos marcos, y una tabla por cada
proceso, donde consta en qué marco se encuentra cada página del proceso. De esta
forma, las páginas de un proceso pueden no estar contiguamente ubicadas en memoria,
y pueden intercalarse con las páginas de otros procesos.

En la tabla de páginas de un proceso, se encuentra la ubicación del marco que

contiene a cada una de sus páginas. Las direcciones lógicas ahora se forman como un
número de página y de un desplazamiento dentro de esa página (conocido comúnmente
como offset). El número de página es usado como un índice dentro de la tabla de
páginas, y una vez obtenida la dirección del marco de memoria, se utiliza el
desplazamiento para componer la dirección real o dirección física. Este proceso se
realiza en una parte del ordenador específicamente diseñada para esta tarea, es decir,
es un proceso hardware y no software.

De esta forma, cuando un proceso es cargado en memoria, se cargan todas sus

páginas en marcos libres y se completa su tabla de páginas.

xxviii
 Swapping

El Swapping es el procedimiento de mover los bloques de memoria en los que están

algunos procesos que no se están utilizando, desde la memoria principal a un espacio
Swap dejando así hueco libre para poder cargar en memoria otros procesos que sí se
van a utilizar.

El espacio Swap o espacio de intercambio es una zona de disco (un fichero o una
partición) que se usa para guardar las imágenes de los procesos que no han de
mantenerse en memoria física.

Este procedimiento es muy similar a la paginación, con la diferencia principal de que

el directorio Swap funciona exactamente igual que la memoria RAM, por lo que puede
almacenar datos privados, contraseñas y todo lo que almacena ésta. Sin embargo, en la
paginación, únicamente se sacan de memoria páginas pertenecientes a procesos que no
se estén utilizando, además de que se pueden sacar solo algunas páginas de los
procesos y no éstos enteros como se hace en el Swapping.

Con respecto al tamaño que debe tener el directorio Swap, hay muchas discusiones
sobre ello como por ejemplo la antigua creencia de “El Swap debe tener el doble de
tamaño que la RAM.” cosa que no es válida hoy día debido a la gran capacidad de la
memoria RAM de la mayoría de ordenadores.

Como conclusión, hay que destacar que el uso de la memoria virtual por parte de
Oracle, va a influir bastante en el rendimiento, disminuyéndolo drásticamente en
comparación con el uso únicamente de la memoria RAM.

Área de Código de Software (Sca)

El área de código de software son zonas de memoria destinadas a almacenar el

código de Oracle en ejecución o que puede ejecutarse. Este código de Oracle se
almacena en una zona distinta, y más protegida, que las zonas dedicadas a almacenar
los códigos de programas de usuarios.

La SCA suele ser de tamaño estático, cambiando únicamente cuando el software se

reinstala o actualiza. El tamaño requerido para este área puede variar en función del SO.
Son áreas de sólo lectura y pueden ser instalas de forma compartida o no compartida.
Cuando es posible, el código de Oracle se comparte, por lo que todos los usuarios
pueden acceder a él sin tener múltiples copias en memoria. El resultado es un ahorro
considerable de memoria y una mejora del rendimiento general.

xxix
 Por otra parte, los programas de usuario también pueden ser compartidos o no.
Algunas utilidades y herramientas de Oracle (como ocurre con Oracle Forms y
SQL*Plus) pueden ser instalados de forma compartida, pero otras no. Múltiples
instancias de Oracle pueden usar la misma SCA con diferentes bases de datos si están
corriendo en la misma máquina.

Hay que tener en cuenta que la opción de instalar software compartido puede no estar
disponible en función del sistema operativo, como ocurre por ejemplo en máquinas con
Windows.

Estructura de los Procesos

Cuando un usuario se conecta a una base de datos de Oracle ejecuta dos módulos
de código diferentes, que además el encargado de gestionar estos procesos es el
sistema operativo, estos dos módulos diferentes son:

         Aplicación o Herramienta Oracle: normalmente son programas clientes

que se conectan a la base de datos y permiten ejecutar sentencias SQL. Ej.: SQL*Plus,
SQL developer

         Código del Servidor de Oracle: son los diferentes procesos que se han
de ejecutar en el servidor para atender las peticiones del usuario.

La base de datos Oracle es un sistema multiproceso, lo que significa que no toda la

base de datos está corriendo en un mismo proceso, si no que varias partes de la base
de datos se ejecuta concurrentemente. Permitiendo a múltiples usuarios conectarse a la
misma vez, y mayor rapidez en el tiempo de respuesta, puesto que siempre que pueda
va a utilizar al máximo al ordenador, por ejemplo si tiene ocho núcleos el servidor, y
resulta que una petición se puede paralelizar se ejecutara esa petición por partes en
cada núcleo.

De los procesos que se ejecutan en el servidor podemos hacer dos grandes grupos:

Procesos de Usuarios: Cada vez que un usuario ejecuta una aplicación, ya sea
propia o de Oracle se crea un proceso, que puede ser de dos tipos.

         Conexión: Que es la vía de comunicación entre la aplicación y la instancia

de la base de datos a la que se ha conectado.

         Sesión: Es la conexión específica con la base de datos proporcionando un

usuario y su contraseña.

xxx
 Esto permite que desde un mismo equipo se puedan conectar varios usuarios
simultáneamente, y que un usuario se pueda conectar desde diferentes equipos
simultáneamente.

Procesos de Oracle: Son propios de la base de datos, y el usuario no tiene control

sobre ellos, pueden ser de dos tipos:

 Procesos de Servidor: Se crea cuando una aplicación intenta acceder a la

base de datos, para atender a las peticiones de la aplicación y devolver los resultados
que se precisen.

 Procesos de Background: Se crean cuando se inicia una instancia de la base

de datos, solo hay un proceso de cada tipo de los que especificaremos a continuación, y
no han de estar todos siempre presentes en el servidor. Se utilizan para realizar labores
de mantenimiento, y para guardar la integridad de la base de datos. Los diferentes tipos
de procesos son los siguientes: 

Database Writer Process (DBWn)

El (DBWn) escribe el contenido de los buffers en los archivos de datos. El proceso

DBWn es responsable por la escritura de los buffers modificados del buffer cache al
disco. El proceso DBWn escribe buffers modificados al disco bajo las siguientes
condiciones:

Cuando un proceso no puede encontrar un buffer limpio reusable después de haber

recorrido un número de determinado de buffers en el buffer caché, éste envía una señal
al DBWn para la escritura. El DBWn escribe los buffers sucios al disco.

El DBWn periódicamente escribe los buffers cuando se lleva a cabo un checkpoint.

Chekpoint es una posición en el hilo de redo (log) donde se iniciará luego la
recuperación. La posición en el log está determinada por el último buffer sucio en el
buffer caché.

Log Writer Process (LGWR)

El proceso LGWR es responsable del manejo del redo log buffer, las escrituras del
redo log buffer al archivo de redo log en el disco. El LGWR escribe todos los registros de
redo que han sido copiados en el buffer desde la última vez que éste se escribió. El redo
log buffer es un buffer circular. Cuando LGWR escribe los registros del redo log buffer al
redo log file, el proceso servidor puede copiar nuevos registros sobre aquellos que se
pasaron a disco. LGWR normalmente escribe lo suficientemente rápido para asegurar

xxxi
que el espacio esté siempre disponible en el buffer para nuevos registros, aun cuando la
escritura al redo log file sea lenta.

LGWR escribe en porciones contiguas del buffer al disco. El LGRW escribe:

         Un registro de commit cuando un usuario hace commit de una transacción

Redo log buffers:

         Cada tres segundos

         Cuando el redo log tenga un tercio lleno

         Cuando un proceso de DBWn escriba los buffers modificados a disco, si es

necesario.

Cuando un usuario lleva a cabo una instrucción de commit, el LGWR coloca el

registro de commit en el log buffer y escribe la transacción a disco inmediatamente en el
redo log. Los cambios correspondientes a los bloques de datos en el buffer caché, son
dejados hasta que se tenga una escritura más eficiente que hacer. Esto se denomina el
mecanismo de fast commit. La escritura de un registro de redo del commit de la
transacción es un evento atómico.

Existe un mito con respecto a la escritura en el redo log buffer, se dice que en el redo
log buffer o redo log file aparecerán sólo las transacciones comprometidas. En el redo
log file se escriben todas las transacciones, no sólo las comprometidas, es por ello que
el redo log permite rehacer los segmentos de undo del cualquier punto en el tiempo
cuando se hace recuperación incompleta (point in time recovery).

Redo Log Files

Los Redo Log Files se agrupan en grupos de Redo Log. Todos los miembros de un
Redo Log Group son idénticos, es decir contendrán la misma información. Dentro de un
grupo de Redo Log se "multiplexan" los archivos para evitar los puntos de fallas, es decir
si se perdiera un archivo de Redo Log habría otro que contendría la información y que
permitiera la recuperación de la base de datos.

Los redo log se utilizan de forma circular, mediante grupos de archivos. Por defecto la
base de datos Oracle genera 3 grupos de archivos. Se considerará el grupo current
(actual) aquel donde se esté utilizando para escribir las transacciones actuales de la
base de datos. Se considera un grupo active (activo), aquel que no es el actual y que
posea transacciones cuyos cambios no se han hecho permanentes en los archivos de

xxxii
datos e inactivo aquel que contenga transacciones que han sido completamente escritas
a disco, finalmente también se puede tener que un grupo de redo log esté limpio porque
nunca haya sido escrito.

Los archivos de redo log trabajan de forma circular porque se sobrescriben,

generalmente con los tres grupos se tendrá que uno de ellos se encontrará activo, el
siguiente en enumeración será el actual y el siguiente estará inactivo listo para que se
escriba en él. Una vez llenado el grupo actual se comenzará a escribir en el inactivo, que
ahora será el actual, el que anteriormente era el actual pasará a ser activo si aún no se
han escrito todas sus transacciones a disco y eventualmente el que inicialmente estaba
activo pasará a ser inactivo y permitirá que al llenarse el grupo actual se escriban las
transacciones en él.

Si se llenara el grupo actual de los archivos de redo y el resto de los grupos se

encontraran activos, la base de datos no permitiría ninguna transacción hasta que se
escriban todas las transacciones a disco del siguiente grupo de redo log y que este
quedase inactivo. Cuando se trabaja con una base de datos en modo ARCHIVELOG,
antes de sobrescribir el archivo se hace una copia de ese grupo de redo log al destino
de los archivos.

Checkpoint Process (CKPT)

El CKPT lleva a cabo un checkpoint, entendiéndose como tal a la escritura parcial o

completa de los buffers de memoria a disco. El CKPT no es el responsable de escribir
los bloques a disco, para ello llama al DBWn y como en esa escritura podrían
almacenarse en disco buffers de transacciones no comprometidas el CKPT también
llama al LGWR para que registre en los redo log files esta escritura que permita generar
los segmentos de undo de transacciones no comprometidas cuando se realice una
recuperación incompleta. También si en la escritura del checkpoint hay transacciones
que no se habían terminado de escribir en disco se escriben, se actualiza la cola de
transacciones activas y un grupo de redo log que estaba activo podría pasar a inactivo.

Cuando un checkpoint ocurre, Oracle debe actualizar todas las cabeceras de los
archivos de datos con los detalles del checkpoint, ésta es una tarea del CKPT.

System Monitor Process (SMON)

El proceso SMON lleva a cabo la recuperación, si es necesaria, de la instancia en el

inicio de la misma, es decir rehacer cualquier transacción comprometida en el redo log
file que no haya sido escrita a disco. SMON también es responsable de limpiar los
segmentos temporales que no estén en uso por algún tiempo y de desfragmentar si cree

xxxiii
oportuno alguna zona de los discos.

Process Monitor (PMON)

PMON lleva a cabo procesos de recuperación cuando un proceso de usuario falla. Es

responsable de la limpieza del buffer caché, también de deshacer los cambios que se
hayan hecho desde el ultimo commit y de la liberación de recursos que el proceso
estaba usando. Por ejemplo este restaura el status de la tabla de transacciones activas,
libera los locks y remueve el ID del proceso de la lista de procesos activos, asociados a
un proceso usuario que pudo haber perdido la conexión de red.

Recoverer (RECO)

Este proceso solo se observa cuando la base de datos ejecuta la opción distribuida de
Oracle. La transacción distribuida es una en la que dos o más emplazamientos de datos
deben mantenerse sincronizados, Por ejemplo cuando se tiene una copia de los datos
en diferentes ciudades y por fallas en una línea telefónica se pierde una transacción en
la mitad de su actualización. El proceso recuperador entonces resuelve las
transacciones que hayan quedado inconsistentes en las dos ciudades.

Archiver Processes (ARCn)

El ARCn copia los archivos de redo log llenos a un espacio de almacenamiento

distinto para no perderlos al ser sobreescritos. El ARCn sólo está habilitado cuando la
base de datos está en el modo ARCHIVELOG. En Oracle 10g para colocar la base de
datos en modo archive basta con colocarla en modo ARCHIVELOG y especificar los
destinos de "archive". En Oracle 9i se distinguía entre el "archive" manual y automático.
Con "archive" manual el DBA debía ordenar hacer la copia de los redo log a los
"archives", en el modo automático se copiaban automáticamente antes de ser
sobrescritos. En Oracle 10g al poner una base de datos en modo ARCHIVELOG
automáticamente se coloca en el modo automático.

Lock (LCKn)

Es un proceso opcional, configurado para manejar los bloqueos entre bases de datos
Oracle cuando estas se encuentran en distintos computadores y compartiendo el mismo
conjunto de discos (es decir en modo servidor en paralelo).

Job Queue (SNPn)

Es un proceso opcional, que se encarga de planificar los procesos que se deben

xxxiv
ejecutar y asegurar que todos deben de terminar en algún momento.

Queue Monitor (QMNn)

QMNn es un proceso opcional de background para el encolamiento avanzado de

Oracle, que monitorea las colas de mensajes. El encolamiento avanzado se usa con
comunicación asíncrona. Los procesos envían los mensajes y en lugar de esperar por la
respuesta siguen con su trabajo.

Dispatcher (Dnnn)

Es un proceso opcional que permite a los usuarios compartir procesos de servidor.

Permitiendo que se conecten múltiples usuarios al mismo servidor.

Shared Server (Snnn)

Este tipo de proceso se encarga de atender a cada uno de los clientes conectados a
la base de datos compartiendo los procesos del servidor.

2.1.3 Requerimientos para Instalación de la Base de Datos

Antes de instalar cualquier SGBD es necesario conocer los requerimientos de

hardware y software, el posible software a desinstalar previamente, verificar el registro
de Windows y el entorno del sistema, así como otras características de configuración
especializadas como pueden ser la reconfiguración de los servicios TCP/IP y la
modificación de los tipos archivos HTML para los diversos navegadores.

Se presenta a continuación una serie de requerimientos mínimos de hardware y

software para instalar oracle 11g Express y MySQL estándar versión 5.1. En Windows
Seven y Ubuntu 10.

Oracle MySQL
Requerimiento
RAM 512 512
MB MB

Memoria virtual 1024 1024

MB MB

Espacio disco duro 1.5 GB 1 GB

xxxv
 Oracle MySQL
Requerimiento
Tamaño máximo de la base de datos 4 GB Sin
limite

Sistema Operativo: Windows Server, Windows Seven, Linux,     

Unix

Arquitectura del Sistema 32/64-bit    

Protocolo de red TCP/IP

Protocolo de red TCP/IP con SSL  

La regla general para determinar el tamaño de la memoria virtual depende del tamaño
de memoria RAM instalada. Si su sistema tiene menos de 4 GB de RAM por lo general
el espacio de intercambio debe ser de al menos dos veces este tamaño. Si usted tiene
más de 8 GB de memoria RAM instalada puede considerar usar el mismo tamaño como
espacio de intercambio. Cuanta más memoria RAM tenga instalada, es menos probable
usar el espacio de intercambio, a menos que tenga un proceso inadecuado.

2.1.4 Instalación del Software de Base de Datos en ModoTransaccional

Debido al constante crecimiento de datos que generan las empresas hoy en día, se
ha vuelto muy necesaria la búsqueda de nuevas plataformas para almacenar y analizar
la información, ambientes que consuman menos recursos, que sean más escalables y
que provean una alta disponibilidad. La solución consiste en el procesamiento paralelo
de los datos de una base de datos.

Una base de datos en modo transaccional significa que la BD será capaz de que las
operaciones de inserción y actualización se hagan dentro de una transacción, es un
componente que procesa información descomponiéndola de forma unitaria en
operaciones indivisibles, llamadas transacciones, esto quiere decir que todas las
operaciones se realizan o no, si sucede algún error en la operación se omite todo el
proceso de modificación de la base de datos, si no sucede ningún error se hacen toda la
operación con éxito.

Una transacción es un conjunto de líneas de un programa que llevan insert o update o

delete. Todo aquél software que tiene un log de transacciones (que es la "bitácora" que
permite hacer operaciones de commit o rollback), propiamente es un software de BD;
aquél que no lo tiene (v.g. D-Base), propiamente no lo es. Todo software de base de

xxxvi
datos es transaccional; si el software de la BD no es "transaccional", en realidad NO es
un "software" de BD; en todo caso, es un software que emula el funcionamiento de un
verdadero software de BD. Cada transacción debe finalizar de forma correcta o
incorrecta como una unidad completa. No puede acabar en un estado intermedio.

Se usan los siguientes métodos:

         Begin TRans para iniciar la transacción

         CommitTrans para efectuar los cambios con éxito

         RollbackTrans para deshacer los cambios

Y depende que base de datos uses para efectuar las operaciones pero, es la misma
teoría para cualquier BD.

Instalación de MySQl en Windows 7

1.    Comprobar que no existe una versión anterior, si existe desinstalarla.

2.    Descargar el archivo de instalación, en nuestro caso MySQL Enterprise.

3.    Ejecute el archivo:

xxxvii
4.    Procesa a instalar en el modo por defecto. Es necesario tener conexión a
Internet

5.    Configure el servidor según sus necesidades

xxxviii
6.    Es este punto se configura como se comportará nuestro servidor y el servicio.
Además se descargan e instalan los paquetes necesarios.

xxxix
 7.    Ahora proceda a configurar MySQL Workbench; es una herramienta visual de
diseño de bases de datos que integra desarrollo de software, administración de
bases de datos, diseño de bases de datos, creación y mantenimiento para el
sistema de base de datos MySQL. Es el sucesor de DBDesigner 4 de
fabFORCE.net, y reemplaza el anterior conjunto de software, MySQL GUI Tools
Bundle.

En MySQL 5.x se soporta por defecto el modo transaccional mediante el motor

InnoDB

Dos recursos basados en disco muy importantes que gestiona el motor de

almacenamiento InnoDB son sus archivos de datos de espacios de tablas y sus archivos
de registro (log).

Si no se especifican opciones de configuración para InnoDB, MySQL 5.0 crea en el

directorio de datos de MySQL un archivo de datos de 10MB (autoextensible) llamado
ibdata1 y dos archivos de registro (log) de 5MB llamados ib_logfile0 e ib_logfile1.

2.1.5 Variables de Ambiente y Archivos Importantes para Instalación

Variable: Es un espacio en memoria al cual se le da un nombre Hay variables

xl
específicas que se crean al momento de entrar al sistema, pero también hay variables
que pueden ser definidas por el usuario. Las variables son una forma de pasar
información a los programas al momento de ejecutarlos.

Variables de Ambiente: Se usan para personalizar el entorno en el que se ejecutan

los programas y para ejecutar en forma correcta los comandos del shell.

Toman su valor inicial generalmente de un archivo .profile, pero hay veces en que el
usuario tiene que modificar los valores de alguna variable de ambiente cuando está
tratando de instalar o ejecutar un nuevo programa

A continuación se comentan las opciones más utilizadas de la sección mysqld

(afectan al funcionamiento del servidor MySQL), se almacenan en el archivo my.cnf (o
my.ini)

basedir = ruta: Ruta a la raíz MySQL

console: Muestra los errores por consola independientemente de lo que se configure

para log_error.

datadir = ruta: Ruta al directorio de datos.

default-table-type = tipo: Tipo de la Tabla InnoDB o, MyISAM.

flush: Graba en disco todos los comandos SQL que se ejecuten (modo de trabajo, sin
transacción).

general-log = valor: Con valor uno, permite que funcione el archivo LOG para
almacenar las consultas realizadas.

general-log-file = ruta: Indica la ruta al registro general de consultas.

language: Especifica el idioma de los lenguajes de error, normalmente esots archivos

de lenguaje, están bajo /usr/local/share.

log-error = ruta: Permite indicar la ruta al registro de errores.

log = ruta: Indica la ruta al registro de consultas.

long-query-time = n: Segundos a partir de los cuales una consulta que tardes más,
se considerará una consulta lenta.

xli
 og-bin = ruta: Permite indicar la ruta al registro binario.

pid-file = ruta: Ruta al archivo que almacena el identificador de proceso de MySQL.

port = puerto: Puerto de escucha de MySQL.

skip-grant-tables: Entra al servidor saltándose las tablas de permisos, es decir todo

el mundo tiene privilegios absolutos.

skip-networking: El acceso a MySQL se hará solo desde el servidor local.

slow-query-log = 0|1: Indica si se hace LOG de las consultas lentas.

slow-query-log-file = ruta: Ruta al archivo que hace LOG de las consultas lentas.

socket = ruta: Archivo o nombre de socket a usar en las conexiones locales.

standalone: Para Windows, hace que el servidor no pase a ser un servicio.

user = usuario: Indica el nombre de usuario con el que se iniciará sesión en MySQL.

tmpdir = ruta: Ruta al directorio para archivos temporales.

Archivos LOG en MySQL

Hay cuatro registros (logs):

Registro de Errores (Error Log): Indica cuando arrancó y se detuvo el servidor. Se

graba por defecto en la carpeta de datos de MySQL (archivo host_name.err, donde
host_name es el nombre del servidor), pero la variable de sistema log_error permite
indicar otra ruta si fuera necesario.

Registro General de Consultas (General Log File): Está en la carpeta de datos de

MySQL, salvo que se indique la variable general-log-file. Contiene las consultas
realizadas. Es el archivo host_name.log.

Registro Binario (Binary Log): Registra instrucciones DML. Los archivos binarios se

almacenan por defecto en el directorio de datos. Sirve para intentar restaurar una base
de datos en caso de desastre. Es binario, por lo que su manejo es complicado, para ver
el contenido se usa la utilidad mysqlbinlog de esta forma: mysqlbinlog archivoLOG

Registro de Consultas Lentas (Slow Query Log File): Registra las consultas que

xlii
tardaron más del tiempo mínimo establecido. El archivo está (salvo quese especifique
slow-log-file como parámetro) en la carpeta de datos de MySQL con el nombre
host_name-slow.log

2.1.6 Procedimiento General de Instalación de un DBMS

MySQL Enterprise Edition

MySQL Enterprise Edition incluye el conjunto más completo de características

avanzadas y herramientas de gestión para alcanzar los más altos niveles de
escalabilidad, seguridad, fiabilidad y tiempo de actividad. Reduce el riesgo, costo y
complejidad en el desarrollo, implementación y administración de aplicaciones críticas de
negocio MySQL.

El MySQL Enterprise incluye las siguientes opciones:

Backup: Realiza copias de seguridad de bases de datos MySQL en línea, de los

subconjuntos de tablas InnoDB, y la recuperación mediante puntos de restauración.

Alta Disponibilidad: es proporcionada con soluciones certificadas que incluyen

replicación de MySQL.

Escalabilidad: permite alcanzar el rendimiento sostenido y la escalabilidad de cada

vez mayor de usuarios, consulta, y las cargas de datos

MySQL Enterprise Security: Proporciona listas para utilizar los módulos de

autenticación externos para integrar fácilmente las infraestructuras existentes de
seguridad, incluyendo Pluggable Authentication Modules y el directorio activo de
Windows

MySQL Enterprise Monitor: supervisa continuamente su base de datos y de forma

proactiva le asesora sobre cómo implementar las mejores prácticas de MySQL,
incluyendo consejos y alertas de seguridad

MySQL Query Analyzer: Mejora el rendimiento de las aplicaciones mediante el

control de rendimiento de las consultas y precisa localización de código SQL que está
causando una desaceleración

MySQL Workbench: Cuenta con ofertas de modelado de datos, desarrollo de SQL y

herramientas de administración integral para la administración del servidor de
configuración del usuario, y mucho más.

xliii
 El proceso de instalación es muy simple y prácticamente no requiere intervención por
parte del usuario.

Comienza el proceso; sólo nos llevará un par de minutos…

Cada vez que veo la pantalla de la GNU GPL me lleno de felicidad. No sólo por las
condiciones y el precio: es además, para mí, una garantía de profesionalidad.

xliv
Estadísticamente, la instalación típica será la que mejor se adapte a tus necesidades.

xlv
Todo listo; presiona Install cuando quieras.

xlvi
 Una vez instalado MySQL, la siguiente fase es la configuración del servidor en sí
mismo. Asegúrate de que la marca Launch the MySQL Instance Configuration
Wizard esté activa.

xlvii
 2.1.7 Procedimiento para Configuración de un DBMS

Para configurar nuestro DBMS podemos acceder a las siguientes pantallas, para
Oracle o MySQL.

El esquema de una base de datos (en inglés, Database Schema) describe la

estructura de una Base de datos, en un lenguaje formal soportado por un Sistema
administrador de Base de datos (DBMS). En una Base de datos Relacional, el Esquema
define sus tablas, sus campos en cada tabla y las relaciones entre cada campo y cada
tabla.

Oracle generalmente asocia un 'username' como esquemas en este caso SYSTEM y

HR (Recursos humanos).

Por otro lado MySQL presenta dos esquemas information_schema y MySQL ambos

xlviii
guardan información sobre privilegios y procedimientos del gestor y no deben ser
eliminados.

Adelante, sin miedo…

Optamos por Detailed Configuration, de modo que se optimice la configuración del

servidorMySQL.

xlix
 Ha llegado un momento crucial. Dependiendo del uso que vayamos a darle a nuestro
servidor deberemos elegir una opción u otra, cada una con sus propios requerimientos
de memoria. Puede que te guste la opción Developer Machine, para desarrolladores, la
más apta para un uso de propósito general y la que menos recursos consume. Si vas a
compartir servicios en esta máquina, probablemente Server Machine sea tu elección o,
si vas a dedicarla exclusivamente como servidor SQL, puedes optar por Dedicated
MySQL Server Machine, pues no te importará asignar la totalidad de los recursos a esta
función.

l
 De nuevo, para un uso de propósito general, te recomiendo la opción por defecto,
Multifunctional Database.

li
 InnoDB es el motor subyacente que dota de toda la potencia y seguridad a MySQL.
Su funcionamiento requiere de unas tablas e índices cuya ubicación puedes configurar.
Sin causas de fuerza mayor, acepta la opción por defecto.

lii
 Esta pantalla nos permite optimizar el funcionamiento del servidor en previsión del
número de usos concurrentes. La opción por defecto, Decision Support (DSS) /
OLAP será probablemente la que más te convenga.

liii
 Deja ambas opciones marcadas, tal como vienen por defecto. Es la más adecuada
para un uso de propósito general o de aprendizaje, tanto si eres desarrollador como no.
Aceptar conexiones TCP te permitirá conectarte al servidor desde otras máquinas (o
desde la misma simulando un acceso web típico).

liv
 Hora de decidir qué codificación de caracteres emplearás, salvo que quieras empezar
a trabajar con Unicode porque necesites soporte multilenguaje, probablemente Latin1 te
sirva (opción por defecto).

lv
 Instalamos MySQL como un servicio de Windows (la opción más limpia) y lo
marcamos para que el motor de la base de datos arranque por defecto y esté siempre a
nuestra disposición. La alternativa es hacer esto manualmente.

Además, me aseguro de marcar que los ejecutables estén en la variable PATH, para

poder invocar a MySQL desde cualquier lugar en la línea de comandos.

lvi
 Pon una contraseña al usuario root. Esto siempre es lo más seguro.

Si lo deseas, puedes indicar que el usuario root pueda acceder desde una máquina

diferente a esta, aunque debo advertirte de que eso tal vez no sea una buena práctica
de seguridad.

lvii
Última etapa, listos para generar el fichero de configuración y arrancar el servicio.

lviii
Sólo damos al botón de Finalizar y terminamos con la configuración del DBMS.

lix
 2.1.8 Comandos Generales de Alta y Baja del DBMS

Una tabla es un sistema de elementos de datos (atributo - valores) que se organizan

que usando un modelo vertical - columnas (que son identificados por su nombre)- y
horizontal filas. Una tabla tiene un número específico de columnas, pero puede tener
cualquier número de filas. Cada fila es identificada por los valores que aparecen en un
subconjunto particular de la columna que se ha identificado por una llave primaria.

Una tabla de una base de datos es similar en apariencia a una hoja de cálculo, en
cuanto a que los datos se almacenan en filas y columnas. Como consecuencia,
normalmente es bastante fácil importar una hoja de cálculo en una tabla de una base de
datos. La principal diferencia entre almacenar los datos en una hoja de cálculo y hacerlo
en una base de datos es la forma de organizarse los datos.

lx
 MySQL

 MySQL soporta varios motores de almacenamiento que tratan con distintos tipos de
tabla. Los motores de almacenamiento de MySQL incluyen algunos que tratan con
tablas transaccionales y otros que no lo hacen:

MyISAM: trata tablas no transaccionales. Proporciona almacenamiento y

recuperación de datos rápida, así como posibilidad de búsquedas fulltext. MyISAM se
soporta en todas las configuraciones MySQL, y es el motor de almacenamiento por
defecto a no ser que tenga una configuración distinta a la que viene por defecto con
MySQL.

El motor de almacenamiento MEMORY proporciona tablas en memoria. El motor de

almacenamiento MERGE permite una colección de tablas MyISAM idénticas ser tratadas
como una simple tabla. Como MyISAM, los motores de almacenamiento MEMORY y
MERGE tratan tablas no transaccionales y ambos se incluyen en MySQL por defecto.

Nota: El motor de almacenamiento MEMORY anteriormente se conocía como HEAP.

Los motores de almacenamiento InnoDB y BDB proporcionan tablas transaccionales.

BDB se incluye en la distribución binaria MySQL-Max en aquellos sistemas operativos
que la soportan. InnoDB también se incluye por defecto en todas las distribuciones
binarias de MySQL 5.0. En distribuciones fuente, puede activar o desactivar estos
motores de almacenamiento configurando MySQL a su gusto.

El motor de almacenamiento EXAMPLE es un motor de almacenamiento 'tonto' que

no hace nada. Puede crear tablas con este motor, pero no puede almacenar datos ni
recuperarlos. El objetivo es que sirva como ejemplo en el código MySQL para ilustrar
cómo escribir un motor de almacenamiento. Como tal, su interés primario es para
desarrolladores.

NDB Cluster es el motor de almacenamiento usado por MySQL Cluster para

implementar tablas que se particionan en varias máquinas. Está disponible en
distribuciones binarias MySQL-Max 5.0. Este motor de almacenamiento está disponible
para Linux, Solaris, y Mac OS X. Los autores mencionan que se añadirá soporte para
este motor de almacenamiento en otras plataformas, incluyendo Windows en próximas
versiones.

El motor de almacenamiento ARCHIVE se usa para guardar grandes cantidades de

datos sin índices con una huella muy pequeña.

lxi
 El motor de almacenamiento CSV guarda datos en archivos de texto usando formato
de valores separados por comas.

El motor de almacenamiento FEDERATED se añadió en MySQL 5.0.3. Este motor

guarda datos en una base de datos remota. En esta versión sólo funciona con MySQL a
través de la API MySQL C Client. En futuras versiones, será capaz de conectar con otras
fuentes de datos usando otros drivers o métodos de conexión clientes.

La versión 5 de MySQL crea por defecto tablas InnoDB que permiten el manejo de

integridad referencial, transacciones. Al igual que las tablas regulares de Oracle. Para
saber si el gestor de base de datos de MySQL que tenemos las soporta es necesario
ejecutar la siguiente sentencia.

 SHOW VARIABLES like '%innodb%';

Comando Describe

MySQL proporciona este comando que resulta útil para conocer la estructura de una
tabla, las columnas que la forman y su tipo y restricciones. La sintáxis es la siguiente:

DESCRIBE nombre Tabla.

DESCRIBE f1;

Comando SHOW TABLES y SHOW CREATE TABLE

El comando SHOW TABLES muestra las tablas dentro de una base de datos y SHOW
CREATE TABLES muestra la estructura de creación de la tabla.

Tablas Temporales

 Las tablas temporales solo existen mientras la sesión está viva. Si se corre este
código en un script de PHP (Cualquier otro lenguaje), la tabla temporal se destruirá
automáticamente al término de la ejecución de la página. Si no específica MEMORY, la
tabla se guardará por defecto en el disco.

CREATE TEMPORARY TABLE temporal (

 ife   INTEGER (13) PRIMARY KEY,

 nombre CHAR (30) NOT NULL UNIQUE

lxii
 );

Este tipo de tabla solo puede ser usada por el usuario que la crea.

Si creamos una tabla que tiene el mismo nombre que una existente en la base de
datos, la que existe quedará oculta y trabajaremos sobre la temporal.

Tablas Memory (Head)

Se almacenan en memoria

Una tabla head no puede tener más de 1600 campos

Las tablas MEMORY usan una longitud de registro fija.

MEMORY no soporta columnas BLOB o TEXT.

MEMORY en MySQL 5.0 incluye soporte para columnas AUTO_INCREMENT e

índices en columnas que contengan valores NULL.

Las tablas MEMORY se comparten entre todos los clientes (como cualquier otra tabla
no-TEMPORARY).

CREATE TEMPORARY TABLE temporal (

 ife   INTEGER (13) PRIMARY KEY,

 nombre CHAR (30) NOT NULL UNIQUE

) ENGINE = MEMORY;

Modificación

Esta operación se puede realizar con el comando ALTER TABLE. Para usar ALTER
TABLE, necesita permisos ALTER, INSERT y CREATE para la tabla. La sintaxis para
MySQL es

ALTER [IGNORE] TABLE tbl_name

alter_specification [, alter_specification] ...;

lxiii
alter_specification:

ADD [COLUMN] column_definition [FIRST | AFTER col_name]

| ADD [COLUMN] (column_definition,)

| ADD INDEX [index_name] [index_type] (index_col_name,)

| ADD [CONSTRAINT [symbol]]

PRIMARY KEY [index_type] (index_col_name,)

| ADD [CONSTRAINT [symbol]]

UNIQUE [index_name] [index_type] (index_col_name,)

| ADD [FULLTEXT|SPATIAL] [index_name] (index_col_name,)

| ADD [CONSTRAINT [symbol]]

FOREIGN KEY [index_name] (index_col_name,)

[reference_definition]

| ALTER [COLUMN] col_name {SET DEFAULT literal | DROP DEFAULT}

| CHANGE [COLUMN] old_col_name column_definition

[FIRST|AFTER col_name]

| MODIFY [COLUMN] column_definition [FIRST | AFTER col_name]

| DROP [COLUMN] col_name

| DROP PRIMARY KEY

| DROP INDEX index_name

| DROP FOREIGN KEY fk_symbol

| DISABLE KEYS

lxiv
 | ENABLE KEYS

| RENAME [TO] new_tbl_name

| ORDER BY col_name

| CONVERT TO CHARACTER SET charset_name [COLLATE collation_name]

| [DEFAULT] CHARACTER SET charset_name [COLLATE collation_name]

| DISCARD TABLESPACE

| IMPORT TABLESPACE

| table_options

Unidad 3: Configuración y Administración del Espacio en Disco

3.1 Estructuras Lógicas de Almacenamiento

Para la gestión del almacenamiento de una base de datos existen 4 conceptos bien
definidos que deben ser conocidos para poder comprender la forma en la que se
almacenan los datos. Vamos a ver la diferencia entre bloque, extensión, segmento y
espacio de tablas.

Bloques: Se tratan de la unidad más pequeña. Generalmente debe múltiple del

tamaño de bloque del sistema operativo, ya que es la unidad mínima que va a pedir
Oracle al sistema operativo. Si no fuera múltiple del bloque del sistema se añadiría un
trabajo extra ya que el sistema debería obtener más datos de los estrictamente
necesarios. Se especifica mediante DB_BLOCK_SIZE

Extensiones: Se forma con uno o más bloques. Cuando se aumenta tamaño de un

objeto se usa una extensión para incrementar el espacio.

Segmentos: Grupo de extensiones que forman un objeto de la base de datos, como

por ejemplo una tabla o un índice.

Espacio de Tablas: Formado por uno o más datafiles, cada datafile solo puede
pertenecer a un determinado tablespace.

En general, el almacenamiento de los objetos de la base de datos (tablas e índices

lxv
fundamentalmente) no se realiza sobre el archivo o archivos físicos de la base de
datos, sino que se hace a través de estructuras lógicas de almacenamiento que tienen
por debajo a esos archivos físicos, y que independizan por tanto las sentencias de
creación de objetos de las estructuras físicas de almacenamiento. Esto es útil porque
permite que a esos "espacios de objetos " les sean asociados nuevos dispositivos
físicos (es decir, más espacio en disco) de forma dinámica cuando la base de datos
crece de tamaño más de lo previsto. Posibilita además otra serie de operaciones como
las siguientes:

         Asignar cuotas específicas de espacio a usuarios de la base de datos.

         Controlar la disponibilidad de los datos de la base de datos, poniendo fuera

de uso alguno de esos espacios de tablas individualmente.

         Realizar copias de seguridad o recuperaciones parciales de la base de datos.

         Reservar espacio para almacenamiento de datos de forma cooperativa entre

distintos dispositivos.

El administrador de la base de datos puede crear o borrar nuevos espacios lógicos

de objetos, añadir o eliminar ficheros físicos de soporte, utilizados como espacio
temporal de trabajo, definir parámetros de almacenamiento para objetos destinados a
ese espacio de datos, todos los gestores relacionales que venimos introduciendo como
ejemplos siguen esta filosofía. En el caso de Oracle, sobre los ficheros físicos de datos
(datafiles) se definen los tablespaces. Por lo tanto, una base de datos Oracle se
compone lógicamente de tablespaces, y físicamente de datafiles. Su creación es
sencilla, con la sentencia GREAT'', TABLESPACE: CREATE TABLESPACE usuarios
DATAFILE `datal.ora' SIZE 50M

También es sencillo ampliar el espacio destinado a un tablespace utilizando el

comando ALTER TABLESPACE:

ALTER TABLESPACE usuarios ADD DATAFILE 'data2.ora' SIZE 25M

Para hacer más grande una base de datos, las opciones disponibles son tres:

lxvi
 Cada base de datos contiene un tablespace llamado SYSTEM que es creado
automáticamente al crear la base de datos. Contiene las tablas del diccionario de datos
para la base de datos en cuestión. Es recomendable no cargar datos de usuario en
SYSTEM, para dejarlos como espacio de objetos del sistema.

Si además los datos de usuario están en tablespaces sitos en otros dispositivos, el

rendimiento mejorará porque las tablas del diccionario de datos se acceden
frecuentemente y por lo tanto son un cuello de botella potencial desde el punto de vista
del acceso a disco. A la hora de estimar el espacio necesario para cl tablespace sys-
nsm hay que tener en cuenta que las unidades de programación PL-SQL (entorno de
programación SQL proporcionado por Oracle) almacenadas en la base de datos
(procedimientos, paquetes, disparos y funciones) almacenan sus datos en SYSTEM.

3.1.1 Definición de Almacenamiento de Bases de Datos

Las bases de datos suelen ser creadas para almacenar grandes cantidades de datos
de forma permanente. Por lo general, los datos almacenados en éstas suelen ser
consultados y actualizados constantemente.

La mayoría de las bases de datos se almacenan en las llamadas memorias

secundarias, especialmente discos duros, aunque, en principio, pueden emplearse
también discos ópticos, memorias flash, etc.

Las razones por las cuales las bases de datos se almacenan en memorias
secundarias son:

lxvii
          En general, las bases de datos son demasiado grandes para entrar en la
memoria primaria.

         La memoria secundaria suele ser más barata que la memoria primaria
(aunque esta última tiene mayor velocidad).

         La memoria secundaria es más útil para el almacenamiento de datos

permanente, puesto que la memoria primaria es volátil.

3.1.2.- Definición y Creación del Espacio Asignado para cada Base de Datos

Las bases de datos se almacenan en ficheros o archivos. Existen diferentes formas

de organizaciones primarias de archivos que determinan la forma en que los registros
de un archivo se colocan físicamente en el disco y, por lo tanto, cómo se accede a
éstos.

Las distintas formas de organizaciones primarias de archivos son:

         Archivos de Montículos (o no Ordenados): esta técnica coloca los

registros en el disco sin un orden específico, añadiendo nuevos registros al final del
archivo.

         Archivos Ordenados (o Secuenciales): mantiene el orden de los

registros con respecto a algún valor de algún campo (clave de ordenación).

         Archivos de Direccionamiento Calculado: utilizan una función de

direccionamiento calculado aplicada a un campo específico para determinar la
colocación de los registros en disco.

         Árboles B: se vale de la estructura de árbol para las colocaciones de

registros.

         Organización Secundaria o Estructura de Acceso Auxiliar: Estas

permiten que los accesos a los registros de un archivo basado en campos alternativos,
sean más eficientes que los que han sido utilizados para la organización primaria de
archivos.

El DBMS asigna espacio de almacenamiento a las bases de datos cuando los

usuarios introducen create database o alter database. El primero de los comandos
puede especificar uno o más dispositivos de base de datos, junto con la cantidad de
espacio en cada uno de ellos que será asignado a la nueva base de datos.

lxviii
 Si se utiliza la palabra clave default o se omite completamente la cláusula on, el
DBMS pone la base de datos en uno o más de los dispositivos predeterminados de
base de datos especificados en master.sysdevices.

Para especificar un tamaño (por ejemplo, 4MB) para una base de datos que se va a
almacenar en una ubicación predeterminada, se utiliza: on default = size de esta forma:

create database newpubs  on default = 4

3.1.3.- Bitácoras

Son estructuras ampliamente utilizadas para grabar las modificaciones de la base de

datos.

Cada registro de la bitácora escribe una única escritura de base de datos y tiene lo
siguiente:

         Nombre de la Transacción: Nombre de la transacción que realizó la

operación de escritura.

         Nombre del Dato: El nombre único del dato escrito.

         Valor Antiguo: El valor del dato antes de la escritura.

         Valor Nuevo: El valor que tendrá el dato después de la escritura.

Es fundamental que siempre se cree un registro en la bitácora cuando se realice una

escritura antes de que se modifique la base de datos.

También tenemos la posibilidad de deshacer una modificación que ya se ha escrito

en la base de datos, esto se realizará usando el campo del valor antiguo de los
registros de la bitácora.

Los registros de la bitácora deben residir en memoria estable como resultado el

volumen de datos en la bitácora puede ser exageradamente grande.

La instrucción en MySQL para crear una bitácora en .txt se crea antes de acceder a
la base de datos con la instrucción:

"xampp>mysql>bin>mysql -hlocalhost -uroot --tee=C:bitacora.txt"

La bitácora debe registrar todos los movimientos (insertar, eliminar y modificar) que

lxix
se realicen en las tablas de la base de datos. Para lograr lo anterior es necesario crear
un trigger para que se ejecute después de la operación de insertar, otro para después
de eliminar y el último para después de modificar para cada una de las 3 tablas de la
base de datos.

3.1.4.- Particiones

Cuando alguna de las tablas de una base de datos llega a crecer tanto que el
rendimiento empieza a ser un problema, es hora de empezar a conocer algo sobre
optimización. Una característica de MySQL son las particiones.

Particionar tablas en MySQL nos permite rotar la información de nuestras tablas en

diferentes particiones, consiguiendo así realizar consultas más rápidas y recuperar
espacio en disco al borrar los registros. El uso más común de particionado es según la
fecha.

Para ver si nuestra base de datos soporta particionado simplemente ejecutamos:

SHOW VARIABLES LIKE '%partition%';

Se puede particionar una tabla de 5 maneras diferentes:

         Por Rango: para construir las particiones se especifican rangos de

valores.

ALTER TABLE contratos 

PARTITION BY RANGE (YEAR (fechaInicio)) ( 

PARTITION partDecada80 VALUES LESS THAN (1990), 

PARTITION partDecada90 VALUES LESS THAN (2000), 

PARTITION partDecada00 VALUES LESS THAN (2010), 

PARTITION partDefault VALUES LESS THAN MAXVALUE 

);

La última partición (partDefault) tendrá todos los registros que no entren en las
particiones anteriores. De esta manera nos aseguramos que la información nunca

lxx
dejará de insertarse en la tabla.

         Por Listas: para construir nuestras particiones especificamos listas de

valores concretos.

ALTER TABLE contratos 

PARTITION BY LIST (YEAR (fechaInicio)) ( 

    PARTITION partDecada80 VALUES IN (1980, 1981, 1982, 1983, 1984, 1985,

1986, 1987, 1988, 1989), 

    PARTITION partDecada90 VALUES IN (1990, 1991, 1992, 1993, 1994, 1995,
1996, 1997, 1998, 1999), 

    PARTITION partDecada00 VALUES IN (2000, 2001, 2002, 2003, 2004, 2005,
2006, 

2007, 2008, 2009), 

    PARTITION partDecada10 VALUES IN (2010, 2011, 2012, 2013, 2014, 2015,
2016, 

2017, 2018, 2019) 

); 

         Por Hash: MySQL se encarga de distribuir las tuplas automáticamente

usando una operación de módulo. Sólo hay que pasarle una columna o expresión que
resulte en un entero (el hash) y el número de particiones que queramos crear.

ALTER TABLE contratos 

PARTITION BY HASH (YEAR (fechaInicio)) 

PARTITIONS 7; 

         Por Clave: similar a la partición por hash, pero en este caso no

necesitamos pasarle un entero; MySQL utilizará su propia función de hash para
generarlo. Si no se indica ninguna columna a partir de la que generar el hash, se utiliza
la clave primaria por defecto.

lxxi
 ALTER TABLE contratos 

PARTITION BY KEY () 

PARTITIONS 7; 

         Compuesta: podemos combinar los distintos métodos de particionado y

crear particiones de particiones

Borrar Particiones

Lo bueno de trabajar con particiones es que podemos borrar rápidamente registros

sin tener que recorrer toda la tabla e inmediatamente recuperar el espacio en disco
utilizado por la tabla.

Por ejemplo si queremos borrar la partición más antigua simplemente ejecutamos:

ALTER TABLE reports DROP PARTITION p201111;

Añadir particiones

En el ejemplo anterior las 2 últimas particiones creadas han sido:

 PARTITION p201205 VALUES LESS THAN (TO_DAYS ("2012-06-01")),

PARTITION pDefault VALUES LESS THAN MAXVALUE

 El problema es que todos los INSERT que se hagan después de mayo de 2012 se
insertarán en pDefault. La solución sería añadir particiones nuevas para cubrir los
próximos meses:

ALTER TABLE reports REORGANIZE PARTITION pDefault INTO (

PARTITION p201206 VALUES LESS THAN (TO_DAYS ("2012-07-01")),

PARTITION pDefault VALUES LESS THAN MAXVALUE);

En el caso que no tuviéramos una partición del tipo pDefault simplemente

ejecutamos:

ALTER TABLE reports ADD PARTITION (PARTITION p201206 VALUES LESS

lxxii
THAN (TO_DAYS ("2012-07-01")));

Consultar Particiones

Para consultar información de particiones creadas en una tabla así como también los
registros que contiene cada una ejecutamos:

SELECT PARTITION_NAME, TABLE_ROWS FROM

information_schema.PARTITIONS WHERE TABLE_NAME='reports';

3.1.5.- Espacios Privados

Un “espacio privado” permite que los administradores y redactores gestionen el

conjunto de datos del sitio. Algunas bases de datos tienen estos espacios privados
llamados comúnmente paneles de control, que son formularios que aparecen al abrir la
base de datos.

Los paneles de control sirven de "puerta principal" o "recibidor" de una base de

datos en el sentido de que dirigen a las personas hacia determinadas tareas, como
introducir o buscar datos. Sirven también para mantener alejados a los usuarios de las
tablas que contienen los datos en tiempo real.

Cuando se recibe una base de datos, se averiguar cómo están estructurados los
datos, revisar de manera general el panel de control. Puede ofrecer algún indicio sobre
las tareas que el diseñador de la base de datos consideró que realizarían los usuarios
habitualmente con los datos.

3.1.6.- Espacios para Objetos

Los DBMS se basan en archivos para almacenar datos, y estos archivos, o

conjuntos de datos, residen en medios de almacenamiento, o dispositivos. Una buena
parte del trabajo del DBA implicará la planificación para el almacenamiento real de la
base de datos.

El rendimiento de la base de datos depende de la entrada y salida a disco. La

cantidad de datos almacenados es mayor que nunca antes, y los datos son
almacenados por más tiempo.

Algunos DBMS permiten al tamaño de los archivos temporales de expandirse y

contraerse de forma automática. Dependiendo del tipo y la naturaleza de las
operaciones de base de datos en proceso, esta fluctuación puede provocar picos de
uso del disco.

lxxiii
 Hay muchos problemas de almacenamiento que deben ser resueltos antes de que
un DBA pueda crear una base de datos. Uno de los temas más importantes es la
cantidad de espacio para permitir la base de datos.

El cálculo espacial debe tener en cuenta no sólo tablas, índices, sino también, y
dependiendo del DBMS, el registro de transacciones. Cada una de estas entidades
probablemente requerirá un archivo separado o conjunto de datos, para el
almacenamiento persistente.

El DBA debe separar en diferentes discos a los archivos para:

         Mejorar el rendimiento

         Separar índices de datos

         Aislar los logros en otro disco

3.2 Segmentos

Los datos en la BD son almacenados físicamente en bloques Oracle: la mínima

unidad de espacio físico, y es un múltiplo del bloque del SO (2 Kb usualmente). El
tamaño del bloque Oracle se fija por el parámetro DB_BLOCK_SIZE del fichero init.ora.
Un tamaño grande de bloque mejora la eficiencia del cache de E/S, pero el tamaño de
la SGA aumentará para contener los mismos DB_BLOCK_BUFFERS, lo que significa
un problema de memoria.

Una serie de bloques contiguos es una extensión, que es una unidad lógica de
almacenamiento. Una serie de extensiones es un segmento. Cuando un objeto es
creado, se reserva una extensión en su segmento. Cuando el objeto crezca, necesitará
más espacio y se reservarán más extensiones.

Cada segmento tiene un conjunto de parámetros de almacenamiento que controla

su crecimiento:

initial: tamaño de la extensión inicial (10k).

next: tamaño de la siguiente extensión a asignar (10k).

minextents: número de extensiones asignadas en el momento de la creación del

segmento (1).

lxxiv
 maxextents: número máximo de extensiones (99).

pctincrease: Porcentaje en el que crecerá la siguiente extensión antes de que se

asigne, en relación con la última extensión utilizada (50).

pctfree: porcentaje de espacio libre para actualizaciones de filas que se reserva

dentro de cada bloque asignado al segmento (10).

pctused: porcentaje de utilización del bloque por debajo del cual Oracle considera
que un bloque puede ser utilizado para insertar filas nuevas en él.

tablespace: nombre del espacio de tablas donde se creará el segmento.

Cuando se diseña una BD se ha de tener mucho cuidado a la hora de dimensionar la

BD y prever el crecimiento de las tablas. A continuación se hacen algunas
consideraciones sobre la gestión del espacio para los diferentes segmentos.

Segmentos de Datos

El espacio del diccionario de datos se suele mantener más o menos constante,

aunque es crítico que tenga suficiente espacio para crecer en el espacio de tablas
SYSTEM. Así, hay que tener cuidado de colocar las tablas de usuario, los índices,
segmentos temporales y los segmentos de rollback en otros espacios de tablas.

Además, es recomendable que el espacio de tablas SYSTEM esté al 50% o 75% de

su espacio disponible. Finalmente, asegurarse que los usuarios no tienen privilegios de
escritura en el espacio de tablas SYSTEM.

Las tablas crecen proporcionalmente con el número de filas, ya que se puede

suponer que la longitud de las filas es constante.

Segmentos de Índice

Los índices crecen en tamaño en mayor proporción que las tablas asociadas si los
datos en la tabla son modificados frecuentemente. La gestión del espacio es mejor si
se mantienen los índices de tablas grandes en espacios de tablas separados.

Segmentos de Rollback

Los segmentos de rollback almacenan la imagen anterior a una modificación de un

bloque. La información en el segmento de rollback se utiliza para asegurar la
consistencia en lectura, el rollback (el valor en el segmento de rollback se copia en el

lxxv
bloque de datos) y la recuperación.

Es importante comprender cuál es el contenido de un segmento de rollback. No

almacenan el bloque de datos modificado entero, sólo la imagen previa de la fila o filas
modificadas. La información del segmento de roolback consiste en varias entradas
llamadas undo. Por ejemplo, si se inserta una fila en una tabla, el undo necesitará sólo
el rowid de la fila insertada, ya que para volver atrás la insercion sólo hay que realizar
un delete. En las operación de actualización, se almacenará el valor antiguo de las
columnas modificadas. El segmento de rollback asegura que la información undo se
guardan durante la vida de la transacción.

Un segmento de rollback como cualquier otro segmento consiste en una serie de

extensiones. Sin embargo, la mayor diferencia entre un segmento de datos y otro
rollback es que en este último las extensiones se utilizan de manera circular. Así, habrá
que tener cuidado a la hora de fijar el tamaño del segmento de rollback para que la
cabeza no pille a la cola.

Segmentos Temporales

Los segmentos temporales se crean cuando se efectuan las siguientes operaciones:

Create Index

Select con distinct, order by, union, intersect y minus.

uniones no indexadas.

Ciertas subconsultas correlacionadas.

Si las tablas a ordenar son pequeñas la ordenación se realiza en memoria principal,

pero si la tabla es grande se realiza en disco. El parámetro SORT_AREA_SIZE
determina el lugar donde se hace la ordenación. Incrementándole se reduce la creación
de segmentos temporales.

3.3 Definición de Memoria Compartida

Un servidor Oracle es un sistema que permite administrar bases de datos y que

ofrece un medio de gestión de información abierto, completo e integrado.

Un servidor Oracle está constituido de una instancia y una base de datos.

lxxvi
 Instancia de Oracle

Una instancia de Oracle permite acceder a la base de datos Oracle y permite abrir
únicamente una sola base de datos.

La instancia de Oracle está compuesta de:

Procesos en segundo plano que administran y aplican las relaciones entre las
estructuras físicas y las estructuras de memoria. Existen dos categorías:

         Procesos en Segundo Plano Obligatorios: DBWN, PMON, CKPT, LGWR,

SMON

         Procesos en Segundo Plano Facultativos: ARCn, LMDn, RECO, CJQ0,

LMON, Snnn, Dnnn, Pnnn, LCKn, QMNn

Estructuras de Memoria: compuestas básicamente de dos áreas de memoria: el

área de memoria asignada a la SGA (System Global Area): asignada al inicio de la
instancia y representa un componente fundamental de una instancia de Oracle.

Está compuesta de varias áreas de memoria:

Área de memoria compartida

Buffer caché de la base de datos

Log buffer

Así como otras estructuras para la gestión de bloqueos externos (lock), internos
(match), datos estadísticos, etc.

Eventualmente también es posible configurar al nivel de la SGA

Área de memoria LARGE POOL

Área de memoria Java

Área de Memoria Asignada a la PGA (Program Global Area): Ésta es asignada al

inicio del proceso de servidor. Es reservada a cada proceso de usuario que se conecte
a la base de datos Oracle y liberada al final del proceso.

El Proceso de Usuario: Es el programa que solicita una interacción con la base de

lxxvii
datos iniciando una conexión. Se comunica únicamente con el proceso de servidor
correspondiente.

El Proceso de Servidor

Representa el programa que entra directamente en interacción con el servidor

Oracle. Responde a todas las peticiones y envía los resultados. Puede estar dedicado
a un servidor cliente o compartido por varios.

3.4 Definición de Múltiples Instancias de un DBMS

Cuando comenzamos a trabajar con Oracle una de las primeras cosas que
aprendemos es a diferenciar entre estos conceptos: base de datos, instancia e
instancia de base de datos.

Una instancia es el conjunto de procesos que se ejecutan en el servidor así como la

memoria que comparten para ello.

Cuando se habla de base de datos, nos referimos a los archivos físicos que
componen nuestra base de datos.

Si queremos referirnos a los procesos que se ejecutan en memoria como a los

archivos de base de datos tendremos que utilizar el término instancia de base de datos.

La instancia en Oracle describe varios procesos residentes en la memoria del

computador(es) y un área de memoria compartida por aquellos procesos. En
arquitecturas de bases de datos tales como, Microsoft SQL Server e IBM BD2, la
palabra instancia indica una colección de bases de datos que comparten recursos de
memoria en común, o sea, la relación entre instancia y bases de datos es 1 a N. Pero
la relación entre la instancia de Oracle y la base de datos es 1 a 1 o n a 1. Cuando hay
una relación N a 1, la configuración es llamada RAC (Real Application CLuster), donde
la base de datos reside en discos compartidos y las instancias en múltiples
computadores anexados a la base de datos.

La instancia de Oracle es el motor que procesa los requerimientos de datos desde la

base de datos. Está compuesta por procesos en primer plano, en segundo plano y un
área de memoria compartida (SGA).

lxxviii
 Una instancia de Oracle es un conjunto de estructuras de memoria que están
asociadas con los archivos de datos (datafiles) en una máquina. Una base de datos es
una colección de archivos físicos.

Instancia de Oracle

La integran los procesos 'background' y la SGA. Abre una y sólo una BDO, y permite
acceder a ella.

Nota: con Oracle Real Application Cluster (RAC), más de una instancia usarán la
misma BD.

En la máquina donde reside el servidor Oracle, la variable ORACLE_SID identifica a

lxxix
la instancia con la que estamos trabajando.

Vistas

V$DATABASE (Base de datos).

V$INSTANCE (Instancia).

V$SGA (SGA).

V$SGAINFO (Gestión dinámica de la SGA).

V$SGASTAT (SGA detallada).

V$BUFFER_POOL (Buffers en la caché de datos)

V$SQLAREA (Sentencias SQL).

V$PROCESS (Procesos).

V$BGPROCESS (Procesos background).

V$DATAFILE (Ficheros de datos de la BD).

V$CONTROLFILE (Ficheros de control de la BD).

V$LOGFILE (Ficheros redo log de la BD).

DBA_TABLESPACES (Tablespaces de la BD).

DBA_SEGMENTS (Segmentos que hay en los tablespaces).

DBA_EXTENTS (Extensiones que componen los segmentos).

DBA_USERS (Usuarios de la BD).

Oracle RAC(Real Application CLuster).

En un Rac de Oracle, múltiples instancias permiten el acceso a una única Base de

datos. En un RAC las instancias corren en múltiples Nodos (servidores), y acceden a
un conjunto común de datafiles que comprender a una 'Única' Base de datos."

lxxx
 En contraste, en un ambiente de una única instancia, una base de datos Oracle es
usada por sólo UNA Instancia corriendo en el servidor. Por lo Tanto, los usuarios
accediendo a la base de datos pueden conectarse a ésta, sólo a través de ese 'Único'
servidor.

En un Oracle RAC, una base de datos puede ser montada por más de una instancia,
y en cualquier punto, una instancia será parte de sólo una Base de datos. El almacén
no volátil para archivos de datos que comprende la Base de datos es igualmente
disponible a todos los nodos, para el acceso de lectura y escritura. De lo anterior se
desprende que un RAC de Oracle necesita coordinar y regular el acceso “simultaneo” a
los datos desde múltiples servidores (nodos), por ende, debe existir una red privada
que sea eficiente, confiable y de alta rapidez, entre los nodos del clúster para enviar y
recibir datos

Crear Instancias MySQL

Tener dos instancias o más tiene entre otras las siguientes justificaciones. Una se
dedicará a desarrollo, para hacer las modificaciones y pruebas necesarias y otra al de
producción.

Proceso

Copiar la carpeta data que se encuentra en nuestro caso en c:\MySQL, como data2

lxxxi
 Copiar y pegar la configuración de MySQL. Es decir, del archivo my.ini (en linux
my.cnf) generamos una copia que podría llamarse my2.ini.

lxxxii
 Ahora con cuidado editamos my2.ini, procure no tocar my,ini a menos que este
seguro de lo que hace.

Iniciamos configurando el puerto por donde escuchara MySQL la segunda instancia

y la ruta de datos el archivo de datos.

Iniciar Instancia desde Consola

Desde la consola de ms-dos en modo administrador. [Tecla Win] + [X] y damos clic
en Símbolo de Sistema (Administrador). Ahora introduzca desde la línea de comandos:

lxxxiii
 cd /MySQL/MySQL Server 5.6/bin

mysqld --defaults-file=my2.ini --explicit_defaults_for_timestamp = TRUE

mysql -u root -port 3307 -p

Establecer la Instancia como Servicio

Procederemos a instalar la nueva instancia como servicio. Desde la consola de ms-

dos en modo administrador. En windows 8 pulse la [Tecla Win] + [X] y damos clic en
Símbolo de Sistema (Administrador):

lxxxiv
Unidad 4: Operación y Mantenibilidad
4.1  Bitácoras de Trabajo del DBMS

Una bitácora (log) es una herramienta (archivos o registros) que permite registrar,

analizar, detectar y notificar eventos que sucedan en cualquier sistema de información
utilizado en las organizaciones.

La estructura más ampliamente usada para grabar las acciones que se llevan en la base
de datos.

Nos ayuda a recuperar la información ante algunos incidentes de seguridad, detección

de comportamiento inusual, información para resolver problemas, evidencia legal, es de
gran ayuda en las tareas de computo forense.

Permite guardar las transacciones realizadas

sobre una base de datos en específico, de tal
manera que estas transacciones puedan ser
auditadas y analizadas posteriormente.

lxxxv
 Pueden obtenerse datos específicos de la transacción como:

1.    Operación que se realizó

2.    Usuario de BD

3.    Fecha

4.    Máquina

5.    Programa

6.    Tipo de conexión

7.    Estado

No se requiere hacer cambios en los sistemas de producción o de desarrollo o en una

simple instalación para la implementación de la bitácora.

A través de la parametrización se generan las pantallas de consulta y reportes sin

necesidad de programar.

Acceso a la bitácora a través de una aplicación Web.

Control de Acceso a la información de la bitácora a través de Roles.

Se puede implementar en los sistemas de información que utilicen las principales bases
de datos: Oracle, SQL Server, Informix, Sybase.

Permite hacer el seguimiento de todos los cambios que ha tenido un registro.

4.1.1 Funciones Específicas de las Bitácoras

La estructura más ampliamente usada para grabar las modificaciones de la base de

datos es la Bitácora. Cada registro de la bitácora escribe una única escritura de base de
datos y tiene lo siguiente:

         Nombre de la Transacción

 Valor antiguo
 Valor Nuevo

lxxxvi
 Es fundamental que siempre se cree un registro en la bitácora cuando se realice una
escritura antes de que se modifique la base de datos.

También tenemos la posibilidad de deshacer una modificación que ya se ha escrito en la

base de datos, esto se realizará usando el campo del valor antiguo de los registros de la
bitácora.

Los registros de la bitácora deben residir en memoria estable como resultado el volumen
de datos en la bitácora puede ser exageradamente grande.

Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de

sincronización lo cual representa el límite entre dos transacciones consecutivas, o el final
de una unidad lógica de trabajo, y por tanto al punto en el cual la base de datos esta (o
debería estar) en un estado de consistencia. Las únicas operaciones que establecen un
punto de sincronización son COMMIT, ROLLBACK y el inicio de un programa. Cuando se
establece un punto de sincronización:

Se comprometen o anulan todas las modificaciones realizadas por el programa desde el

punto de sincronización anterior.

Se pierde todo posible posicionamiento en la base de datos. Se liberan todos los

registros bloqueados. Es importante advertir que COMMIT y ROLLBACK terminan las
transacción, no el programa.

4.1.2 Recuperación (Rollback)

En tecnologías de base de datos, un rollback es una operación que devuelve a la base

de datos a algún estado previo. Los Rollbacks son importantes para la integridad de la
base de datos, a causa de que significan que la base de datos puede ser restaurada a una
copia limpia incluso después de que se han realizado operaciones erróneas. Son cruciales
para la recuperación de crashes de un servidor de base de datos; realizando rollback
(devuelto) cualquier transacción que estuviera activa en el tiempo del crash, la base de
datos es restaurada a un estado consistente.

En SQL, ROLLBACK es un comando que causa que todos los cambios de datos desde
la última sentencia BEGIN WORK, o START TRANSACTION sean descartados por el
sistema de gestión de base de datos relacional (RDBMS), para que el estado de los datos
sea "rolled back"(devuelto) a la forma en que estaba antes de que aquellos cambios
tuvieran lugar.

Una sentencia ROLLBACK también publicará cualquier savepoint existente que puediera

lxxxvii
estar en uso.

En muchos dialectos de SQL, los ROLLBACK son específicos de la conexión. Esto

significa que si se hicieron dos conexiones a la misma base de datos,
un ROLLBACK hecho sobre una conexión no afectará a cualesquiera otras conexiones.
Esto es vital para el buen funcionamiento de la Concurrencia.

La funcionalidad de rollback está normalmente implementada con un Log de

transacciones, pero puede también estar implementada mediante control de concurrencia
multiversión.

4.1.3 Permanencia (Commit)

En el contexto de la Ciencia de la computación y la gestión de datos, commit (acción de

comprometer) se refiere a la idea de consignar un conjunto de cambios "tentativos, o no
permanentes". Un uso popular es al final de una transacción de base de datos.

Una sentencia COMMIT en SQL finaliza una transacción de base de datos dentro de un
sistema gestor de base de datos relacional (RDBMS) y pone visibles todos los cambios a
otros usuarios. El formato general es emitir una sentencia BEGIN WORK, una o más
sentencias SQL, y entonces la sentencia COMMIT. Alternativamente, una sentencia
ROLLBACK se puede emitir, la cual deshace todo el trabajo realizado desde que se emitió
BEGIN WORK. Una sentencia COMMIT publicará cualquiera de los savepoints (puntos de
recuperación) existentes que puedan estar en uso.

En términos de transacciones, lo opuesto de commit para descartar los cambios "en

tentativa" de una transacción, es un rollback.

4.2 Definición de los Modos de Operación de un DBMS (Alta, Baja, Recovery)

La vida de todo archivo comienza cuando se crea y acaba cuando se borra. Durante su
existencia es objeto de constante procesamiento, que con mucha frecuencia incluye
acciones de consulta o búsqueda y de actualización. En el caso de la estructura archivos,
entenderemos como actualización, además de las operaciones, vistas para vectores y
listas enlazadas, de introducir nuevos datos (altas) o de eliminar alguno existente (bajas), la
modificación de datos ya existentes, (operación muy común con datos almacenados). En
esencia, es la puesta al día de los datos del archivo.

Una operación de alta en un archivo consiste en la adición de un nuevo registro. En un

archivo de empleados, un alta consistirá en introducir los datos de un nuevo empleado.
Para situar correctamente un alta, se deberá conocer la posición donde se desea

lxxxviii
almacenar el registro correspondiente: al principio, en el interior o al final de un archivo.

El algoritmo de ALTAS debe contemplar la comprobación de que el registro a dar de alta

no existe previamente. Una baja es la acción de eliminar un registro de un archivo. La baja
de un registro puede ser lógica o física. Una baja lógica supone el no borrado del registro
en el archivo. Esta baja lógica se manifiesta en un determinado campo del registro con una
bandera, indicador o “flag” -carácter *. $, etc.,-, o bien con la escritura o rellenado de
espacios en blanco en el registro dado de baja

Altas

La operación de dar de alta un determinado registro es similar a la de añadir datos a un

archivo. Es importante remarcar que en un archivo secuencial sólo permite añadir datos al
final del mismo.

En otro caso, si se quiere insertar un registro en medio de los ya presentes en el archivo,

sería necesaria la creación nueva del archivo.

El algoritmo para dar de alta un registro al final del fichero es como sigue:

algoritmo altas
leer registro de alta
inicio
abrir archivo para añadir
mientras haya más registros hacer {algunos lenguajes ahorran este bucle}
leer datos del registro
fin_mientras
escribir (grabar) registro de alta en el archivo
cerrar archivo
fin

Bajas

Existen dos métodos para dar de baja a un registro en un archivo secuencial, donde no
es fácil eliminar un registro situado en el interior de una secuencia: Para ello podemos
seguir dos métodos:

1) Utilizar y por tanto crear un segundo archivo auxiliar transitorio, también secuencial,
copia del que se trata de actualizar. Se lee el archivo completo registro a registro y en
función de su lectura se decide si el registro se debe dar de baja o no. En caso afirmativo,
se omite la escritura en el archivo auxiliar. Si el registro no se va a dar de baja, este registro

lxxxix
se reescribe en el archivo auxiliar

Tras terminar la lectura del archivo original, se tendrán dos archivos: original (o maestro)
y auxiliar. El proceso de bajas del archivo concluye borrando el archivo original y
cambiando el nombre del archivo auxiliar por el del inicial.

2) Guardar o señalar los registros que se desean dar de baja con un indicador o bandera
que se guarda en un array; de esta forma los registros no son borrados físicamente, sino
que son considerados como inexistentes.

Inevitablemente, cada cierto tiempo, habrá que crear un nuevo archivo secuencial con el
mismo nombre, en el que los registros marcados no se grabarán.

Propósito de Backup y Recuperación

Como administrador de copia de seguridad, la tarea principal es diseñar, implementar y

gestionar una estrategia de backup y recuperación. En general, el propósito de una
estrategia de recuperación de copia de seguridad y es para proteger la base de datos
contra la pérdida de datos y reconstruir la base de datos después de la pérdida de datos.
Normalmente, las tareas de administración de seguridad son las siguientes:

         Planificación y probar las respuestas a diferentes tipos de fallas.

         Configuración del entorno de base de datos de copia de seguridad y

recuperación.

         La creación de un programa de copia de seguridad

         Seguimiento de la copia de seguridad y entorno de recuperación

         Solución de problemas de copia de seguridad

         Para recuperarse de la pérdida de datos en caso de necesidad

Como administrador de copia de seguridad, es posible que se le pida que realice otros
deberes que se relacionan con copia de seguridad y recuperación:

         La preservación de datos, lo que implica la creación de una copia de base de

datos para el almacenamiento a largo plazo

         La transferencia de datos, lo que implica el movimiento de datos de una base de

xc
 datos o un host a otro.

De Protección de Datos

Como administrador de copia de seguridad, su trabajo principal es hacer copias de

seguridad y vigilancia para la protección de datos. Una copia de seguridad es una copia de
los datos de una base de datos que se puede utilizar para reconstruir los datos. Una copia
de seguridad puede ser una copia de seguridad física o una copia de seguridad lógica.

Copias de seguridad físicas son copias de los archivos físicos utilizados en el

almacenamiento y la recuperación de una base de datos. Estos archivos incluyen archivos
de datos, archivos de control y los registros de rehacer archivados. En última instancia,
cada copia de seguridad física es una copia de los archivos que almacenan información de
base de datos a otra ubicación, ya sea en un disco o en medios de almacenamiento fuera
de línea, tales como cinta.
Copias de seguridad lógicas contienen datos lógicos, como tablas y procedimientos
almacenados. Puede utilizar Oracle Data Pump para exportar los datos a archivos lógicos
binarios, que posteriormente puede importar a la base de datos. Clientes de línea de
comandos La bomba datos expdp y impdp utilizan el DBMS_DATAPUMP y
DBMS_METADATA PL / SQL paquetes.

Copias de seguridad físicas son la base de cualquier estrategia de recuperación de

copia de seguridad sólida y. Copias de seguridad lógicas son un complemento útil de las
copias de seguridad físicas en muchas circunstancias, pero no son suficiente protección
contra la pérdida de datos y sin respaldos físicos.
A menos que se especifique lo contrario, la copia de seguridad término tal como se utiliza
en la copia de seguridad y la documentación de recuperación se refiere a una copia de
seguridad física. Copia de seguridad de una base de datos es el acto de hacer una copia
de seguridad física. El enfoque en la copia de seguridad y recuperación de documentación
está casi exclusivamente en copias de seguridad físicas.

Mientras que varios problemas pueden detener el funcionamiento normal de una base
de datos Oracle o afectar a las operaciones de base de datos de E / S, solamente la
siguiente normalmente requiere la intervención del DBA y de recuperación de datos: un
error de medios, errores de usuario, y los errores de aplicación. Otros fallos pueden
requerir intervención DBA sin causar la pérdida de datos o que requieren la recuperación
de copia de seguridad. Por ejemplo, es posible que tenga que reiniciar la base de datos
tras un fallo de instancia o asignar más espacio de disco después de un fallo debido a la
declaración de un archivo de datos completo.

xci
 Las Fallas de Medios

La falta de medios es un problema físico con un disco que provoca un fallo de una leer o
escribir en un archivo de disco que se requiere para ejecutar la base de datos. Cualquier
archivo de base de datos puede ser vulnerable a un fallo de comunicación. La técnica de
recuperación adecuada después de un fallo de los medios de comunicación depende de
los archivos afectados y el tipo de copia de seguridad disponible.
Un aspecto particularmente importante de la copia de seguridad y recuperación se está
desarrollando una estrategia de recuperación ante desastres para proteger contra la
pérdida de datos catastrófica, por ejemplo, la pérdida de toda una serie de bases de datos.

Errores de los Usuarios

Los errores del usuario cuando se producen, ya sea debido a un error en la lógica de la
aplicación o un error manual, los datos en una base de datos se modifican o eliminan
incorrectamente. Errores de usuario se estima que la mayor causa de inactividad de base
de datos.

La pérdida de datos debido a un error del usuario puede ser localizada o generalizada.
Un ejemplo de daño localizado está eliminando a la persona equivocada en la tabla
empleados. Este tipo de lesiones requiere la detección y la reparación quirúrgica. Un
ejemplo de un daño generalizado es un trabajo por lotes que borra las órdenes de la
empresa para el mes en curso. En este caso, se requiere una acción drástica para evitar
una extensa base de datos de tiempo de inactividad.

Mientras que la formación de usuarios y el manejo cuidadoso de los privilegios pueden

prevenir la mayoría de los errores de usuario, su estrategia de copia de seguridad
determina la gracia de recuperar los datos perdidos cuando un error del usuario que hace
perder los datos.

Errores de Aplicación

A veces, un mal funcionamiento de software puede dañar los bloques de datos. En una
corrupción física, que también se conoce como la corrupción los medios de comunicación,
la base de datos no reconoce el bloque en absoluto: la suma de comprobación no es
válida, el bloque contiene todos los ceros, o el encabezado y el pie de página del bloque no
coinciden. Si el daño no es muy amplio, puede a menudo repara fácilmente con bloque de
recuperación de medios.

Preservación de Datos

xcii
 Conservación de datos se relaciona con la protección de datos, pero tiene un propósito
diferente. Por ejemplo, puede que tenga que conservar una copia de una base de datos tal
como existía al final de la cuarta parte del negocio. Esta copia de seguridad no es parte de
la estrategia de recuperación de desastres. Los medios a los que estas copias de
seguridad se escriben a menudo disponible después de la copia de seguridad. Usted
puede enviar la cinta en almacenamiento incendio o enviar un disco duro portátil a un
centro de pruebas. RMAN proporciona una manera conveniente para crear una copia de
seguridad y eximirla de su política de retención de copia de seguridad. Este tipo de copia
de seguridad se conoce como una copia de seguridad de archivo.

Transferencia de Datos

En algunas situaciones, es posible que tenga que tomar una copia de seguridad de una
base de datos o base de datos de componentes y moverlo a otra ubicación. Por ejemplo,
puede utilizar el Administrador de recuperación (RMAN) para crear una copia de base de
datos, cree una copia de tabla que se puede importar en otra base de datos, o mover una
base de datos completa de una plataforma a otra. Estas tareas no son, estrictamente
hablando, parte de una estrategia de backup y recuperación, pero requieren el uso de
copias de seguridad de bases de datos, por lo que pueden incluirse en las tareas de un
administrador de copia de seguridad.

Oracle Backup y Recuperación de Soluciones

Al implementar una estrategia de backup y recuperación, dispone de las siguientes

soluciones disponibles:

         Administrador de Recuperación (RMAN)

Recovery Manager está completamente integrado con la base de datos Oracle para
llevar a cabo una serie de actividades de copia de seguridad y recuperación, incluyendo el
mantenimiento de un repositorio de RMAN de datos históricos acerca de las copias de
seguridad. Se puede acceder a RMAN través de la línea de comandos oa través de Oracle
Enterprise Manager.

         Copia de Seguridad y Recuperación Gestionadas por el Usuario

En esta solución, realizar copias de seguridad y recuperación con una mezcla de

comandos del sistema operativo host y SQL * Plus.

Recuperación de Comandos

xciii
 Ustedes son responsables de determinar todos los aspectos de cuándo y cómo las
copias de seguridad y la recuperación se hacen.

Estas soluciones están respaldadas por Oracle y se documentan, pero RMAN es la

mejor solución para copia de seguridad y recuperación de bases de datos. RMAN
proporciona una interfaz común para las tareas de copia de seguridad a través de
diferentes sistemas operativos host, y ofrece varias técnicas de copia de seguridad que no
están disponibles a través de métodos administrados por usuarios.

La mayor parte de este manual se centra en la copia de seguridad y recuperación de

RMAN basado. Técnicas de copia de seguridad y recuperación gestionadas por el usuario
se tratan en Realización de usuario-Managed Backup and Recovery. Las más destacables
son los siguientes:

         Copias de Seguridades Incrementales

Una copia de seguridad incremental almacena sólo los bloques modificados desde la
última copia de seguridad. Por lo tanto, proporcionan copias de seguridad más compacta y
una recuperación más rápida, lo que reduce la necesidad de aplicar de rehacer en archivo
de datos de recuperación de los medios de comunicación. Si se habilita el seguimiento de
cambios de bloque, entonces usted puede mejorar el rendimiento al evitar escaneos
completos de todos los archivos de datos de entrada. Utilice el comando Copia de
seguridad incremental para realizar copias de seguridad incrementales.

         Bloquear los Medios de Recuperación

Usted puede reparar un archivo de datos con sólo un pequeño número de bloques de
datos corruptos sin tomarlo fuera de línea o la restauración desde copia de seguridad.
Utilice el comando BLOQUE RECOVER para realizar la recuperación del bloque de
comunicación.

         Compresión Binaria

Un mecanismo de compresión binaria integrado en base de datos Oracle reduce el

tamaño de las copias de seguridad.

         Copias de Seguridad Encriptadas

RMAN utiliza las capacidades de cifrado de copia de seguridad integrados en bases de

datos Oracle para almacenar conjuntos de copia de seguridad en un formato codificado.
Para crear copias de seguridad cifradas en el disco, la base de datos debe utilizar la opción

xciv
de seguridad avanzada. Para crear copias de seguridad encriptadas directamente en cinta,
RMAN debe utilizar la copia de seguridad de Oracle Secure interfaz SBT, pero no requiere
la opción de seguridad avanzada.

         Duplicación de la Base de Datos Automatizada

Crea fácilmente una copia de su base de datos, el apoyo a diversas configuraciones de

almacenamiento, incluida la duplicación directa entre las bases de datos de ASM.

         Conversión de Datos entre Plataformas

Ya sea que utilice RMAN o métodos administrados por usuarios, puede complementar
las copias de seguridad físicas con copias de seguridad lógicas de objetos de esquema
realizados con la utilidad Export Data Pump. Más tarde, puede utilizar Data Pump Import
para volver a crear los datos después de la restauración y la recuperación. Copias de
seguridad lógicas son en su mayoría más allá del alcance de la copia de seguridad y de
recuperación de documentación.

4.3 Comandos de Activación para los Modos de Operación

Para ser uso de los diferentes comandos para un modo de operación debemos estar
como administrador o asuma un rol que incluya el perfil de derechos Service Management.

Comando STARTUP

Para el arranque de una base de datos hay tres fases de arranque, para realizar estas
fases podemos utilizar startup más un comando, las tres fases son las siguientes:

Fase de no Montaje: se leen los parámetros del sistema, se inician las estructuras de
memoria y los procesos de segundo plano. La instancia se arranca sin asociarla a la base
de datos. Normalmente se utiliza cuando se modifica o se necesita crear el archivo de
control:

startup nomount ;

Fase de Montaje: se asocia la instancia con la base de datos. Se usa el archivo de

parámetros para localizar los archivos de control, que contienen el nombre de los archivos
de datos y los registros rehacer. Los archivos de datos y los registros de rehacer no están
abiertos, así que no son accesibles por usuarios finales para tareas normales. Para realizar
esta fase se pueden utilizar dos comandos:

xcv
 startup mount;

alter database mount;

Fase de Apertura: se abren los archivos de datos y los registros rehacer. La base de
datos queda disponible para las operaciones normales. Es necesario que existan registros
rehacer de lo contrario si no hay registros usamos el comando resetlogs, que crea registros
nuevos. Para esta fase se pueden usar dos comandos:

startup open;

alter database open;

Si es necesario utilizar resetlogs:

startup open resetlogs;

alter database open resetlogs;

startup restrict (sólo permite la conexión de usuarios con el privilegio restricted sesion).

startup force (hace shutdown abort y arranca la BD).

Comando SHUTDOWN

El comando SHUTDOWN lo utilizamos  parar una base de datos la cual consiste en

varias cláusulas.

Shutdown Normal: Este es el valor por defecto, durante el proceso de parada no

admite nuevas conexiones y espera que las conexiones actuales finalicen. En el próximo
arranque la base datos no requiere procedimientos de recuperación.

Shutdown Immediate: Se produce una parada inmediata de la base de datos, durante

el proceso de parada no permite nuevas conexiones y las actuales la desconecta, las
transacciones que no estén commit se hara roolback de ellas. En el próximo arranque la
base datos no requiere procedimientos de recuperación.

Shutdown Transactional: Se produce una parada hasta que hayan terminado las
transacciones activas, no admite nuevas conexiones y tampoco nuevas transacciones, una
vez que las transacciones activas van terminando va desconectando a los usuarios. En el
próximo arranque la base datos no requiere procedimientos de recuperación.

xcvi
 Shutdown Abort: Aborta todos los procesos de una base de datos, durante el proceso
de parada no permite nuevas conexiones y las actuales la desconecta, las transacciones
que no estén commit se hará roolback de ellas. En el próximo arranque la base datos
puede requerir procedimientos de recuperación.

Comando Describe

Este comando permite conocer la estructura de una tabla, las columnas que la forman y
su tipo y restricciones.

DESCRIBE f1;

Comando SHOW TABLES y SHOW CREATE TABLE

El comando SHOW TABLES muestra las tablas dentro de una base de datos y SHOW

CREATE TABLES muestra la estructura de creación de la tabla.

Modificación

Para realizar una modificación utilizamos el comando ALTER TABLE. Para usar ALTER
TABLE, necesita permisos ALTER, INSERT y CREATE para la tabla.

4.4.- Manejo de Índices

El índice de una base de datos es una estructura alternativa de los datos en una tabla. El
propósito de los índices es acelerar el acceso a los datos mediante operaciones físicas
más rápidas y efectivas. En pocas palabras, se mejoran las operaciones gracias a un
aumento de la velocidad, permitiendo un rápido acceso a los registros de una tabla en una
base de datos. Al aumentar drásticamente la velocidad de acceso, se suelen usar sobre
aquellos campos sobre los cuáles se hacen búsquedas frecuentes.

4.4.1 Tipos de Índices

Resumen de Índices

Un índice es una estructura opcional, asociado con una mesa o tabla de clúster, que a
veces puede acelerar el acceso de datos. Mediante la creación de un índice en una o
varias columnas de una tabla, se obtiene la capacidad en algunos casos, para recuperar un
pequeño conjunto de filas distribuidas al azar de la tabla. Los índices son una de las
muchas formas de reducir el disco I / O.

Si una tabla de montón organizado no tiene índices, entonces la base de datos debe

xcvii
realizar un escaneo completo de tabla para encontrar un valor. Por ejemplo, sin un índice,
una consulta de ubicación 2700 en la tabla hr.departments requiere la base de datos para
buscar todas las filas de cada bloque de la tabla para este valor. Este enfoque no escala
bien como datos de aumento de volúmenes.

Por analogía, supongamos que un gerente de Recursos Humanos tiene un estante de

cajas de cartón. Las carpetas que contienen información de los empleados se insertan
aleatoriamente en las cajas. La carpeta de empleado Whalen (ID 200) es de 10 carpetas
desde el fondo de la caja 1, mientras que la carpeta para el rey (ID 100) se encuentra en la
parte inferior del cuadro 3. Para localizar una carpeta, el gestor busca en cada carpeta en
la casilla 1 de abajo hacia arriba, y luego se mueve de una casilla a otra hasta que se
encuentra la carpeta. Para acelerar el acceso, el administrador puede crear un índice que
enumera de forma secuencial todos los ID de empleado con su ubicación de la carpeta:

ID 100: Box 3, position 1 (bottom)

ID 101: Box 7, position 8

ID 200: Box 1, position 10

Del mismo modo, el administrador podría crear índices separados para los últimos
nombres de los empleados, los ID de departamento, y así sucesivamente.
En general, considerar la creación de un índice en una columna en cualquiera de las
siguientes situaciones:

         Las columnas indizadas se consultan con frecuencia y devuelven un pequeño

porcentaje del número total de filas en la tabla.

         Existe una restricción de integridad referencial en la columna o columnas

indexadas. El índice es un medio para evitar un bloqueo de tabla completa que de
otro modo se requeriría si se actualiza la clave principal de la tabla principal, se
funden en la tabla principal, o eliminar de la tabla primaria.

         Una restricción de clave única se coloca sobre la mesa y desea especificar

manualmente el índice de todas las opciones sobre índices y.

Características de Indexación

Los índices son objetos de esquema que son lógica y físicamente independiente de los
datos de los objetos con los que están asociados. Por lo tanto, un índice se puede quitar o
creado sin afectar físicamente a la tabla para el índice.

xcviii
 Nota: Si se le cae un índice, las aplicaciones siguen funcionando. Sin embargo, el
acceso de los datos previamente indexado puede ser más lento.

La ausencia o presencia de un índice no requiere un cambio en el texto de cualquier

sentencia SQL. Un índice es una ruta de acceso rápido a una sola fila de datos. Sólo afecta
a la velocidad de ejecución. Dado un valor de datos que se ha indexado, el índice apunta
directamente a la ubicación de las filas que contienen ese valor.

La base de datos mantiene automáticamente y utiliza los índices después de su

creación. La base de datos también refleja automáticamente los cambios en los datos,
como agregar, actualizar y eliminar filas, en todos los índices pertinentes sin acciones
adicionales requeridas por los usuarios. Rendimiento de recuperación de datos indexados
permanece casi constante, incluso cuando se insertan filas. Sin embargo, la presencia de
muchos índices en una tabla degrada el rendimiento DML porque la base de datos también
debe actualizar los índices.

Los índices tienen las siguientes propiedades:

         Facilidad de Uso

Los índices son utilizables (por defecto) o inutilizable. Un índice inutilizables no se

mantiene por las operaciones DML y es ignorado por el optimizador. Un índice inutilizable
puede mejorar el rendimiento de las cargas a granel. En lugar de dejar un índice y luego
volverlo a crear, puede hacer que el índice inservible y luego reconstruirlo. Índices
inutilizables y las particiones de índice no consumen espacio. Cuando usted hace un índice
utilizable no utilizable, la base de datos cae su segmento de índice.

         Visibilidad

Los índices son visibles (por defecto) o invisible. Un índice invisible se mantiene por las
operaciones DML y no se utiliza de forma predeterminada por el optimizador. Cómo hacer
una invisible índice es una alternativa a lo que es inutilizable o se caiga. Índices invisibles
son especialmente útiles para probar la eliminación de un índice antes de dejarlo caer o
mediante índices temporalmente sin afectar a la aplicación general.

Guía del Administrador para Aprender a Manejar los Índices

         Base de datos Oracle Performance Tuning Guide para aprender cómo ajustar los
índices

Teclas y Columnas

xcix
 Una clave es un conjunto de columnas o expresiones en las que se puede construir un
índice. Aunque los términos se usan indistintamente, los índices y las claves son diferentes.
Los índices son estructuras almacenados en la base de datos que los usuarios a
administrar el uso de sentencias de SQL. Las claves son estrictamente un concepto lógico.

La siguiente sentencia crea un índice en la columna customer_id de la muestra

oe.orders tabla:

CREATE INDEX ord_customer_ix ON orders (customer_id);

En la declaración anterior, la columna customer_id es la clave de índice. El índice en sí

se llama ord_customer_ix.

Índices Compuestos

Un índice compuesto, también llamado índice concatenado, es un índice de varias

columnas de una tabla. Las columnas de un índice compuesto que deben aparecer en el
orden que tenga más sentido para las consultas que recuperar datos y no necesita ser
adyacente en la tabla.

Los índices compuestos pueden acelerar la recuperación de datos para las instrucciones
SELECT en la que el DONDE referencias cláusula totalidad o la parte principal de las
columnas en el índice compuesto. Por lo tanto, el orden de las columnas utilizadas en la
definición es importante. En general, las columnas de acceso más común van primero.

Por ejemplo, supongamos que una aplicación realiza consultas frecuentes a apellidos,
job_id, y columnas de salario en la tabla empleados. También asumir que last_name tiene
alta cardinalidad, lo que significa que el número de valores distintos que es grande en
comparación con el número de filas de la tabla. Se crea un índice con el siguiente orden de
las columnas:

CREATE INDEX employees_ix

ON employees (last_name, job_id, salary);

Las consultas que acceden a las tres columnas, sólo la columna last_name, o sólo el
last_name y columnas job_id utilizan este índice. En este ejemplo, las consultas que no
tienen acceso a la columna last_name no utilizan el índice.

Nota: En algunos casos, tales como cuando la columna principal tiene muy baja
cardinalidad, la base de datos puede utilizar una búsqueda selectiva de este índice.

c
 Múltiples índices pueden existir para la misma mesa, siempre y cuando la permutación
de columnas difiere para cada índice. Puede crear varios índices que utilizan las mismas
columnas si se especifica claramente diferentes permutaciones de las columnas. Por
ejemplo, las siguientes sentencias SQL especifican permutaciones válidas:

CREATE INDEX employee_idx1 ON employees (last_name, job_id);

CREATE INDEX employee_idx2 ON employees (job_id, last_name);

Índices Únicos y no Únicos

Los índices pueden ser únicos o no únicos. Índices únicos garantizar que no hay dos
filas de una tabla tienen valores duplicados en la columna de clave o columna. Por ejemplo,
dos empleados no pueden tener el mismo ID de empleado. Por lo tanto, en un índice único,
existe una ROWID para cada valor de datos. Los datos de los bloques de hojas se ordenan
sólo por clave.

Índices no únicas permiten valores duplicados en la columna o columnas indexadas. Por

ejemplo, la columna 'nombre de la tabla de empleados puede contener varios valores Mike.
Para un índice no único, el ROWID se incluye en la clave de forma ordenada, por lo que los
índices no únicos se ordenan por la clave de índice y ROWID (ascendente).

Oracle Database no filas de la tabla de índice en el que todas las columnas clave son
nulas, a excepción de los índices de mapa de bits o cuando el valor de la columna clave de
clúster es nulo.

Tipos de Índices

Base de Datos Oracle ofrece varias combinaciones de indexación, que proporcionan una
funcionalidad complementaria sobre el rendimiento. Los índices se pueden clasificar de la
siguiente manera:

         Los Índices de Árbol B

Estos índices son el tipo de índice estándar. Son excelentes para la clave principal y los
índices altamente selectivos. Utilizado como índices concatenados, B-tree índice pueden
recuperar los datos ordenados por las columnas de índice. Índices B-tree tienen los
siguientes subtipos:

         Índice de Tablas Organizadas

Una tabla de índice-organizada difiere de un montón-organizado porque los datos es en

ci
sí mismo el índice.

En este tipo de índice, los bytes de la clave de índice se invierten, por ejemplo, 103 se
almacena como 301. La inversión de bytes extiende inserta en el índice durante muchos
bloques.

         Índices Descendentes

Este tipo de índice almacena los datos en una columna o columnas de concreto en
orden descendente.

         Índices B-Tree de Racimo

Este tipo de índice se utiliza para indexar una clave de clúster tabla. En lugar de apuntar
a una fila, los puntos clave para el bloque que contiene filas relacionadas con la clave de
clúster.

         Mapa de Bits y los Índices Bitmap Join

En un índice de mapa de bits, una entrada de índice utiliza un mapa de bits para que
apunte a varias filas. En cambio, los puntos de entrada de un índice B-tree en una sola fila.
Un índice de combinación de mapa de bits es un índice de mapa de bits para la unión de
dos o más tablas. Consulte "Indicadores de mapa de bits".

         Índices Basados en Funciones

Este tipo de índice incluye columnas que, o bien se transforman por una función, tales
como la función UPPER, o incluidos en una expresión. Índices B-tree o mapa de bits puede
ser basado en las funciones.

         Índices de Dominio de Aplicación

Este tipo de índice se crea por un usuario para los datos en un dominio específico de la
aplicación. El índice físico no tiene que utilizar una estructura de índice tradicional y se
puede almacenar ya sea en la base de datos Oracle como tablas o externamente como un
archivo. Consulte "Indicadores de dominio de aplicación".

         Índices B-Tree

Árboles B, abreviatura de árboles balanceados, son el tipo más común de índice de base
de datos. Un índice B-tree es una lista ordenada de valores dividida en rangos. Mediante la
asociación de una tecla con una fila o rango de filas, los árboles B proporcionan un

cii
excelente rendimiento de la recuperación para una amplia gama de consultas, incluyendo
coincidencia exacta y búsquedas por rango.
La figura 3-1 ilustra la estructura de un índice B-tree. El ejemplo muestra un índice en la
columna department_id, que es una columna de clave externa en la tabla empleados.

4.4.2 Reorganización de Índices.

Un factor clave para conseguir una E/S de disco mínima para todas las consultas de
bases de datos es asegurarse de que se creen y se mantengan buenos índices. Una vez
creados los índices, se debe procurar mantenerlos para asegurarse que sigan trabajando
en forma óptima. A medida que se agregan, modifican o borran datos se produce
fragmentación. Esta fragmentación puede ser buena o mala para el rendimiento del
sistema, dependiendo de las necesidades del trabajo de la base de datos.

Fragmentación de los Índices

La fragmentación es consecuencia de los procesos de modificación de los datos

(instrucciones INSERT, UPDATE y DELETE) efectuados en la tabla y en los índices
definidos en la tabla. Como dichas modificaciones no suelen estar distribuidas de forma
equilibrada entre las filas de la tabla y los índices, el llenado de cada página puede variar
con el paso del tiempo. Para las consultas que recorren parcial o totalmente los índices de
una tabla, este tipo de fragmentación puede producir lecturas de páginas adicionales. Esto
impide el recorrido paralelo de los datos. Existen dos tipos de fragmentación:

Interna: Fragmentación dentro de páginas individuales de datos e índices con espacios

libres que generan la necesidad de más operaciones de E/S y más memoria para su
lectura. Este hecho disminuye el rendimiento en ambientes de lectura, pero en algunos
casos puede beneficiar las inserciones, que no requieren una división de páginas con tanta
frecuencia.

Externa: Cuando el orden lógico de las páginas no es correcto, porque las páginas no

son contiguas. El acceso a los datos es mucho más lento por la necesidad de búsqueda de
los datos.

La fragmentación de índices se puede reparar reorganizando un índice o

reconstruyéndolo. Para los índices fraccionados que fueron construidos en una estructura
partida se puede usar cualquiera de estos métodos o bien en un índice completo o bien en
un único fragmento del índice.

Detección de Fragmentación

ciii
 El primer paso para decidir qué método de desfragmentación se va a utilizar consiste en
analizar el índice para determinar el nivel de fragmentación. Si se usa la función del
sistema sys.dm_db_index_physical_stats, se puede detectar la fragmentación de los
índices de la base de datos thuban-homologada.

SELECT DISTINCT

A.INDEX_ID 'IDIndice';

sys.TABLES.name 'Tabla',

b.name 'Indice',

avg_fragmentation_in_percentr '% Fragmentación',

fragment_count 'Cantidad de Fragmentos',

avg_fragment_size_in_pages 'Promedio de fragmentos por página',

FROM

sys.dm_db_index_physical_stats (

DB_ID ()N'thuban-himologada'),

OBJECT_ID (N'dbo.*'),

NULL,

NULL,

NULL) AS  a JOIN sys.indexes AS b ON a.object_id = b.object_id AND a.index_id =

b.index_id,

sys.TABLES

WHERE

sys.TABLES.object_id = b.object_id

ORDER BY

civ
 avg_fragmentation_in_percent DESC

La grilla de resultados emitida por la anterior sentencia incluye las siguientes columnas:

Descripción
Columna
Id Índice El número de índice dentro de la tabla.
Tabla Nombre de la tabla a la que corresponde el índice.
Índice Nombre del índice.
% Fragmentación El porcentaje de fragmentación lógica (páginas del
índice fuera de orden).
Cantidad de fragmentos La cantidad de fragmentos (páginas físicas
consecutivas) en el índice.
Promedio de páginas por Promedio de número de páginas en un fragment del
fragmentos índice.

Una vez que se toma conciencia del nivel de fragmentación, se debe utilizar la tabla a
continuación para determinar el mejor método para su corrección.

Sentencia correctiva
% Fragmentación
> 5% and < = 30% ALTER INDEX REORGANIZE
> 30% ALTER INDEX REBUILD WITH (ONLINE = ON)*

La reconstrucción del índice puede ejecutarse tanto en línea como fuera de línea. La
reorganización de los índices debe ejecutarse siempre en línea. Para adquirir una
disponibilidad similar a la de la opción de reorganización, los índices deben ser
reconstruidos en línea.

Estos valores proveen una estricta guía para determinar el punto en el que se debe
cambiar de ALTER INDEX REORGANIZE a ALTER INDEX REBUILD.

Los niveles muy bajos de fragmentación (menores que el 5 por ciento) no deben ser
corregidos por ninguno de estos comandos porque el beneficio de la remoción de una
cantidad tan pequeña de fragmentación es casi siempre superado ampliamente por el
costo de reorganización o reconstrucción de índices.

Reorganización de Índices

cv
 Para reorganizar uno o más índices se debe usar la sentencia ALTER INDEX con la
cláusula REORGANIZE. Por ejemplo:

ALTER INDEX PK_LOGS ON THUBAN_LOGS REORGANIZE

El proceso de reorganización de índices se realiza siempre en línea y el consumo de

recursos es bajo por lo que no mantiene bloqueos por mucho tiempo.

4.4.3 Reconstrucción de Índices

Es importante periódicamente examinar y determinar qué índices son susceptibles de

ser reconstruidos. Cuando un índice está descompensado puede ser porque algunas
partes de éste han sido accedidas con mayor frecuencia que otras. Como resultado de este
suceso podemos obtener problemas de contención de disco o cuellos de botella en el
sistema. Normalmente reconstruimos un índice con el comando ALTER INDEX.

Es importante tener actualizadas las estadísticas de la base de datos. Para saber si las
estadísticas se están lanzando correctamente podemos hacer una consulta sobre la tabla
dba_indexes y ver el campo last_analyzed para observar cuando se ejecutaron sobre ese
índice las estadísticas.

Blevel (branch level) es parte del formato del B-tree del índice e indica el número de
veces que Oracle ha tenido que reducir la búsqueda en ese índice. Si este valor está por
encima de 4 el índice deberá de ser reconstruido.

ALTER INDEX <index_name> REBUILD;

Para reconstruir una partición de un índice podríamos hacer los siguiente:

ALTER INDEX <index_name> REBUILD PARTITION <nb_partition> NOLOGGING;

Nota: En algunos casos cuando alguno de los índices tiene algún tipo de corrupción no
es posible reconstruirlo. La solución en este caso es borrar el índice y recrearlo.

Unidad 5: Seguridad
5.1 Respaldo y Recuperación

cvi
 El respaldo es uno de los pasos más importantes que puedes dar para proteger tu
información. Cuando algo sale mal, como fallas en disco duro, borrado accidental de
archivos o infecciones por malware, son tu último recurso. En esta edición, te
explicamos cómo respaldar tu información y preparar una estrategia adecuada para ti.

Qué Respaldar y Cuándo

Existen dos aspectos fundamentales para decidir qué respaldar: la información que
hayas generado o que sea importante para ti, como documentos, fotografías o videos;
o toda, incluyendo tu sistema operativo y cualquier programa que hayas instalado. El
primer aspecto limita el proceso de respaldo, mientras que el segundo hace que sea
más fácil recuperar el sistema en caso de un fallo completo. Si no estás seguro de qué
respaldar, respalda todo. A continuación, tendrás que decidir qué tan seguido respaldar
tu información. Lo más común es hacerlo cada hora, diariamente, semanalmente, etc.
Para usuarios caseros, los programas de respaldo personal como Time Machine de
Apple o Copias de seguridad y restauración de Windows, permitirán fijar un horario
automático de respaldo “prográmalo y olvídate”. Otras soluciones ofrecen “protección
continua”, en la cual los archivos nuevos o modificados son respaldados
inmediatamente tan pronto sean cerrados. Si perteneces a una organización con
muchas computadoras, quizás te gustaría definir tu propio calendario. Sería bueno que
consideraras cuánta información estás dispuesto a perder en el peor de los casos. Por
ejemplo, si respaldas diariamente, puedes perder una jornada de trabajo si tu
computadora falla al final del día. Muchas organizaciones programan respaldos diarios
fuera de las horas pico para minimizar el impacto la operación normal.

Cómo Respaldar

En general, existen dos recursos en los que puedes respaldar tu información:

medios físicos o almacenamiento en la nube. Ejemplos de medios físicos incluyen
DVD’S, dispositivos USB, cintas magnéticas o discos duros adicionales. Evita respaldar
en el mismo dispositivo que contiene los archivos originales. Cuando uses medios
físicos asegúrate de etiquetarlos, tanto interna (en el nombre del archivo) como
externamente (sobre el dispositivo), para que puedas identificar fácilmente fecha y hora
del respaldo.

Puedes almacenar el respaldo en un contenedor con llave, a prueba de fuego y de

agua, dependiendo del medio que elegiste. Una opción más robusta es almacenar
copias de tus respaldos fuera de las instalaciones. Para respaldos personales, puede
ser tan simple como almacenarlos en casa de un miembro de la familia o en una caja
de seguridad. Las organizaciones quizá deseen contratar un servicio profesional para

cvii
transportar y almacenar los respaldos de forma segura. Dependiendo de qué tan
sensibles sean y dónde se almacenen los respaldos, tal vez convenga cifrarlos.

Muchos de estos problemas se solucionan con respaldos en la nube. Realizar copias

de seguridad en la nube es tan sencillo como instalar o configurar una aplicación en tu
computadora. Después de configurar las opciones de respaldo, archivos nuevos y
modificados son respaldados automáticamente a través de Internet en servidores del
centro de datos del proveedor.

Finalmente, necesitas decidir por cuánto tiempo conservarás tus respaldos. Es

probable que los usuarios caseros no necesiten mantenerlos por más de treinta días.
Algunas organizaciones cuentan con políticas o requerimientos legales para resguardar
por periodos más largos, así como reglas para la destrucción de respaldos obsoletos.
Si estás respaldando información de tu organización, verifica con el grupo de TI, legal o
de gestión de registros para estar seguro. Respecto a las opciones de respaldo en la
nube, es posible que te cobren con base a la cantidad de datos que respaldes, así que
es importante ser cuidadoso de no acumular una gran deuda.

Recuperación

Respaldar tu información es sólo la mitad de la batalla; ahora tienes que asegurarte

de que puedes recuperarla fácilmente. Practica regularmente tu proceso de
recuperación, tal y como harías en un simulacro de sismo, esto te ayudará a asegurar
que todo funcione correctamente en caso de necesitarlo. Comprueba por lo menos una
vez al mes que el programa de respaldos está funcionando adecuadamente. Por lo
menos trata de recuperar un archivo. Para una prueba más robusta, sobre todo para
las organizaciones, considera hacer la recuperación completa del sistema y verifica que
sea recuperable. Si no cuentas con hardware externo para la prueba de recuperación
completa del sistema, restaura archivos y carpetas importantes en una ubicación
diferente y luego verifica si recuperaste y puedes abrir todo.

5.1.1 Espejeo (Mirroring)

Base de Datos Espejo (Database Mirroring) es una configuración donde dos o tres
servidores de dase de datos, ejecutándose en equipos independientes, cooperan para
mantener copias de la base de datos y archivo de registro de transacciones (log).

Tanto el servidor primario como el servidor espejo mantienen una copia de la base
de datos y el registro de transacciones, mientras que el tercer servidor, llamado el
servidor árbitro, es usado cuando es necesario determinar cuál de los otros dos
servidores puede tomar la propiedad de la base de datos. El árbitro no mantiene una

cviii
copia de la base de datos. La configuración de los tres servidores de base de datos (el
primario, el espejo y el árbitro) es llamado Sistema Espejo (Mirroring System), y el
servidor primarioy espejo juntos son llamados Servidores Operacionales (Operational
Servers) o Compañeros (Partners).

5.1.1.1 Beneficios del Espejeo de Datos en un DBMS

La creación de reflejo de la base de datos es una estrategia sencilla que ofrece las
siguientes ventajas:

Incrementa la disponibilidad de una base de datos. Si se produce un desastre en el

modo de alta seguridad con conmutación automática por error, la conmutación por
error pone en línea rápidamente la copia en espera de la base de datos, sin pérdida de
datos. En los demás modos operativos, el administrador de bases de datos tiene la
alternativa del servicio forzado (con una posible pérdida de datos) para la copia en
espera de la base de datos. Para obtener más información, vea Conmutación de roles,
más adelante en este tema.

Aumenta la protección de los datos. La creación de reflejo de la base de datos

proporciona una redundancia completa o casi completa de los datos, en función de si el
modo de funcionamiento es el de alta seguridad o el de alto rendimiento. Para obtener
más información, vea Modos de funcionamiento, más adelante en este tema.

Un asociado de creación de reflejo de la base de datos que se ejecute en SQL

Server 2008 Enterprise o en versiones posteriores intentará resolver automáticamente
cierto tipo de errores que impiden la lectura de una página de datos. El socio que no
puede leer una página, solicita una copia nueva al otro socio. Si la solicitud se realiza
correctamente, la copia sustituirá a la página que no se puede leer, de forma que se
resuelve el error en la mayoría de los casos. Para obtener más información, vea
Reparación de página automática (grupos de disponibilidad/creación de reflejo de base
de datos).

Mejora la disponibilidad de la base de datos de producción durante las

actualizaciones. Para minimizar el tiempo de inactividad para una base de datos
reflejada, puede actualizar secuencialmente las instancias de SQL Server que
hospedan los asociados de creación de reflejo de la base de datos. Esto incurrirá en el
tiempo de inactividad de solo una conmutación por error única. Esta forma de
actualización se denomina actualización gradual. Para obtener más información, vea
Instalar un Service Pack en un sistema con un tiempo de inactividad mínimo para
bases de datos reflejadas.

cix
5.1.1.2 Activación de Espejeo en un  DBMS

cx
cxi
cxii