7.1. COMPRENDIENDO TABLESPACES Y DATAFILES.

COMPRENDIENDO TABLESPACES Y DATAFILES.

Los datos son almacenados Lógicamente en Segmentos y físicamente en DataFiles. La entidad Tablespace abstrae los dos, un Tablespace puede contener muchos segmentos y estar conformado de muchos DataFiles. No hay una relación directa entre un segmento y un DataFile. Los DataFiles pueden existir como archivos en un Sistema de Archivos o (desde la versión 10g en adelante) sobre dispositivos Automatic Storage Management (ASM).

EL MODELO DE ALMACENAMIENTO DE DATOS ORACLE.

La separación del almacenamiento lógico del físico es una parte necesaria del paradigma de Base de Datos Relacional. Esto significa que los programadores no tienen posibilidad de encontrar donde, físicamente, un ítem de dato se encuentra. Si pudieran encontrar, su software estaría atado a la maquina en el que fue escrito. E incluso así, algo tan trivial como renombrar o mover un archivo rompería la aplicación. El paradigma relacional indica que programadores deben dirigirse solo a las estructuras lógicas y dejar a la Base de Datos gestione la asignación de estructuras físicas. Esto significa que el almacenamiento físico puede ser reorganizado, o la Base de Datos entera movida completamente a un hardware diferente y sistema operativo diferente, y la aplicación no estará consciente de cualquier cambio.

La figura 7-1. Muestra el modelo de almacenamiento Oracle esbozado como un diagrama entidad relación, con las estructuras lógicas a la izquierda y las estructuras físicas a la derecha.

Hay una relación dibujada como una línea de puntos: una relación muchos-a-muchos entre Segmentos y DataFiles. Esta relación es de puntos, porque no debe estar allí. Como bueno ingenieros relacionales, DBAs no permiten relaciones de muchos-a-muchos. La resolución de esta relación en una estructura normalizada en la que está todo el modelo de almacenamiento. Tomando las entidades en la figura uno por uno.

La entidad Tablespace resuelve la relación muchos-a-muchos entre Segmentos y DataFiles. Un Tablespace puede contener muchos segmentos y puede estar conformado de muchos DataFiles. Esto significa que cualquier Segmento puede ser propagado atraves de múltiples DataFiles, y cualquier DataFiles puede contener todos o parte de muchos segmentos. Esto resuelve muchos problemas de almacenamiento. Algunos viejos sistemas de administración de Bases de Datos utilizan una relación uno-a-uno entre segmentos y archivos: cada Tabla o Índice se almacena como un archivo separado. Esto plantea dos problemas terribles para sistemas grandes. Primero, en una aplicación podría tener miles de tablas e índices e incluso más; la gestión de muchos miles de archivos es una tarea terrible para los administradores de sistemas. Segundo, el tamaño máximo de una tabla está limitado por el tamaño máximo de un archivo. Incluso si el sistema operativo moderno no tiene límites prácticos, bien puede haber limitaciones impuestas por el ambiente de hardware subyacente. El uso de Tablespace pasa por alto ambos problemas. Los Tablespace son identificados por nombres, único en la Base de Datos.

La entidad Segmento representa cualquier objeto de Base de Datos que almacena datos y por lo tanto requiere espacio en un Tablespace. Su segmento típico es una Tabla, pero hay otros tipos de segmentos, en particular los segmentos Índice (descritos en el Capitulo 9) y los segmentos Undo (descritos en el Capitulo 11). Cualquier segmento puede existir en un solo Tablespace, pero el Tablespace puede propagarse atraves de todos los archivos que conforman el Tablespace. Esto significa que el tamaño de las Tablas no está sujeto a las limitaciones por el entorno en el tamaño máximo de archivo. Como muchos segmentos pueden compartir un único Tablespace, es posible tener poco más segmentos que DataFiles existentes. Los segmentos son objetos del esquema, identificados por el nombre del segmento calificado con el nombre de propietario del esquema. Tenga en cuenta que los objetos de esquema de programación (tales como procedimientos PL/SQL, vistas o secuencias) no son segmentos: ellos no almacenan datos, y existen dentro del Diccionario de Datos.

El Oracle Block es la unidad de E/S para la Base de Datos. Los DataFiles son formateados en Oracle Blocks, numerados consecutivamente. El tamaño de los Oracle Blocks es fijo para un Tablespace (hablando en general, es lo mismo para todos los Tablespace en la Base de Datos). Por defecto (con la versión de 11g) es 8 KB. Una fila puede ser solo un par de cientos de bytes, y así podría haber muchas filas almacenadas en un Block, pero cuando una sesión quiere una fila, el bloque completo será leído desde disco en el Database Buffer Cache. Similarmente, si solo una columna de una fila se ha modificado en el Database Buffer Cache, El DBWn (eventualmente) escribe el Block completo de nuevo en el DataFile de donde vino, sobrescribirá la versión anterior. El tamaño de un Oracle Block puede variar de 2KB a 16 KB en Linux o Windows, hasta 32 KB en otros Sistemas Operativos. El tamaño del Block es controlado por el parámetro DB_BLOCK_SIZE. Esto nunca será cambiado después de la creación de la Base de Datos, porque es utilizado para dar formato a los DataFiles que conforman el Tablespace SYSTEM. Si llega a ser evidente después que el tamaño del Block es inapropiado, el único curso de acción es crear una nueva Base de Datos y transferir todo en ella. Un Block se identifica por su número dentro de un DataFile: el número de Block solamente no es suficiente.

El manejo de espacio un Block a la vez sería una tarea agobiante, así que los Blocks son agrupados en Extents. Un Extents es un conjunto de Oracle Block numerados consecutivamente dentro de un DataFile. cada segmento consistirá en uno o más Extents, numerados consecutivamente. Estos Extents pueden estar en cualquier y todos los DataFiles que conforman el Tablespace. Un Extents puede ser identificado de la dimensión del Segmento (Los Extents son numerados consecutivamente por segmento, iniciando desde cero) o la dimensión del DataFile (cada segmento esta en un archivo, comenzando en cierto número de bloque de Oracle).

Un DataFile es, físicamente, compuesto de un número de Blocks de Sistema Operativo. Como se estructuran los DataFiles y los Blocks de sistema operativo son enteramente dependientes del Sistema de Archivos del Sistema Operativo. Algunos sistema de archivos tienen limitaciones conocidas y por lo tanto no se utilizan para sistemas modernos (Por ejemplo el Viejo MSDOS el sistema de archivos FAT podría manejar archivos solo de 4GB y solo 512 de ellos por directorio). La mayoría de las Bases de Datos serán instaladas en sistemas de archivos sin límites prácticos, tales como NTFS en Windows o ext3 en Linux. Las alternativas a los sistemas de archivos para almacenamiento de DataFiles son Dispositivos en Crudo o ASM. Dispositivos en Crudo son ahora muy rara vez utilizados para almacenamiento de DataFiles debido a cuestiones de gestión (Problemas). ASM se describe brevemente en la sección posterior de este capítulo, Automatic Storage Management (ASM).

Un Block de Sistema operativo es la Unidad E/S para su Sistema de Archivos. Un proceso puede leer solo un byte de disco, pero el Sistema de E/S tiene que leer un Block de Sistema Operativo. El tamaño del Block de sistema operativo es configurable para algunos Sistemas de Archivos. (Por ejemplo, cuando formateas un sistema de archivo NTFS usted puede elegir de 512 Byte a 64 KB). Pero típicamente el Administrador de Sistemas lo dejara en el predeterminado (512 B para NTFS o 1 KB para ext3). Esto es porque la relación entre Oracle Blocks y Blocks de sistema operativo es usualmente uno a muchos. No hay razón para no coincidir con el tamaño de block de sistema operativo al tamaño de oracle block si su sistema de archivo le permite hacer esto. La configuración que se debe evitar siempre estaría donde los bloques del sistema operativo eran más grandes que los bloques de Oracle.

SEGMENTOS, EXTENTS, BLOCKS Y FILAS.

Los Datos se almacenan en Segmentos. La vista de Diccionario de Datos DBA_SEGMENTS describe cada segmento en la Base de Datos. Esta consulta muestra los tipos de segmentos en una Base de Datos simple. Los contadores son bajos porque no hay una aplicación real instalada.

SQL> select segment_type,count(1) from dba_segments group by
segment_type
2 order by segment_type;


SEGMENT_TYPE COUNT(1)
------------------ ----------
CLUSTER 10
INDEX 3185
INDEX PARTITION 324
LOB PARTITION 7
LOBINDEX 760
LOBSEGMENT 760
NESTED TABLE 29
ROLLBACK 1
TABLE 2193
TABLE PARTITION 164
TYPE2 UNDO 10
11 rows selected.
SQL>

En resumen, y en el orden en que es más probable que se refieren a un DBA, estos tipos son los segmentos.

• TABLE. Estas son las Tablas Heap-Estructuradas: Filas de longitud variable, en orden aleatorio. A pesar que un segmento típico es una Segmento Tabla, nunca olvide que la tabla no es el segmento, y que hay organizaciones de tablas más complejas que utilizan otros tipos de segmentos.

• INDEX. Los índices son listas ordenadas de valores claves, cada uno con un puntero, El ROWID, a la localización física de la fila. El ROWID específica que Oracle Block de que DataFile la Fila es, y el número de fila dentro del Block.

• TYPE2 UNDO. Estos son los segmentos UNDO (nadie se refiere a ellos como segmentos TYPE2 UNDO) que almacenan las versiones anteriores al cambio de los datos que son necesarios para proporcionar integridad transaccional: RollBack, Consistencia de Lectura y Aislamiento (rollback, read consistency, and isolation.).

• ROLLBACK. Los Segmentos Rollback no se deben utilizar el funcionamiento normal desde la versión 9i en adelante. La versión 9i se introdujeron gestión automática de UNDO, que se basa en los Segmentos UNDO. Habrá siempre un Segmento RollBack que protege las transacciones utilizadas parea crear la Base de Datos, pero no debe de usarse posteriormente.

• TABLE PARTITION. Una Tabla puede ser Dividida en muchas particiones. Si se hace esto, entonces las particiones serán Segmentos Individuales, y la propia Tabla no será un Segmento en Absoluto: existe solo como el total de sus particiones. Cada partición de la Tabla de una Heap Table está estructurada como una Heap Table, en su propio segmento. Estos segmentos pueden estar en diferentes Tablespace, esto significa que es posible extender una tabla atraves de múltiples Tablespace.

• INDEX PARTITION. Un índice por default estará en un Segmento, pero los índices pueden ser particionados. Si usted esta particionado sus Tablas, generalmente particionara los índices de las tablas también.

• LOBSEGMENT, LOBINDEX, LOB PARTITION. Si una columna se define como un Tipo de Objeto de Objeto Grande, entonces solo un puntero se almacena en la propia Tabla: un puntero a una entrada en un segmento separado donde las columnas de datos residen actualmente. LOBs puede tener índices creados en ellos para el acceso rápido a los datos dentro de los objetos, y LOBs puede también ser particionado.

• CLUSTER. Un Cluster es un segmento que pueden contener varias tablas. En contraste con particionamiento, que permite propagar una tabla atraves de muchos segmentos, Cluster permite des normalizar muchas tablas en un segmento.

• NESTED TABLE. Si una columna de una Tabla se define como un tipo de objeto definido por el usuario  que si mismo tenga columnas, si una columna, entonces la columna puede ser almacenada en su propio segmento, como una Tabla anidada (NESTED TABLE).

Cada segmento tiene uno o más Extents. Cuando se crea un segmento, Oracle asignará un Extent a este, en cualquier Tablespace se especifica. Eventualmente, como los datos se introducen, el Extent se llenará. Oracle entonces asignará un segundo Extent, en el mismo Tablespace pero no necesariamente en el mismo DataFile. si sabe que un segmento va a necesitar más espacio, usted puede manualmente asignar un Extent, La figura 7-2 muestra como identificar con precisión donde esta un segmento.

En la figura, el primer comando crea la Tabla HR.NEWTAB, confiar totalmente en los valor predeterminados para el almacenamiento. Entonces, una consulta contra DBA_EXTENTS muestra que el segmento consiste de solo un Extent, Extent número cero. Este Extents está en el archivo 4 y es 8 block de largo. El primero de los 8 Blocks es en el Block numero 1401. El tamaño del Extent es 64 KB, que muestra que el tamaño del Block es 8 KB. El siguiente comando obligará a Oracle a asignar otro Extent en el Segmento, incluso también si el primer Extent no está lleno. La siguiente consulta muestra que este nuevo Extent, numero 1, está también en el Archivo numero 4 y inicia inmediatamente después del Extent Cero. Observe que no está claro de este ejemplo sí o no el Tablespace consiste de varios DataFiles. Porque el Algoritmo de Oracle que utiliza para calcular donde asignar el siguiente Extent no utiliza simplemente DataFiles alternadamente. Si el Tablespace consiste de múltiples DataFiles, puede anular la elección de Oracle con esta sintaxis:

ALTER TABLE tablename ALLOCATE EXTENT STORAGE (DATAFILE 'filename');

EN EL TRABAJO

Pre asignar espacio agregando Extent manualmente puede proporcionar un beneficio en rendimiento pero es una enorme cantidad de Trabajo. No lo hará por más que muy pocas tablas o índices que tengan excepcionalmente una tasa de crecimiento alta. O tal vez antes de operaciones de carga.

La última consulta en la figura 7-2 va a la vista DBA_DATA_FILES para determinar el nombre del archivo en el cual los Extents fueron asignados, y el nombre del Tablespace a cual el DataFile pertenece. Para identificar las Tablas en el Tablespace, uno puede también consultar DBA_SEGMENTS.

EN EL TRABAJO.

Usted puede consultar DBA_TABLES para encontrar en que Tablespace una Tabla reside, pero esto solo funcionará para Tabla sin particiones- no para tablas particionadas, donde cada partición en su propio segmento y puede estar en un diferente Tablespace. Particionamiento permite una Tabla (almacenar como múltiples segmentos) abarca un Tablespace.

Un Extent consiste de un conjunto de Block numerado consecutivamente. Cada Block tendrá un Área de Header y un Área Data. El Header es de tamaño variable y crece hacia debajo de la parte superior del Block. Entre otras cosas, contiene un directorio de filas (que muestra en que parte del Block cada fila inicia) y bloque de información de la fila. El área de datos se llena de abajo hacia arriba. Entre las dos puede (o no puede) haber un área de espacio libre. Los eventos que hará que el encabezado de un bloque de crecer incluir la inserción de filas y bloqueo. El área de datos inicialmente estará vacio y se llenará con filas que son insertadas (o claves de índices son insertados, en el caso de un block de un segmento de índice). El espacio libre consigue hecho fragmentos mientras que se insertan, se suprimen, y se ponen al día las filas (que pueden hacer el tamaño de una fila cambiar), pero eso no tiene importancia porque todo esto sucede en la memoria, después el Block ha sido copiado en un Buffer en el Database Buffer Cache. El espacio libre. El espacio libre se une en un área contigua cuando es necesario, y siempre antes de que el DBWn escriba el bloque de nuevo a su datafile.

AUTOMATIC STORAGE MANAGEMENT (ASM)

Los DataFiles puede existir en cuatro tipos de dispositivos: Local File Systems, Clustered File Systems, Asm Disk Groups y Raw Devices:

• Archivos sobre un File Local System Estos son los simples DataFiles; existen como archivos normales del sistema operativo en una estructura de directorios sobre el disco directamente conectados a la computadora que ejecuta la instancia. En un Windows o Linux, estos pueden ser internos IDE o DATA. En un Hardware más sofisticado, generalmente serian discos SCSI o unidades externas.

• Archivos sobre un Clustered File System Un Clustered File System son discos externos, montados concurrentemente en más de una computadora. El Clustered File System media el acceso a los discos de los procesos que funcionan en todas las computadoras en el cluster. Utilizando el Clustered File Systems en una forma de implementación RAC: La Base de Datos debe de residir en discos accesibles a todas las instancias que la van abrir. Clustered File Systems se pueden comprar a vendedores del Sistema Operativo o Oracle Corporation’s OCFS (Oracle Clustered File System) es una excelente alternativa. OCFS fue primero escrito para Linux y Windows y viene con la versión de la Base de Datos 9i; con 10 g que fue portado a todos los otros sistemas principales de funcionamiento.

• Archivos en Raw Devices Es posible crear DataFiles sobre discos sin Sistema de archivos en absoluto. Esto todavía soportado pero en realidad es solo una anomalía histórica. En los malos viejos tiempos antes de los sistemas de archivos en clúster (o ASM) existía, dispositivos en bruto fueron la única forma de implementar una base de datos de servidor paralelo. Parallel Server se fue reemplazado por 9i RAC en la liberación de bases de datos.

• Archivos sobre ASM Devices ASM es una instalación introducida con la versión 10g. Este es una alternativa a Sistemas de Archivos.

EN EL TRABAJO

Algunas personas afirman que Raw Devices dan mejor rendimiento. Con el disco contemporáneo y la tecnología de sistemas de archivos, esto no es casi cierto. E incluso si era verdad, son tan difíciles de manejar que ningún DBA sano quiere utilizarlos.

En resumen, ASM es un Gestor de Volúmenes Lógicos proporcionado por Oracle y viene con la Base de Datos. La idea general es que usted tome un montón de discos sin formato, darles a Oracle, y deje a Oracle con ella. Los administradores de sistema no tienen la necesidad de preocuparse sobre la creación de sistemas de archivos en absoluto.

Un Gestor de volúmenes Lógicos proporcionados por el Sistema Operativo, o tal vez por un tercero tales como Veritas, tomará un conjunto de volúmenes físicos y presentara al sistema operativo como volúmenes lógicos. Los volúmenes Físicos podrían ser discos completos, o podrían ser particiones de discos. Los volúmenes lógicos se verán con la aplicación software como discos, pero el almacenamiento subyacente de cualquier volumen lógico no puede ser un volumen físico sino varios. En estos volúmenes lógicos que los sistemas de archivos entonces están creados.

Un volumen lógico puede ser mucho mayor que cualquiera de los volúmenes físicos de lo que la componen. Por otra parte, el volumen lógico puede ser creado con características que exploten el rendimiento y seguridad de uso de múltiples volúmenes físicos. Estas características son striping y la duplicación (mirror) de datos. Striping Data atraves de múltiples volúmenes físicos da enormes ganancias de rendimiento. En principio, si un archivo se distribuye atraves de dos discos, debería ser posible leerlo en la mitad de tiempo que tomaría si se tratara todo en un disco. El rendimiento mejorará geométricamente, en proporción al número de discos asignado al volumen lógico. Mirroring da seguridad. Si un volumen lógico consiste de dos o más volúmenes físicos, entonces cada Block de sistema operativo escrito a un volumen puede ser escrito simultáneamente al otro volumen. Si una copia es dañada, el administrador de volúmenes lógicos leerá del otro. Si hay más de dos volúmenes físicos, un grado mayor de reflejo a ser posible, proveyendo tolerancia a fallo en los eventos de fallos a múltiples discos. Entonces, cada Block de sistema operativo escrito a un volumen puede ser escrito simultáneamente a otro volumen.

Algunos Sistemas Operativos (tales como AIX) incluyen un Administrador de Volúmenes Lógicos como standard, con otros sistemas operativos esto es opcional (y con cargo) extra. Históricamente, algunos de los sistemas operativos más simples (tales como Windows y Linux) no tenían mucho apoyo para los gestores de volúmenes lógicos en los absoluto. Si un administrador de volúmenes lógico está disponible, puede requerir considerable tiempo y habilidad para configurarlo óptimamente.

ASM es un gestor de volúmenes lógicos diseñado para archivos de Bases de Datos Oracle. La definición de archivo de bases de datos es amplia. Además de los verdaderos archivos de Bases de Datos (controlfile, online redo log files y datafiles) ASM puede también almacenar archivos Backup, archivos archived redo log y archivos Datapump (Todos estos archivos serán detallados en los capítulos siguientes). No puede ser utilizado para el Oracle Home, o para el Alert Log y Trace Files.

EXAMEN

ASM puede almacenar solo archivos de Bases de Datos, no los binarios. El Oracle Home debe siempre ser sobre en sistemas de archivos convencionales.

Para configurar ASM, los administradores de sistemas deben proporcionar los volúmenes físicos. Estos pueden ser los discos actuales, particiones de discos o dispositivos establecidos por una SAN (storage area network) o alguna forma de almacenamiento conectado a red.

Las normas sobre qué tipo de dispositivo puede ser usado y como deben ser configurados son estrictas pero no inusual. El DBA entonces agrupa estos volúmenes físicos (conocido como Discos ASM) en volúmenes lógicos (conocidos como Grupos de Discos ASM). Los grupos de discos son formateados en allocation units (unidades de asignación), que son Block contiguos de espacio sobre un volumen físico. El tamaño por default de una allocation unit es 1MB, pero este puede ser incrementado hasta 64 MB si la naturaleza de la aplicación es tal (por lo general, un Data Warehouse) que se benefician de esto. El nivel más bajo de almacenamiento es el Block físico. Este será determinado por la geometría de los discos.

Cada archivo creado sobre un Grupo de Discos ASM será siempre stripes atraves de todos los discos del ASM que componen el grupo. Esto no es configurable; se trata de una ventaja de rendimiento con ningún inconveniente y se aplica siempre. Mirroring es configurable pero no está activado por defecto. En términos generales, ASM da ahora un rendimiento superior a cualquier gestor de volúmenes lógicos de terceros. Esto es porque es un sistema Oracle consciente que puede stripes archivos inteligentemente.

Los diferentes tipos de archivos tienen diferentes patrones de acceso que hagan diferente striping y estrategias de Mirroring apropiadas, porque stripes ASM en el nivel del archivo (algo que el nivel volumen, la manera un sistema RAID hace), que puede manejar está mucho mejor que un administrador de volumen del sistema operativo dependiente de lógica. Los striping de nivel archivo y el Mirroring también significa que los discos adicionales se pueden agregar o quitar de un grupo uno a la vez en caso de ser necesario. Por ejemplo, si un grupo de volumen se compone de dos discos y un tercero se añade, ASM se iniciará automáticamente una operación de reequilibrio para ponerla en uso por restriping los archivos ASM: moverá una mezcla de primaria y refleja las extensiones de los discos existentes en el nuevo disco. Semejantemente, si un disco sale del grupo (debido a un comando de la administración o una falta), el grupo del disco se reequilibrará inmediatamente a los espejos perdidos reinstantiate. Reequilibrando operaciones ocurra en el fondo, mientras que la base de datos es funcionando.

Una característica clave de la ASM es que puede funcionar como un sistema de archivos en clúster. Históricamente, muchos sistemas operativos tenido problemas con la fabricación de un sistema de archivos disponibles en dos o más nodos al mismo tiempo (esto no es lo que los archivos a través de un archivo del servidor que está conectado directamente de almacenamiento), que sea necesario para base de datos de CCR. Para los sistemas operativos que son compatibles con sistemas de archivo cluster, a menudo son una opción del impuesto. ASM es un sistema de archivos en clúster disponibles en todas las plataformas principales y viene con la licencia de base de datos Oracle.

A key feature of ASM is that it can work as a clustered file system. Historically, many operating systems had problems with making a file system available on two or more nodes concurrently (this is not making files available through a file server—it is directly attached storage), as is necessary for RAC database. For operating systems that do support clustered file systems, often they are a chargeable option. ASM is a clustered file system available on all mainstream platforms and bundled with the Oracle database license.

EXAMEN

Archivos ASM stripes, no volúmenes, El Mirroring es opcional, striping no es.

EN EL TRABAJO

ASM obtiene fantástico rendimiento. Funciona para Bases de Datos Single-Instance, así como Bases de Datos RAC.

La figura 7-3 bosqueja la estructura ASM como un diagrama entidad-relación. Tenga en cuenta la asignación uno a uno de un Archivo ASM a un Archivo de Base de Datos, que podría ser cualquiera de los tipos de archivos que soporta ASM. Uno podría dibujar una relación muchos a muchos entre Archivos ASM y Discos ASM, pero esto se resuelve vía los grupos de discos ASM o las unidades de asignación.

EJERCICIO 7-1.
INVESTIGANDO LAS ESTRUCTURAS DE ALMACENAMIENTO DE DATOS EN LA BASE DE DATOS.

En este ejercicio, usted ejecutar consultas para documentar la estructura física de una Base de Datos. Los comandos deben ser ejecutados interactivamente desde SQL PLUS o Database Control, pero tendrían sentido guardarlos como un script que pueden ser ejecutados contra cualquier Base de Datos como parte de reportes regulares sobre uso del espacio en la Base de Datos.

1. Conéctese a la Base de Datos como usuario SYSTEM.
2. Determine el nombre y tamaño de los ControlFiles:
select name,block_size*file_size_blks bytes from v$controlfile;
3. Determine el nombre y tamaño de los miembros Online Redo Log Files:
select member,bytes from v$log join v$logfile using (group#);
4. Determine el nombre y tamaño de los DataFiles y TempFiles:
select name,bytes from v$datafile union all select name,bytes from v$tempfile;