Arquitectura del Motor de almacenamiento extensible

Arquitectura del Motor de almacenamiento extensible

El almacén de Exchange se asienta sobre una base de datos llamada Motor de almacenamiento extensible (ESE). ESE es un administrador de tablas multiusuario del Método de acceso secuencial indizado (ISAM) con todas las capacidades del Lenguaje de manipulación de datos (DML) y del Lenguaje de definición de datos (DDL). ESE permite que las aplicaciones almacenen registros y creen índices para tener acceso a esos registros de distintas formas.

Existen tres versiones de ESE:

  • ESE97   El motor de base de datos de Exchange Server 5.5.
  • ESENT   El motor de base de datos de Active Directory y de muchos componentes de Microsoft Windows. A diferencia de otras versiones de ESE (que utilizan archivos de registro de cinco MB y tamaños de página de cuatro KB), la implementación de Active Directory de ESENT utiliza archivos de registro de diez MB y páginas de ocho KB.
  • ESE98   El motor de base de datos de Exchange 2000 Server y Exchange Server 2003.
Aa998171.note(es-es,EXCHG.65).gifNota:
ESE se denominaba anteriormente Joint Engine Technology (JET) Blue. JET Blue no es lo mismo que la versión de JET de Access (denominada JET Red).
 Transacciones

ESE es un motor complejo de base de datos basado en transacciones. Una transacción es un conjunto de operaciones que se tratan como una unidad atómica (indivisible). Todas las operaciones de una transacción se realizan y se guardan permanentemente, o no se lleva a cabo ninguna de ellas. Considere, por ejemplo, las operaciones implícitas cuando mueve un mensaje de la Bandeja de entrada a la carpeta Elementos enviados. El mensaje se elimina de una carpeta, se agrega a otra y se actualizan las propiedades de las carpetas. Si se produce un error, no deseará disponer de dos copias del mensaje, ni ninguna copia en absoluto, ni querrá que los valores de las propiedades de la carpeta (como el número de elementos) sean incoherentes con el contenido real de la carpeta.

Para evitar que se produzcan problemas de este tipo, ESE agrupa las operaciones en una transacción. ESE se asegura de que ninguna de las operaciones se aplique permanentemente hasta que la transacción se valide en el archivo de base de datos. Cuando la transacción se valida en el archivo de base de datos, todas las operaciones se aplican permanentemente.

En caso de que se bloquee el sistema, ESE administra también la recuperación automática durante el arranque y deshace las transacciones no validadas. Si ESE produce un error antes de que se valide una transacción, se deshace toda la transacción y es como si la transacción nunca se hubiera producido. Si ESE se bloquea después de que se valide la transacción, toda la transacción se mantiene y los cambios son visibles a los clientes.

 Transacciones ACID

Las transacciones que son así de confiables se denominan normalmente transacciones ACID. Las transacciones ACID se caracterizan por los siguientes atributos:

  • Unicidad   Este término indica que un cambio en el estado de una transacción se produce totalmente o no se produce. Los cambios de estado atómicos incluyen cambios de base de datos y mensajes y acciones en los transductores.
  • Coherencia   Este término indica que una transacción es una transformación correcta del estado. Las acciones realizadas como grupo no infringen ninguna de las restricciones de integridad asociadas al estado. Para ello es necesario que la transacción sea un programa correcto.
  • Aislamiento   Este término indica que aunque las transacciones se ejecuten simultáneamente, cada transacción percibirá que las otras se ejecutan antes o después que ella, pero no ambas cosas.
  • Durabilidad   Este término indica que en cuanto se ejecute correctamente una transacción (se valida), cambia el estado para resistir cualquier error.
 El almacén de versiones

El almacén de versiones permite que ESE realice un seguimiento de las transacciones actuales y las administre, de forma que pueda superar los requisitos de aislamiento y coherencia de la prueba ACID. El almacén de versiones mantiene una lista en memoria de las modificaciones realizadas en la base de datos.

El almacén de versiones se utiliza en las siguientes situaciones:

  • Recuperación   Si debe deshacerse una transacción, se consulta el almacén de versiones para obtener la lista de operaciones realizadas. La transacción se puede deshacer revirtiendo todas las operaciones.
  • Detección de conflictos de escritura   Si dos sesiones diferentes tratan de modificar el mismo registro, el almacén de versiones advierte este conflicto y rechaza la segunda modificación.
  • Lecturas repetibles   Cuando una sesión inicia una transacción, siempre encuentra la misma vista de base de datos, aunque otras sesiones modifiquen los registros que está consultando. Cuando una sesión lee un registro, se realiza una consulta en el almacén de versiones para determinar qué versión del registro debe ver la sesión. Las lecturas repetibles proporcionan un nivel de aislamiento que permite que cuando un cliente inicia una transacción vea el estado de la base de datos tal como estaba cuando comenzó la transacción, independientemente de las modificaciones realizadas por otros clientes o sesiones. Las lecturas repetibles se implementan mediante el almacén de versiones. Con una lista en memoria de las modificaciones realizadas en la base de datos, se puede determinar la vista de un registro que debe ver una determinada sesión.
  • Registro diferido antes de imagen   Ésta es una optimización compleja que permite a ESE registrar menos datos que otros motores de base de datos equiparables.
 Aislamiento de instantáneas

Después de iniciarse una transacción, ESE garantiza que la sesión vea una imagen única y coherente de la base de datos, tal como era al iniciarse la transacción, más los cambios realizados. Como otras sesiones pueden modificar también los datos y validar sus transacciones, estos cambios son invisibles a cualquier transacción que se inicie antes de la validación. Un usuario sólo puede modificar un registro si ve la última versión. De lo contrario, la actualización produce un error con JET_errWriteConflict. Las versiones anteriores a la última transacción se descartan automáticamente.

ESE dispone de un nivel de aislamiento de transacciones denominado Aislamiento de instantáneas. El nivel de aislamiento de instantáneas permite a los usuarios tener acceso a la última fila validada mediante una vista coherente entre transiciones de la base de datos. El aislamiento de instantáneas es un algoritmo de control de concurrencia descrito por primera vez en A Critique of ANSI SQL Isolation Levels (Crítica de los niveles de aislamiento SQL de ANSI). ESE implementa el aislamiento de instantáneas mediante el uso de lecturas repetibles.

 Estructura de la base de datos de ESE

Todos los datos incluidos en el archivo de base de datos de texto enriquecido se almacenan en árboles B. La “B” de árbol B es la abreviatura de “balanced” (equilibrado). “Árbol” hace referencia a una disposición similar a una estructura de carpetas de un sistema de archivos, donde hay una raíz que es el nodo principal de los elementos (las páginas de la base de datos), que a su vez son nodos principales de otros elementos. Los árboles B están diseñados para proporcionar un rápido acceso a los datos en disco. Como las operaciones de lectura y escritura en un disco son mucho más lentas que en memoria, un árbol B se divide en páginas de cuatro KB, lo que permite a ESE obtener los datos que necesita mediante el número mínimo de operaciones de E/S de disco. Una base de datos ESE puede contener hasta 2^32 (2 elevado a la 32ª potencia) páginas o 16 terabytes. En realidad, el tamaño de la base de datos está limitado únicamente por la capacidad de realizar copias de seguridad, restauraciones y otras operaciones de mantenimiento de la base de datos (como la desfragmentación sin conexión y las reparaciones de base de datos) en un tiempo aceptable.

 Páginas de base de datos

El tamaño de página en ESE lo define la aplicación que utiliza este motor. Por ejemplo, ESE97 (Exchange Server 5.5) y ESE98 (Exchange 2000 Server y Exchange Server 2003) utilizan páginas de cuatro KB, mientras que ESENT (Active Directory) utiliza páginas de ocho KB. Cada una de estas páginas de cuatro u ocho KB contienen punteros a otras páginas o a los datos reales almacenados en el árbol B. El puntero y las páginas de datos están entremezclados en el archivo.

Para aumentar el rendimiento allí donde es posible, las páginas se almacenan en un búfer de memoria durante todo el tiempo posible, con lo que se reduce la necesidad de tener acceso al disco. Cada página comienza con un encabezado de 40 bytes que incluye los siguientes valores:

  • pgnoThis   Este valor indica el número de la página.
  • DbtimeDirtied   Este valor indica la hora (Dbtime) en que se modificó la página por última vez.
  • pgnoPrev   Este valor indica el número de la página izquierda contigua en el mismo nodo.
  • pgnoNext   Este valor indica el número de la página derecha contigua en el mismo nodo.
  • ObjidFDP   Este valor indica el Id. de objeto de una página especial de la base de datos, denominada Padre de la página de datos (FDP), que indica el árbol B al que pertenece esta página. La página FDP se utiliza durante las operaciones de reparación.
  • cbFree   Este valor indica el número de bytes disponibles en la página.
  • cbUncommittedFree   Este valor indica el número de bytes no validados disponibles (bytes que están libres pero disponibles para usarlos en la recuperación) en la página.
  • ibMicFree   Este valor indica la posición de página para el siguiente byte disponible al principio de la página.
 Suma de comprobación de ECC

Exchange Server 2003 Service Pack 1 (SP1) presenta una nueva característica denominada Suma de comprobación de código de corrección de errores (ECC). La suma de comprobación de ECC es un nuevo formato de suma de comprobación que permite la corrección de errores de un solo bit en páginas de base de datos (en el archivo .edb, en al archivo .smt y en los archivos de registro de transacciones). Este nuevo formato de suma de comprobación utiliza 64 bits, mientras que el formato anterior utiliza 32 bits. Las bases de datos con el formato anterior se pueden utilizar con el nuevo código, pero las bases de datos con el formato actual no se pueden utilizar con versiones anteriores de ESE. Una vez actualizado el motor de base de datos, todas las páginas que se escriban en la base de datos tendrán el nuevo formato de suma de comprobación. Las páginas que se lean y no se modifiquen no tendrán el formato de suma de comprobación actualizado.

Aa998171.note(es-es,EXCHG.65).gifNota:
Después de implementar el nuevo archivo ESE.dll, al realizar una desfragmentación sin conexión, se actualiza el formato de suma de comprobación de todas las páginas de la base de datos. Esto podría aumentar sustancialmente el tiempo empleado en desfragmentar la base de datos, por lo que no es una práctica recomendable. Asimismo, tampoco se recomienda ejecutar eseutil con el modificador /k, que realiza una suma de comprobación de todas las páginas de la base de datos.

Las páginas de base de datos con el formato anterior de suma de comprobación empiezan con una suma de comprobación de cuatro bytes seguida de un número de página de cuatro bytes, que se utiliza para comprobar que la página solicitada se lee realmente del disco.

En el nuevo formato de suma de comprobación no se incluye el número de página de cuatro bytes, sino que se empieza con una suma de comprobación de ocho bytes. El número de página se utiliza como parámetro de entrada al calcular la suma de comprobación. Por tanto, si se lee la página incorrecta del disco, habrá una discrepancia de suma de comprobación.

El formato de suma de comprobación actual se compone en realidad de dos sumas de comprobación de 32 bits. La primera es una suma de comprobación XOR, calculada de forma muy similar a como se calcula en el formato anterior. El número de página se utiliza como un valor de inicialización en el cálculo de esta suma de comprobación. La segunda suma de comprobación de 32 bits es una suma de comprobación de ECC, que permite la corrección de errores de un solo bit en la página.

 Coherencia de la base de datos y errores -1018
  • Cuando se lee una página, ESE examina un indicador de la misma para ver si tiene el formato de suma de comprobación actual. A continuación, se calcula la suma de comprobación correspondiente (con el formato actual o anterior). Si hay una discrepancia entre la suma de comprobación y la suma de comprobación del formato actual, ESE intenta corregir el error. Si el error no se puede corregir automáticamente, Exchange genera un error -1018.

El almacén de Exchange puede ser el responsable de autogenerar un error -1018, si realiza alguna de las siguientes operaciones:

  • Crea una página con la suma de comprobación incorrecta.
  • Crea una página correctamente, pero indica al sistema operativo que escriba la página en un lugar incorrecto.

Si un administrador del sistema encuentra un error -1018 o ejecuta las pruebas de hardware de diagnóstico en el servidor y estas pruebas no informan de ningún problema, puede llegar a la conclusión de que Exchange Server debe ser el responsable del problema, ya que el hardware ha superado el análisis inicial.

En muchos casos, gracias a investigaciones exhaustivas realizadas por Microsoft u otros proveedores de hardware, se han sacado a la luz problemas imperceptibles en el hardware, firmware o controladores de dispositivos que son en realidad los responsables de los daños sufridos por el archivo de base de datos.

Las pruebas de diagnóstico habituales a veces no detectan todos los errores transitorios producidos por diversos motivos. Puede que los programas de diagnóstico no sean capaces de detectar los problemas del firmware o del software de los controladores. Las pruebas de diagnóstico pueden no ser capaces de simular adecuadamente procesos de ejecución prolongados o cargas complejas. Además, la incorporación de control de diagnóstico o registro de depuración podría cambiar el sistema para evitar que el problema vuelva a aparecer.

La simplicidad y estabilidad de los mecanismos de Exchange Server que generan las sumas de comprobación y escriben páginas en el archivo de base de datos sugieren que la causa del error -1018 hay que buscarla probablemente en algún elemento externo de Exchange Server. Los mecanismos de suma de comprobación y detección de páginas incorrectas son simples y confiables y, esencialmente, siguen siendo los mismos desde que se publicó por primera vez Exchange, excepto algunos pequeños cambios para adaptar las modificaciones del formato de las páginas de base de datos entre las distintas versiones de base de datos.

Una suma de comprobación se genera para una página que se va a escribir en disco después de que todos los datos se escriban en la página, incluido el propio número de página. Cuando Exchange Server agrega la suma de comprobación a la página, indica al sistema operativo Microsoft Windows Server que escriba la página en disco mediante las API estándar publicadas de Windows Server.

La suma de comprobación podría generarse correctamente para una página, pero la página podría escribirse en la ubicación incorrecta del disco duro. Esto puede deberse a un error de memoria transitoria, como una “mutación de bits”. Suponga, por ejemplo, que Exchange crea una nueva versión de la página 70. La propia página no experimenta ningún error, pero la copia del número de página utilizado por el controlador de disco o el sistema operativo se modifica aleatoriamente. Este problema se puede producir si 70 (binario 1000110) se ha cambiado a 6 (binario 000110) por una celda de memoria inestable. La suma de comprobación de la página sigue siendo correcta, pero la ubicación de la página en la base de datos es incorrecta. Exchange Server genera un error -1018 para la página cuando detecta que el número de la página lógica no coincide con la ubicación física de la página.

Se puede producir otro tipo de error de numeración de páginas (causado por Exchange Server) si Exchange Server escribe el número de página incorrecto en la propia página, pero este problema causa otros errores, no el error -1018. Si Exchange Server escribe 71 en la página 70 y después realiza correctamente la suma de comprobación en la página, la página se escribe en la ubicación 71 y supera las pruebas de número de página y suma de comprobación.

Normalmente, un único error -1018 registrado en una base de datos de Exchange Server no causa una parada de la base de datos ni produce más síntomas que la presencia del propio error -1018. La página podría estar en una carpeta a la que no se tiene acceso frecuentemente (por ejemplo, las carpetas Elementos enviados y Elementos eliminados), o en un archivo adjunto que rara vez se abra o incluso esté vacío.

Aunque es improbable que un único error -1018 cause una pérdida de datos importante, los errores -1018 siguen siendo causa de preocupación porque ponen de manifiesto que el sistema de almacenamiento no ha podido almacenar o recuperar datos de forma confiable al menos una vez. Aunque el error -1018 puede ser un problema transitorio que no se vuelva a repetir nunca, es más probable que este error sea una advertencia de un problema que podría ir agravándose con el tiempo. Aunque el primer error -1018 se produzca en una página vacía de la base de datos, no es posible saber cuál será la siguiente página que podría resultar dañada. Si una tabla global crítica resulta dañada, puede que la base de datos no se inicie, y su reparación podría ser una solución parcial o totalmente insatisfactoria.

Cuando se registre un error -1018, deberá considerar la posibilidad de que se produzca un error inminente u otro daño aleatorio en la base de datos, hasta que encuentre y elimine la causa primigenia.

 Equilibrio del árbol de base de datos

Una de las funciones principales de ESE es mantener el árbol de base de datos equilibrado en todo momento. El proceso de equilibrar el árbol termina cuando se dividen o se combinan todas las páginas. Como se ilustra en la siguiente figura, el nivel raíz del árbol siempre contiene el mismo número de nodos que el nivel de hoja y, por tanto, el árbol está equilibrado.

Árbol equilibrado
Aa998171.3b77fce3-607c-48db-bcf9-e190d7c4e197(es-es,EXCHG.65).gif
Aa998171.note(es-es,EXCHG.65).gifNota:
Aunque los árboles incluidos en una base de datos ESE se denominan normalmente árboles B, en realidad son árboles B+. Los árboles B+ incluyen todas las características de los árboles B, pero además cada página de datos del árbol B+ contiene punteros a la página contigua anterior o siguiente en la hoja. Aunque, para mantener estos punteros actualizados, hay una sobrecarga durante las operaciones de inserción o división y combinación, los punteros permiten búsquedas secuenciales más rápidas a través de los datos de la estructura de árbol B+.

Desde el punto de vista de ESE, una tabla de base de datos es un conjunto de árboles B. Cada tabla está formada por un árbol B que contiene los datos, si bien puede haber muchos árboles B de índices secundarios utilizados para proporcionar diferentes vistas de los datos. Si una columna o campo de una tabla es demasiado grande para almacenarse en el árbol B, se divide y se coloca en un árbol B distinto, denominado árbol de valores largos.

La definición de estas tablas y sus árboles B asociados se almacena en otro árbol B, que recibe el nombre de catálogo del sistema. La pérdida del catálogo del sistema es un problema grave. Por ello, ESE conserva dos copias idénticas de este árbol B en cada base de datos: una que comienza en la página cuatro y otra que comienza en la página 24.

 División

Cuando una página está a punto de llenarse, alrededor de la mitad de los datos se colocan en una página secundaria y se incluye una clave adicional en la página principal de esta página. Este proceso se realiza salvo que la página principal también esté llena. En ese caso, la página principal se divide y se agrega un puntero a la página principal de esta página. En última instancia, podría ser necesario dividir cada página de puntero hasta el bloque raíz. Si hay que dividir el bloque raíz, se inserta un nivel adicional de páginas en el árbol. Metafóricamente hablando, el árbol crece en altura.

 Combinación

Cuando una página está casi vacía, se combina con una página contigua, se actualizan los punteros de la página principal y, si es necesario, se combina la página. En última instancia, si se combina cada página de puntero hasta el bloque raíz, el árbol disminuye en altura. Para llegar hasta una hoja (a los datos), ESE comienza en el nodo raíz y sigue los punteros de página hasta llegar al nodo de hoja deseado.

 Despliegue

La estructura de un árbol B de ESE tiene un despliegue muy alto, lo que permite a ESE tener acceso a cualquier fragmento de datos de una tabla de 50 GB con cuatro lecturas de disco como máximo (tres páginas de puntero y la propia página de datos). ESE almacena más de 200 punteros de página para cada página de cuatro KB, por lo que utiliza árboles con un número mínimo de niveles principales y secundarios (llamados también árboles superficiales). ESE almacena también una clave del árbol actual que le permite buscar rápidamente por dicho árbol. El diagrama anterior es un árbol con tres niveles principal/secundarios; un árbol con cuatro niveles principal/secundarios puede almacenar muchos gigabytes de datos.

 Índices

Un árbol B tradicional sólo se indiza de un modo en concreto. Utiliza una clave, y los datos deben recuperarse mediante esa clave. Por ejemplo, los registro de la tabla de mensajes se indizan en un identificador exclusivo del mensaje, llamado Id. del servicio de transferencia de mensajes (MST). Sin embargo, es probable que un usuario desee ver los datos de la tabla de mensajes ordenados de una forma más sencilla.

Para recuperar los datos se utilizan índices, o más concretamente, índices secundarios. Cada índice secundario es otro árbol B que asigna la clave secundaria elegida a la clave principal. Con ello se obtiene un árbol B pequeño en comparación con los datos que se indizan.

Para comprender cómo se utiliza un índice secundario, piense en lo que sucede cuando un usuario cambia el modo en que se presentan los mensajes en una carpeta de mensajes. Si cambia la vista de carpeta en Outlook para que se ordene por el asunto en lugar de por la hora de recepción, Outlook hará que el almacén y ESE creen un nuevo índice secundario en la tabla de carpetas de mensajes.

Cuando cambie por primera vez las vistas en una carpeta de gran tamaño, observará que esta operación tarda algún tiempo. Si examina atentamente el servidor, apreciará un pequeño pico en la actividad de disco. Cuando vuelva a cambiar a esa vista, el índice ya se habrá creado y la respuesta será mucho más rápida.

Los árboles B de índice secundario de los servicios Almacén de información Microsoft Exchange se conservan durante ocho días. Si no se utilizan, el servicio los elimina mediante una operación en segundo plano.

 Valores largos

Una columna o registro de ESE no puede abarcar una página en el árbol B de datos. Hay valores (como PR_BODY, que es el cuerpo de un mensaje) que superan el límite de 4 KB de una página. Se denominan valores largos. El árbol B de valores largos de una tabla se utiliza para almacenar dichos valores.

Si se introduce un fragmento de datos en una tabla ESE demasiado grande para incluirse en el árbol B de datos, se divide en páginas de cuatro KB y se almacena en el árbol B de valores largos de la tabla. El registro del árbol B de datos contiene un puntero al valor largo. Este puntero se denomina Id. del valor largo (LID) e indica que el registro tiene un puntero a LID 256.

 Formato de registros

Un conjunto de árboles B representa una tabla, y una tabla es un conjunto de filas. Las filas se denominan también registros. Un registro se compone de muchas columnas. El tamaño máximo de un registro y, por tanto, el número de columnas que aparecen en un único registro, está regido por el tamaño de página de la base de datos menos el tamaño del encabezado. ESE tiene páginas con un tamaño de cuatro KB. Por tanto, el tamaño máximo del registro es aproximadamente 4.050 bytes (4.096 bytes menos el tamaño del encabezado de página).

 Tipos de datos de columna

Cada definición de columna debe especificar el tipo de datos que se almacenan en la columna. ESE admite los tipos de datos que se describen en la tabla siguiente.

Tipos de datos de columna del Motor de almacenamiento extensible

Tipos de datos de columna Descripción
Bit NULO, 0 o distinto de 0
Bytes sin signo Entero de 1 bytes sin signo
Short Entero de 2 bytes con signo
Short sin signo Entero de 2 bytes sin signo
Long Entero de 4 bytes con signo
Long sin signo Entero de 4 bytes sin signo
LongLong Entero de 8 bytes con signo
Moneda Entero de 8 bytes con signo
IEEE Single Número de 4 bytes de punto flotante
IEEE Double Número de 8 bytes de punto flotante
Date Time Fecha-hora de 8 bytes (fecha íntegra, hora fraccionaria)
GUID Identificador exclusivo de 16 bytes
Binario Cadena binaria, longitud <= 255
Texto Cadena ANSI o Unicode, longitud <= 255 bytes
Binario largo Cadena binaria de valores largos, longitud < 2 GB
Texto largo Cadena ANSI o Unicode de valores largos, longitud < 2 GB

Los tipos de datos de columna se dividen en dos clases. La primera clase la componen las columnas fijas y variables. La segunda clase son las columnas etiquetadas. Cada columna se define como una estructura FIELD de 16 bytes más el tamaño del nombre de columna.

Cuando se crea una tabla en una base de datos ESE, la tabla se define mediante una matriz de estructuras FIELD. Esta matriz identifica las distintas columnas de la tabla. Dentro de esta matriz, cada columna se representa mediante un valor de índice, llamado Id. de columna. Es similar a una matriz normal en la que se puede hacer referencia a miembros de la matriz por el Id., como matriz[0], matriz[1], etc. A las columnas se tiene acceso rápidamente mediante el Id., pero una búsqueda por nombre de columna requiere un examen lineal de toda la matriz de estructuras FIELD.

 Columnas fijas y variables

Las columnas fijas tienen una longitud de datos fija. Cada registro ocupa una cantidad definida de espacio de registro, aunque no se defina ningún valor. Los Id. de tipos de datos del 1 al 10 se pueden definir como columnas fijas. Cada tabla puede definir hasta 126 columnas fijas (Id. de columna del 1 al 127).

Las columnas variables pueden tener hasta 256 bytes de datos. En el registro se almacena una matriz de posiciones con el conjunto mayor de columnas variables. Cada columna requiere dos bytes. Los Id. de tipos de datos 10 y 11 se pueden definir como columnas variables. Cada tabla puede definir hasta 127 columnas variables (Id. de columna del 128 al 256).

 Columnas etiquetadas

ESE define las columnas que rara vez aparecen o que aparecen varias veces en un solo registro como columnas etiquetadas. Las columnas etiquetadas no definidas no producen sobrecarga de espacio. Una columna etiquetada puede aparecer varias veces en el mismo registro. Si una columna etiquetada está representada en un índice secundario, este índice se utiliza para hacer referencia a cada aparición de la columna.

Las columnas etiquetadas pueden contener una longitud variable e ilimitada de datos. El Id. y la longitud de la columna se almacenan con los datos. Todos los tipos de datos se pueden definir como columnas etiquetadas. Cada tabla puede definir hasta 64.993 columnas etiquetadas.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s