RESUMIR LAS ESTRUCTURAS DE ALMACENAMIENTO.
La Base de Datos Oracle ofrece una
completa abstracción del Almacenamiento Lógico del Físico. El almacenamiento de
datos Lógico es en segmentos. Hay varios tipos de segmentos; un segmento típico
es una Tabla. Los segmentos son almacenados físicamente en DataFiles. La
abstracción del Almacenamiento Lógico del almacenamiento físico es logrado
atraves de Tablespaces. La relación entre las estructuras Lógicas y físicas,
así como sus definiciones, son mantenidas en el Diccionario de Datos.
ESTRUCTURAS FISICAS DE LA BASE DE DATOS.
Hay tres tipos de archivos que conforman
una Base de Datos Oracle, mas algunos otros que existen externamente de la Base
de Datos y son, estrictamente hablando, opcionales. Los archivos requeridos son
los ControlFiles, Los Redo Log Files, y los DataFiles. Los archivos externos
que generalmente se presentan(Hay otros, necesarios para las opciones
avanzadas) son el Initialization Parameter File, El Password File, El Archive
Redo Log Files y el Log y Trace Files.
EXAMEN.
¿Cuáles son los tres tipos de archivos que
deben estar presentes en una Base de Datos? El ControlFile, El Online Redo Log
Files y cualquier número de DataFiles.
EL CONTROLFILE.
Primer punto de la terminología: algunos
DBAs dirán, que una Base de Datos puede tener múltiples ControlFiles, mientras
que otros dirán que tiene un ControlFile, del cual puede haber múltiples
copias. En este libro seguiremos la última terminología. Que se ajusta a Oracle
Corporation de frases tales como “Multiplexación de ControlFiles”, que
significa crear múltiples copias.
El ControlFile es pequeño, pero vital.
Contiene referencias al resto de la Base de Datos: La ubicación de los Online
Redo Log Files y de los DataFiles y de los más recientes Archive Log Files si
la Base de Datos esta en Modo Archive Log. Este también almacena la información
necesaria para mantener la integridad de la Base de Datos: varios números de
secuencia critica (critical sequence numbers) y marcas de tiempo (timestamps),
por ejemplo. Si la Herramienta Recovery Manager (Descrita en el Capitulo 16 y
17) se utiliza para Backups, entonces los detalles de estos Backups serán
almacenados en el ControlFile. El ControlFile suele ser no más que unos pocos
Megabytes, pero no puede sobrevivir sin este.
Cada Base de Datos tiene un ControlFile,
pero un buen DBA creará siempre múltiples copias del ControlFile, de modo que
si se daña una copia, la Base de Datos sobrevivirá. Si todas las copias del ControlFile
se pierden, es posible recuperar, pero nunca debe encontrarse en esa situación.
Usted no tiene que preocuparse de mantener las copias multiplexadas del
ControlFiles sincronizadas. Oracle se ocupara de eso. Su mantenimiento es
automático. El único control es el número de copias que tiene, y donde
ponerlos.
Si obtiene el número de copias, o su
ubicación, incorrecto en el tiempo de creación de la Base de Datos, usted puede
añadir o remover copias posteriores, o moverlos. Pero usted debería tener en
cuenta que cualquier tipo de operaciones requerirá el tiempo de inactividad,
por lo que es una buena idea hacerlo bien desde el principio. No hay bien o mal
cuando determina el número de copias a tener. El mínimo es uno; el máximo
posible es ocho. Todas las organizaciones deben tener un manual de normas de
DBA, que expone algo así “Todas las Bases de Datos en Producción tendrá tres
copias de los ControlFiles, en tres dispositivos diferentes” tres son un numero
escogido solo para ilustración, pero un numero con que muchas organizaciones
son felices. Si no hay tales indicaciones de este tipo, alguien debería
escribirlos. No hay regla que dice que dos copias son demasiadas pocas, o siete
copias es demasiado; hay solo estándares corporativos, y el trabajo del DBA es
asegurarse de que las Bases de Datos se ajustan a estos.
El daño a cualquier copia de ControlFile
hará que la instancia de base de datos terminar inmediatamente. No hay manera
de evitar esto: Oracle Corporation no permite operar una Bases de datos con
menos que el número de ControlFiles que se han solicitado. La técnicas de
multiplexación o relocalización son tratados en el Capitulo 15.
EL ONLINE REDO LOG FILES.
El Redo Log almacena una cadena continua
en orden cronológico de cada change vector aplicado a la Base de Datos. Esta
será la mínima cantidad de información requerida para reconstruir, o rehacer,
todo el trabajo que ha sido hecho. Si un DataFile(o la totalidad de la Base de
Datos) es dañado o destruido, estos change vector pueden ser aplicados a los
respaldos del DataFile para rehacer de nuevo el trabajo, trayéndolo hacia
adelante en el tiempo, hasta el momento en que ocurrió el daño. El Redo Log
consiste en dos tipos de archivos: El Online Redo Log Files (Que son
requeridos) y el Archive Log Files (Que son opcionales). Cada Base de Datos
tiene al menos dos Online Redo Log Files, pero como con los ControlFiles, un
buen DBA crea múltiples copias para cada Online Redo Log File. El Online Redo
Log consiste en grupos de Online Redo Log Files, cada archivo será conocido
como un miembro. Una Base de Datos Oracle requiere al menos de dos grupos de al
menos un miembro cada uno para su funcionamiento. Usted puede crear más de dos
grupos por razones de rendimiento, y más de un miembro por grupo por seguridad.
El requerimiento de un mínimo de dos grupos es para que un grupo pueda aceptar
los cambios actuales, mientras que el otro grupo está respaldando (o
archivando-archived, para usar el término correcto).
EXAMEN.
Cada Base de Datos debe tener al menos dos
Grupos de Online Redo Log File para funcionar, cada grupo debería tener al
menos dos miembros por seguridad.
Uno de los Grupos es el Grupo Actual: los
cambios son escritos al actual Online Redo Log File Group por el LGWR. Mientras
las sesiones de usuario actualizan datos en el Database Buffer Cache, también
escriben los change vector mínimos al Redo Log Buffer. LGWR limpia
continuamente este buffer a los archivos que conforman el actual Online Redo
Log File Group. Los archivos Log son de tamaño fijo; por lo tanto, los archivos
que conforman el grupo actual se llenarán. LGWR entonces realizará lo que es
llamado un switch de log. Esto hace que el segundo grupo actual y comienza a
escribir. Si su Base de Datos se configura correctamente, los procesos ARCn entonces
archivará los miembros Log File que conforman el primer grupo, cuando el
segundo grupo llena, LGWR volverá al primer grupo, haciendo este actual, y
sobrescribiéndola; ARCn entonces archivará el segundo grupo. Por lo tanto, El
Online Redo Log File Groups se utilizan en forma circular, y cada switch
generará un archivado de Redo Log File.
Como con el ControlFile, si usted tiene
múltiples miembros por grupo (y debe!) usted no tiene preocuparse por
mantenerlos sincronizados. LGWR se asegurará de que escriba a todos,
paralelamente, así mantenerlos idénticos. Si usted pierde un miembro del grupo,
mientras tenga un miembro sobreviviente, la base de datos puede continuar con
su funcionamiento.
El tamaño y número de sus grupos Log File
son una cuestión de ajuste. En general, usted elije el tamaño adecuado a la
cantidad de actividad que usted anticipa. El tamaño mínimo es cincuenta
megabytes, pero algunas bases de datos muy activas necesitarán levantar esto a
varios gigabytes sino son llenados en muy pocos minutos. Una Base de Datos muy
ocupada puede generar megabytes de Redo en un segundo, mientras una base de
datos estática puede generar solo unos pocos megabytes en una hora. El número
de miembros por grupo dependerá de que nivel de tolerancia a fallos se considere
necesario, y es una cuestión que se documenta en los estándares corporativos.
Sin embargo, no tiene que preocuparse acerca de esto en el tiempo de la
creación de la Base de Datos. Puede mover sus Online Redo Log Files alrededor,
añadir o eliminar, y crear unos de diferentes tamaños cuando desee en cualquier
momento más tarde. Estas operaciones se realizan en línea y no requieren tiempo
de inactividad por lo que son transparentes para los usuarios finales.
LOS DATAFILES.
El tercer tipo de archivo requerido para
conformar una Base de Datos es el DataFile. Como un mínimo, debe tener dos
DataFiles, serán creados en la Base de Datos en tiempo de creación. Con
versiones previas de Oracle, usted puede crear una Base de Datos con solo un
DataFile-10g y 11g requieren dos, al menos uno cada uno, para el Tablespace
SYSTEM (que almacena el Diccionario de Datos) y el Tablespace SYSAUX (que
almacena datos que son auxiliares para el Diccionario de Datos.). Usted, sin
embargo. Tendrá mucho más que eso cuando su base de datos es útil, y
generalmente creará unos pocos más para iniciar.
Los DataFiles son el repositorio para los
Datos. Su tamaño y número son prácticamente ilimitados. Una pequeña Base de
Datos, de solo unos pocos gigabytes. Podría tener solo media docena de
DataFiles de solo unos pocos cientos de megabytes cada una. Una Base de Datos
más grande podría tener miles de DataFiles, cuyo tamaño es limitado solo por la
capacidad del sistema operativo host y el hardware.
Los DataFiles son las Estructuras Físicas
visible al Administrador de Sistema. Lógicamente, son el Repositorio de los
segmentos que contienen los datos del usuario que los programadores consideran,
y también para los segmentos que conforman el Diccionario de Datos.
Un segmento es una estructura de almacenamiento
para datos; segmentos típicos son Tablas e Índices. Los DataFiles pueden ser
renombrados, cambiados de tamaño, mover, agregar o eliminar en cualquier
momento de la vida útil de la Base de Datos, pero recuerde que algunas
operaciones en algunos DataFiles pueden requerir tiempo de inactividad.
A nivel del Sistema Operativo, un DataFile
consiste en un número de bloques del Sistema Operativo. Internamente, los
DataFiles son formateados en Oracle Blocks. Estos bloques son numerados
consecutivamente dentro de cada DataFile. El tamaño del Block es fijado cuando
el DataFiles es creado. Y en la mayoría de circunstancias, será el mismo en
toda la Base de Datos. El tamaño del Block es una cuestión para ajuste y puede
variar (con limites dependiendo de la plataforma) desde 2KB hasta 64 KB. No hay
relación entre el tamaño de Oracle Block y el tamaño de Block del Sistema
Operativo.
EN EL TRABAJO.
Muchos DBA tienen gusto de emparejar el
Tamaño de Block de sistema Operativo al tamaño de block de Oracle Block. Por
motivos de rendimiento, los Blocks de Sistema Operativo nunca deben ser más
grandes que los Oracle Blocks, pero no hay razón no tenerlos más pequeños. Por
ejemplo, un 1KB de tamaño de block de sistema operativo y 8KB de tamaño de
Oracle Block es perfectamente aceptable.
EXAMEN.
Procesos Servidor leen desde el DataFile;
DBWn escribe al DataFile.
Dentro de un block, hay una sección de
encabezado y un área de datos, y posiblemente algún espacio libre. La sección
de encabezado contiene información tal como el directorio de la fila, que lista
la ubicación dentro del área de datos de las filas en el Block (si el Block se
está utilizando para un segmento de tabla) y también la información de bloqueo
de fila si hay una transacción trabajando sobre la fila en el block. El área de
datos contiene los datos, tales como filas si es parte de un segmento de tabla,
o llaves de índices si el block es parte de un segmento de índice.
Cuando una sesión de usuario necesita
trabajar sobre los datos para cualquier propósito, el proceso servidor que
soporta la sesión, localiza el block relevante en el disco y copia este en un
buffer libre en el Database Buffer Cache. Si los datos en el bloque entonces se
cambian (El buffer es sucio) ejecutando un comando DML contra él, Eventualmente
DBWn escribirá el Block de regreso al DataFile en Disco.
Los DataFiles deberían ser respaldados
regularmente. A diferencia los ControlFiles y los Online Redo Log Files, no
pueden ser protegidos por multiplexación (Aunque pueden, por supuesto, estar
protegidos por el sistema operativo y las instalaciones de hardware, tales como
RAID.). Si un DataFile es dañado, este puede ser restaurado desde un Backup y
entonces recuperado (para recuperar un DataFile significa traerlo hasta la
fecha) aplicando todo el Redo generado desde que el Backup fue hecho. El Redo
necesario extrae los Change Vectors en el Online y Archive Redo Log Files. Las
rutinas para respaldar DataFiles, restaurar y la recuperación son descritos en
capítulos 16 y 17.
OTROS ARCHIVOS DE BASE DE DATOS.
Estos archivos existen externamente a la
Base de Datos. Son, para fines prácticos, necesaria-pero no son estrictamente
parte de la Base de Datos.
El INSTANCE PARAMETER FILE. Cuando una Instancia Oracle es iniciada,
construir las estructuras SGA en memoria y los procesos background iniciará de
acuerdo a los ajustes en el Archivo de Parámetros. Este es el único archivo que
necesita existir para iniciar una instancia. Hay varios cientos de parámetros,
pero solo uno es requerido: El parámetro DB_NAME. Todos los demás tienen
valores default. Así el archivo de parámetros puede ser bastante pequeño, pero
debe existir.
EL PASSWORD FILE. Los usuarios establecen sesiones presentando un Username y
un Password. El servidor Oracle autentifica esto contra definiciones de
usuarios almacenadas en el Diccionario de Datos. El Diccionario de Datos es un
conjunto de tablas en la Base de Datos. Es por lo tanto inaccesible si la base
de datos no está abierta: Hay ocasiones cuando un usuario necesita ser
autentificado antes de que el diccionario de datos esté disponible: cuando el
necesita para iniciar la Base de Datos, o incluso para crearlo. Un archivo de
contraseñas externa es uno de los medios de hacerlo. Contiene un pequeño número
(típicamente menos que la mitad de una docena) de nombres de usuarios y
Password que existen fuera del diccionario de datos, y que por tanto se puede
utilizar para conectarse a una instancia ante el diccionario de datos está
disponible. Crear el fichero de contraseñas se describe en el capítulo 4.
ARCHIVE REDO LOG FILES. Cuando un Online Redo Log File está lleno.
El proceso ARCn copia fuera de la Base de Datos a un Archive Redo Log File. Una
vez hecho esto, el Archive Log ya no forma parte de la Base de Datos. Es, sin
embargo, esencial si es siempre necesario para restaurar un respaldo de
DataFile, y Oracle proporciona herramientas para administrar los Archive Redo
Log Files.
ALERT LOG Y TRACE FILES. El Alert Log es un flujo continuo de
mensajes con respecto a ciertas operaciones críticas que afectan la instancia y
la Base de Datos. No se registra todo: solo los eventos que son considerados
realmente importantes, como el inicio y apagado; cambios en las estructuras
físicas de la base de datos; cambios en los parámetros que controlan la
instancia. Archivos Trace son generados por procesos background cuando detectan
condiciones de error, y a veces para reportar ciertas acciones.
ESCENARIO Y SOLUCION
Usted está asumiendo el control la
gerencia de una base de datos, y no hay documentación del almacenaje físico o
lógico, o el uso de la memoria. ¿Cómo puede usted resolverse cómo se configura?
Debe ejecutar consultas en numerosas vistas que describen la base de datos y su
contenido. Existen herramientas gráficas que le ayudarán a-muchos se incluyen
con Oracle Enterprise Manager, pero todos estos están haciendo es ejecutar
consultas contra puntos de vista, y el formato de los resultados de una forma
bonita.
Peor aún, la base de datos está en un
sistema operativo y hardware con el que no está familiarizado. ¿Eso significa
que no se puede gestionar? No, él doesnt-pero puede que necesite alguna ayuda.
En principio, la arquitectura de Oracle es idéntico en todas las plataformas, y
cuando se está trabajando desde dentro de una herramienta de Oracle como SQL *
Plus o SQL Developer, realmente no importa lo que la plataforma es. Dicho esto,
a menos que esté razonablemente competentes a trabajar desde el sistema
operativo
del sistema, así, necesitará mucha ayuda
de los administradores del sistema. El trabajo en equipo! Una habilidad
esencial en soporte de TI.
LAS ESTRUCTURAS LOGICAS DE BASE DE DATOS.
Las estructuras físicas que conforman una
Base de Datos son visibles como Archivos de Sistema Operativo a los
Administradores de sistemas. Sus usuarios ven las estructuras lógicas tales
como tablas. Oracle utiliza el término segmento para describir cualquier
estructura que contenga datos. Un típico segmento es una Tabla, que contiene
filas de datos, pero hay más de una docena posible de tipos de segmentos en una
Base de Datos. De particular interés (para efectos de este examen) son
segmentos Tablas, segmentos Índices, segmentos Undo, todos los cuales son
investigados en detalle más adelante. Por ahora. Usted no necesita saber más
que las tablas contienen filas de información; que los índices son un mecanismo
para obtener rápido acceso a cualquier registro en particular, y que los
segmentos Undo son estructuras de datos utilizadas para almacenar información
que pudiera necesitarse para revertir, o roll back, cualquier transacción que
usted no desea hacer permanente.
Así los Administradores de Sistemas ven
DataFiles Físicos; programadores ven segmentos Lógicos. Oracle abstrae el
almacenamiento Lógico del almacenamiento físico por medio de Tablespace. Un
Tablespace es lógicamente una colección de uno o más segmentos, y físicamente
una colección de uno o más DataFiles. Dicho en términos de análisis relacional,
existe una relación muchos-a-muchos entre Segmentos y DataFiles: una tabla
puede ser cortada atraves de muchos DataFiles (una tabla puede estar almacenada
en varios DataFiles), un DataFile puede contener bits de muchas tablas.
Mediante la inserción de la entidad Tablespace entre los segmentos y los
archivos, Oracle resuelve esta relación mucho-a-muchos.
Una serie de segmentos deben ser creados
en tiempo de creación de la Base de Datos: estos son los segmentos que
conforman el Diccionario de Datos. Estos segmentos son almacenados en dos
Tablespaces, llamados SYSTEM y SYSAUX. El Tablespace SYSAUX era nuevo con la
versión 10g: en versiones anteriores, la totalidad del Diccionario de Datos
entraba en SYSTEM. El proceso de creación de la Base de Datos debe crear al
menos estos dos Tablespaces, con al menos un DataFile cada uno, para almacenar
el Diccionario de Datos.
EXAMEN.
El Tablespace SYSAUX se debe crear en
tiempo de creación de la Base de Datos en Oracle 10g y posteriores. Si usted no
los especifica, será creado por defecto.
Un segmento consistirá de un número de
Blocks. Los DataFiles son formateados en Block, y estos Blocks son asignados a
segmentos como el segmento Grow. Por que administrar espacio en un Block sería
un proceso desgastante, los bloques son agrupados en extents (extensiones), los
Blocks son agrupados en extents (extensiones). Un Extents (extensión) es una
serie de Blocks que son numerados consecutivamente dentro de un DataFile, y los
segmentos crecerán agregando nuevos extents a ellos. Estos Extents
(extensiones) no necesitan ser adyacentes entre sí, o incluso en el mismo
DataFile; pueden venir de cualquier DataFile que es parte del Tablespace dentro
del cual el segmento reside.
La Figura 2-3 muestra la Jerarquía de
almacenamiento de Datos de Oracle, con la separación del almacenamiento lógico
del físico.
La figura muestra las relaciones entre las
estructuras de almacenamiento. Lógicamente, un Tablespace puede contener muchos
segmentos, cada uno constituido de muchos extents (extensiones). Un Extents
(extensión) es un conjunto de Block Oracle. Físicamente, un DataFile se compone
de muchos Block de Sistema Operativo asignados por cualquier sistema de
archivos del sistema operativo que utiliza. Las dos partes del modelo están
conectadas por las relaciones que demuestran que un Tablespace puede consistir
de múltiples DataFiles, y el nivel más bajo que un Block Oracle consistirá de
varios Block de sistema operativo.
EL DICCIONARIO DE DATOS
El Diccionario de Datos son los Metadatos:
Datos sobre Datos. Este describe la Base de Datos, tanto físicamente y
Lógicamente, y su contenido. Definiciones de Usuario, Información de Seguridad,
restricciones de Integridad, y (en versiones 10g y posteriores) información de
monitoreo de rendimiento son todos parte del Diccionario de Datos. Se almacena
como un conjunto de Segmentos en el Tablespace SYSTEM y SYSAUX.
De muchas maneras, los segmentos que
conforman el Diccionario de Datos son Segmentos como cualquier otro: solo
Tablas e Índices. La diferencia crítica es que las Tablas del Diccionario de
Datos son generadas en tiempo de creación de la Base de Datos, y no permite
acceso a ellos directamente. No hay nada que impida a un DBA inquisitiva de
investigar el diccionario de datos directamente, pero si usted hace cualquier
actualización a este, usted puede causar daños irreparables a su Base de Datos,
y ciertamente Oracle Corporation no le apoyará. La creación del Diccionario de
Datos es parte del Proceso de creación de la Base de Datos. Este es mantenido
posteriormente por comandos del Lenguaje de Definición de Datos. Cuando usted
emita el comando CREATE TABLE, usted de hecho esta insertando filas en las
Tablas del Diccionario de Datos, como son con comandos tales como CREATE USER o
GRANT. Para consultar el Diccionario, Oracle provee un conjunto de Vistas. Las
vistas vienen en tres formas: Prefijos DBA_, ALL_ o USER_. La matoria de las
vistas vienen en todas las tres formas. Cualquier vista con prefijo USER_ será
llenado con filas describiendo objetos que pertenecen al usuario que consulto
la vista. Así que no existen dos personas podrán ver el mismo contenido. Si el
usuario SCOTT consulta USER_TABLES, se mostrará información acerca de sus tablas,
si usted consulta USER_TABLES, se mostrará información acerca de sus tablas.
Cualquier vista con Prefijo ALL_ serán llenadas con filas describiendo objetos
a los tiene Acceso. Así ALL_TABLES contendrá filas describiendo sus propias
tablas, más filas describiendo Tablas que pertenezcan a cualquiera y que le han
dado permiso para ver.
EXAMEN.
Cual vista muestra todas las Tablas en la
Base de Datos? DBA_TABLES, no ALL_TABLES.
Cualquier vista con prefijo DBA_ tendrá
filas para cada objeto en la Base de Datos. Así DBA_TABLES tendrá un registro
por cada Tabla en la Base de Datos, no importa quién lo creó. Estas vistas son
creadas como parte del proceso de creación de la Base de Datos, junto con un
gran número de paquetes PL/SQL que son proveídos por Oracle para ayudar a las
Administradores de Bases de Datos en la Administración de la Base de Datos y
programadores en el Desarrollo de Aplicaciones. El Código PL/SQL es también
almacenado en el Diccionario de Datos.
La relación entre Tablespace y DataFile es
mantenida en el ControlFile de la Base de Datos. Esto lista todos los
DataFiles, indicando que Tablespace son parte de. Sin el ControlFile, no hay
forma de que una instancia pueda localizar los DataFiles y luego identificar
aquellos que conforma el Tablespace SYSTEM. Solo cuando el Tablespace SYSTEM ha
sido abierto es posible para la instancia acceder al Diccionario de Datos,
momento en el cual se hace posible abrir la Base de Datos.
El Código SQL siempre referirá a objetos
definidos en el Diccionario de Datos. Para ejecutar un simple Query contra una
tabla, El Servidor Oracle debe primero consultar el Diccionario de Datos para
buscar si la tabla existe, y las columnas que la componen. Entonces debe
encontrar donde, físicamente, esta la tabla. Esto requiere la lectura del Mapa
de Extents del Segmento. El mapa de Extents lista todos los extents que
conforman la Tabla, con el detalle cuyo el DataFile cada Extents está adentro,
en qué bloque del DataFile el Extents comienza, y para cuánto Blocks continúa.
EJERCICIO 2-4
INVESTIGAR LAS EXTRUCTURAS DE
ALMACENAMIENTO EN SU BASE DE DATOS.
En este ejercicio usted creara un Segmento
Tabla, y luego resuelve donde se encuentra físicamente.
1.Conéctese a la Base de Datos como
usuario SYSTEM.
2.Crear una Tabla sin el nombramiento de
un Tablespace-esta será creada en su Tablespace por default, con un Extents:
create table tab24 (c1 varchar2(10));
3.Identifique el Tablespace en el que
reside la Tabla, el tamaño del Extent, el numero de archivo en el que el
Extents está dentro, y en que Block del archivo el Extents inicia.
select tablespace_name, extent_id, bytes,
file_id, block_id from dba_extents where owner='SYSTEM' and
segment_name='TAB24';
4.Identificar el archive por nombre:
sustituir la file_id de la consulta previa cuando se le solicite:
select name from v$datafile where
file#=&file_id;
5.Resolver exactamente donde en el archive
esta el Extents, en términos de cuantos bytes en el archivo inicia. Esto
requiere descubrir el tamaño de bloque del tablespace. Enter the block_id and
tablespace_name returned by the query in Step 3 when prompted.
select block_size * &block_id from
dba_tablespaces where tablespace_name='&tablespace_name';
The illustration shows that the table
exists in one extent that is 64 KB large. This extent is in the file
/home/db11g/app/db11g/oradata/orcl/ system01.dbf and begins about 700 MB into
the file.
RESUMEN DE CERTIFICACION.
Este capítulo cubre la Instancia Oracle y
Arquitectura de Base de Datos. Muchos temas serán tratados más completo en
capitulo posteriores. Pero en este punto la arquitectura general de la
Instancia (Consiste por estructuras de memoria compartida y procesos) la Base
de Datos (consiste de archivos en disco), y sesiones de usuarios (un proceso
servidor y un proceso usuario) deben ser claras.
DOS MINUTOS.
Describir la Arquitectura de
Instancia-Única
- Un Servidor Oracle es una Instancia
conectada a una Base de Datos.
- Una instancia es un bloque de memoria
compartida y un conjunto de procesos Background.
- Una Base de Datos es un conjunto de
Archivos en Disco.
- Una sesión de usuario es un proceso
usuario conectado a un proceso servidor.
Explicar las Estructuras de Memoria.
- La memoria compartida de la Instancia es
la System Global Area (La SGA).
- Las sesiones tienes una memoria privada
esta es Program Global Area (La PGA).
- La SGA consiste de una serie de
subestructuras, algunos de los cuales son Requeridos (El DataBase Buffer Cache,
El Log Buffer y la Shared Pool) y algunos de los cuales son opcionales (el
Large Pool, el Java Pool y la Streams Pool).
- Las estructuras SGA pueden ser cambiadas
de tamaño dinámicamente y gestionada dinámicamente, con la excepción del Log
Buffer.
Describir las Estructuras de Procesos.
- Los procesos de sesión de servidor son
lanzados en demanda cuando los usuarios se conectan.
- Los procesos Background son lanzado en
el inicio de la instancia y persisten hasta que termina la instancia.
- Los procesos servidor leen desde la Base
de Datos; Los procesos Background escriben a la Base de Datos.
- Algunos procesos Background siempre
estarán presentes (en particular SMON, PMON, DBWn, LGWR, CKPT y MMON); otros se
ejecutaran dependiendo que opciones han sido habilitadas.
Resumiendo las Estructuras de
almacenamiento.
- Existen tres tipos de archivos
requeridos en una Base de Datos: El ControlFile, El Online Redo Log Files y los
DataFiles.
- El ControlFile almacena información de
integridad y referencias del resto de la Base de Datos.
- El Online Redo Log almacena Change
Vector recientes aplicados a las Base de Datos.
- Los DataFiles almacenan los datos.
- Archivos Externos incluyen el Parameter
File, el Password File, Archive Redo Logs, y el Log y Trace Files.
- El almacenamiento Lógico de Datos (Segments)
se abstrae del almacenamiento físico de datos (DataFiles) mediante los
Tablespaces.
- Un Tablespace puede estar conformado de
múltiples DataFiles.
- Segments están conformados de múltiples
extents, que consisten de múltiples Oracle Blocks, que consisten de múltiples
Blocks de sistema operativo.
- Un Segment puede tener extents en varios
DataFiles.
MY BUENO ME AYUDO BASTANTE
ResponderEliminarExcelente aporte te agradezco, me ha sido muy util.
ResponderEliminar