Base de Datos Relacional

Bienvenido.
SQLite es una biblioteca de software que implementa un autónomo , sin
servidor , sin configuración , transaccional motor de base de datos
SQL. SQLite es el mayor despliegue de motor de base de datos SQL en el
mundo. El código fuente de SQLite está en el dominio público .

Patrocinadores
El desarrollo continúo y el mantenimiento de SQLite es patrocinado en
parte por el Consorcio SQLite miembros, entre ellos:

Bentley - Comprehensive software solutions for
Sustaining Infrastructure.

Mozilla - Working to preserve choice and
innovation on the internet.

Nokia is the world leader in mobility, driving the
transformation and growth of the converging
internet and communications industries.
Oracle - Software. Hardware. Complete.

Adobe revolutionizes how the world engages with
ideas and information - anywhere, anytime, and
through any medium.

Bloomberg - A world leader in
information technology.

financial-

Corp.

SQLite es autónomo
SQLite es en gran medida autónomo. Se requiere apoyo muy mínima de
bibliotecas externas o desde el sistema operativo. Esto hace que sea muy
adecuado para su uso en dispositivos integrados que carecen de la
infraestructura de soporte de un ordenador de sobremesa. Esto también
hace que SQLite apropiado para uso dentro de las aplicaciones que
necesitan para funcionar sin modificaciones en una amplia variedad de
equipos de diferentes configuraciones.
SQLite está escrito en ANSI-C y debe ser fácilmente compilado por
cualquier compilador de C estándar. Se hace un uso mínimo de la
biblioteca estándar de C. Las funciones de la biblioteca C sólo se requiere
llamados son:
memset ()
memcpy ()
memcmp ()
strcmp ()
malloc (), free () y realloc ()
SQLite se puede configurar en el tiempo de inicio para usar un buffer
estático en lugar de llamar a malloc () para la memoria que necesita. La
fecha y hora funciones SQL proporcionadas por SQLite requieren algún
apoyo adicional biblioteca C, pero estas funciones también pueden ser
omitidas de la acumulación con las opciones de tiempo de compilación.
Las comunicaciones entre SQLite y el sistema operativo y el disco están
mediadas a través de un intercambiables VFS capa. Módulos de VFS para
Unix y Windows se proporcionan en el árbol de código fuente. Es una
simple cuestión de idear un VFS alternativas para los dispositivos
integrados.
Para un funcionamiento seguro en entornos multi-hilo, SQLite requiere el
uso de mutex. Bibliotecas mutex apropiadas se vinculan automáticamente
para plataformas Win32 y POSIX. Para otros sistemas, primitivas de
exclusión mutua se pueden añadir en el tiempo de inicio usando
el sqlite3_config ( SQLITE_CONFIG_MUTEX , ...) de la interfaz. Mutex sólo
son necesarios si SQLite es utilizado por más de un hilo a la vez.
El código fuente de SQLite está disponible como una " fusión "- un único
archivo de código fuente de C grande. Los proyectos que quieran incluir
SQLite pueden hacerlo simplemente dejando caer el archivo una fuente
(llamado "sqlite3.c") y su correspondiente encabezado ("sqlite3.h") en su

Corp.

árbol de código fuente y compilarlo junto con el resto del código. SQLite
no se vincula contra ninguna biblioteca externa (distinta de la biblioteca
de C, como se describió anteriormente) y no requiere ningún apoyo de
construcción especial.

SQLite es Serverless
La mayoría de los motores de base de datos SQL se ejecutan como un
proceso servidor independiente. Los programas que quieran acceder a la
base de datos se comunican con el servidor utilizando algún tipo de
comunicación entre procesos (normalmente TCP / IP) para enviar
peticiones al servidor y recibir de vuelta los resultados. SQLite no funciona
de esta manera. Con SQLite, el proceso que quiere acceder a la base de
datos lee y escribe directamente de los archivos de base de datos en el
disco. No hay ningún proceso de servidor intermediario.
Hay ventajas y desventajas para estar sin servidor. La principal ventaja es
que no hay ningún proceso de servidor separado para instalar, configurar,
configurar, inicializar, administrar y solucionar problemas. Esta es una
razón por SQLite es un " cero-configuración del motor de base de
datos". Los programas que utilizan SQLite no requieren el apoyo
administrativo para la creación del motor de base de datos antes de
ejecutarlas. Cualquier programa que es capaz de acceder al disco es capaz
de utilizar una base de datos SQLite.
Por otro lado, un motor de base de datos que utiliza un servidor puede
proporcionar una mejor protección contra errores en la aplicación de
cliente - punteros callejeros en un cliente no puede alterar la memoria en
el servidor. Y debido a que un servidor es un solo proceso persistente, que
es capaz de controlar el acceso de base de datos con más precisión, lo
que permite para el bloqueo de grano más fino y mejor concurrencia.
La mayoría de los motores de base de datos SQL se cliente / servidor
basado. De los que son sin servidor, SQLite es el único conocido a este
autor que permite que múltiples aplicaciones accedan a la misma base de
datos al mismo tiempo.

SQLite es una base de datos de configuración cero
SQLite no tiene por qué ser "instalado" antes de su uso. No existe un
procedimiento "setup". No existe un proceso de servidor que necesita ser
iniciados, detenidos o bien configurados. No hay necesidad de un
administrador para crear una nueva instancia de base de datos o asignar
permisos de acceso a los usuarios. SQLite no utiliza archivos de

Corp.

configuración. Nada de lo que hay que hacer para decirle al sistema que
se está ejecutando SQLite. No se requieren acciones para recuperarse
después de una caída del sistema o fallo de alimentación. No hay nada
que solucionar.
SQLite funciona.
Otros motores de base de datos pueden ejecutar grandes una vez que
llegue a ir. Pero hacer la instalación y configuración inicial a menudo
puede ser intimidante.

SQLite es transaccional
Una base de datos transaccional es aquella en la que todos los cambios y
las consultas parecen ser atómico, consistente, aislada y durable
( ACID ). SQLite implementa serializables transacciones que son atómica,
consistente, aislada y durable, incluso si la transacción es interrumpida
por una caída del programa, una caída del sistema operativo o un corte de
energía a la computadora.
Estamos aquí, reiteramos y ampliamos la frase anterior para dar énfasis:
Todos los cambios dentro de una única transacción, con SQLite bien
ocurrir completamente o en absoluto, aun cuando el acto de escribir el
cambio hacia el disco se ve interrumpida por
una caída del programa,
una caída del sistema operativo, o
un corte de energía.
La afirmación del párrafo anterior se comprueba ampliamente en el
conjunto de pruebas de regresión SQLite usando un instrumento de
prueba especial que simula los efectos de un archivo de base de datos de
fallos del sistema de funcionamiento y fallas de energía.

Commit atómico En SQLite
1.0 Introducción
Una característica importante de las bases de datos transaccionales como
SQLite es "confirmación atómica". Medios confirmación atómica que todos
los cambios de base de datos dentro de una sola transacción ocurren o
ninguno de ellos se producen. Con la confirmación atómica, es como si
muchas diferentes escrituras en las diferentes secciones del archivo de
base de producirse instantáneamente y simultáneamente. Hardware real
Corp.

serializa escribe a almacenamiento masivo, y la escritura de un solo sector
tiene una cantidad limitada de tiempo. Por lo tanto, es imposible escribir
realmente muchos sectores de un archivo de base de datos al mismo
tiempo y / o de manera instantánea. Pero la lógica confirmación atómica
dentro de SQLite hace que parezca como si los cambios de una
transacción se escriben de forma instantánea y simultáneamente.
SQLite tiene la importante propiedad de que las transacciones parecen ser
atómica, incluso si la transacción se ve interrumpido por un fallo del
sistema operativo o de corte del suministro eléctrico.
En este artículo se describen las técnicas utilizadas por SQLite para crear
la ilusión de confirmación atómica.
La información de este artículo sólo se aplica cuando SQLite funciona en
"modo de rollback", o en otras palabras, cuando SQLite no está utilizando
una escritura anticipada registro . SQLite todavía apoya confirmación
atómica cuando escritura anticipada registro está habilitado, pero logra
atómica comprometerse por un mecanismo diferente de la descrita en
este artículo. Consulte la documentación de la ventaja de escritura de
registro para obtener más información sobre cómo SQLite apoya
confirmación atómica en ese contexto.

2.0 Supuestos Hardware
A lo largo de este artículo, le llamaremos el dispositivo "disco" de
almacenamiento masivo a pesar de que el dispositivo de almacenamiento
masivo podría realmente ser memoria flash.
Suponemos que el disco que está escrito en trozos que llamamos un
"sector". No es posible modificar cualquier parte del disco más pequeño
que un sector. Para cambiar una parte del disco más pequeño que un
sector, hay que leer en el sector completo que contiene la parte que desea
cambiar, hacer el cambio, y luego escribir de nuevo el sector completo.
En un disco giratorio tradicional, un sector es la unidad mínima de
transferencia en ambas direcciones, tanto para la lectura y la escritura. En
la memoria flash, sin embargo, el tamaño mínimo de una lectura suele ser
mucho más pequeño que una escritura mínima. SQLite sólo se refiere a la
cantidad mínima de escritura y por lo que para los efectos del presente
artículo, cuando decimos "sector" nos referimos a la cantidad mínima de
datos que se pueden escribir en almacenamiento masivo en una sola vez.
Antes de SQLite versión 3.3.14, un tamaño de sector de 512 bytes se
supuso en todos los casos. Había una opción en tiempo de compilación

Corp.

para cambiar esto, pero el código no se había probado con un valor
mayor. El supuesto sector de 512 bytes parecía razonable ya que hasta
hace muy poco tiempo todos los discos duros usados un sector de 512
bytes internamente. Sin embargo, recientemente ha habido un esfuerzo
para aumentar el tamaño de sector de los discos a 4096 bytes. Además, el
tamaño del sector de la memoria flash es normalmente mayor que 512
bytes. Por estas razones, las versiones de SQLite principio con 3.3.14
tienen un método en la capa de interfaz de sistema operativo que
interroga el sistema de archivos subyacente para encontrar el tamaño de
sector verdadera. Tal como está implementado actualmente (versión
3.5.0) este método todavía devuelve un valor codificado de 512 bytes, ya
que no hay manera estándar de descubrir el tamaño de sector verdadera
en cualquiera de Unix o Windows. Sin embargo, el método está disponible
para los dispositivos integrados fábrica para ajustar de acuerdo a sus
propias necesidades. Y hemos dejado abierta la posibilidad de llenar una
aplicación más significativa en Unix y Windows en el futuro.
SQLite ha asumido tradicionalmente que una escritura sector no es
atómica. Sin embargo, SQLite no siempre asumen que una escritura
sector es lineal. Por "lineal" queremos decir que SQLite asume que al
escribir un sector, el hardware comienza en un extremo de los datos y
escribe byte por byte hasta que llega al otro extremo. La escritura podrían
ir de principio a fin o del final al principio. Si se produce un fallo de
alimentación en el medio de un sector de escritura podría ser que parte
del sector se modificó y otra parte se deja sin cambios. El supuesto clave
de SQLite es que si alguna parte del sector se cambia, entonces o se
cambiará el primero o los últimos bytes. Así que el hardware nunca
empezar a escribir un sector en el medio y trabajar hacia los extremos. No
sabemos si este supuesto es siempre cierto, pero parece razonable.
El párrafo anterior establece que SQLite no asume ese sector escribe son
atómicos. Esto es así por defecto. Pero a partir de SQLite versión 3.5.0,
existe una nueva interfaz llamada el Sistema de Archivos Virtual ( VFS )
interfaz. La VFS es el único medio por el cual SQLite se comunica con el
sistema de archivos subyacente. El código viene con VFS defecto
implementaciones para Unix y Windows y no hay un mecanismo para la
creación de nuevos VFS implementaciones personalizadas en tiempo de
ejecución. En esta nueva interfaz VFS hay un método llamado
xDeviceCharacteristics. Este método interroga al sistema de archivos
subyacente para descubrir varias propiedades y comportamientos que el
sistema de ficheros puede o no exhibir. El método xDeviceCharacteristics
podría indicar que el sector escribe son atómicas, y si no lo indica, SQLite
tratará de sacar provecho de ello. Pero el método xDeviceCharacteristics

Corp.

predeterminado para Unix y Windows no indica sector atómico escribe y lo
que estas optimizaciones se suele omitir.
SQLite asume que el sistema operativo amortiguar escribe y que una
petición de escritura volverá antes de los datos de hecho han sido
almacenados en el dispositivo de almacenamiento masivo. SQLite asume,
además, que las operaciones de escritura serán reordenadas por el
sistema operativo. Por esta razón, SQLite hace una operación de "flush" o
"fsync" en puntos clave. SQLite asume que el color o fsync no regresará
hasta que todas las operaciones de escritura pendientes para el archivo
que se está volcando han completado. Se nos dice que los primitivos ras y
fsync se dividen en algunas versiones de Windows y Linux. Esto es
lamentable. Abre SQLite a la posibilidad de la corrupción de bases de
datos después de una pérdida de energía en el medio de un
compromiso. Sin embargo, no hay nada que SQLite puede hacer para
detectar o remediar la situación. SQLite asume que el sistema operativo
que se está ejecutando en funciona como se anuncia. Si eso no es
exactamente así, bueno, entonces esperemos que no pierde potencia con
demasiada frecuencia.
SQLite asume que cuando un archivo crece en longitud que el nuevo
espacio de archivos contiene originalmente basura y luego se rellena con
los datos realmente escritos. En otras palabras, SQLite asume que el
tamaño del archivo se actualiza antes de que el contenido del
archivo. Esta es una suposición pesimista y SQLite tiene que hacer algún
trabajo extra para asegurarse de que no causa la corrupción de base de
datos si se pierde la energía entre el momento en que el tamaño del
archivo es mayor y cuando el nuevo contenido se escribe. El método
xDeviceCharacteristics de los VFS puede indicar que el sistema de
archivos siempre escribirá los datos antes de actualizar el tamaño del
archivo. (Esta es la propiedad SQLITE_IOCAP_SAFE_APPEND para
aquellos lectores que están buscando en el código.) Cuando el método
xDeviceCharacteristics indica que los archivos de contenido está escrito
antes de que se aumentó el tamaño del archivo, SQLite puede renunciar a
algunas de sus pedantes medidas de protección de bases de datos y con
ello disminuir la cantidad de / S de disco necesario para realizar un
commit. La implementación actual, sin embargo, no hace tales supuestos
para los VFS es por defecto para Windows y Unix.
SQLite asume que un archivo borrado es atómica desde el punto de vista
de un proceso de usuario. Con esto queremos decir que si las solicitudes
de SQLite que un archivo se borrará y el poder se pierde durante la
operación de eliminación, una vez que se restablezca la energía ya sea el
archivo va a existir por completo con todo si su contenido original sin
modificaciones, o de lo contrario, el archivo no se puede ver en el sistema
Corp.

de archivos en absoluto. Si después de la conexión se restaura el archivo
sólo se elimina parcialmente, si algunos de los datos han sido alterados o
borrados, o que el archivo se ha truncado, pero no se elimina por
completo, entonces la corrupción de bases de datos dará lugar
probablemente.
SQLite supone que la detección y / o corrección de errores de bit causado
por los rayos cósmicos, ruido térmico, las fluctuaciones cuánticas, errores
de controladores de dispositivo u otros mecanismos, es la responsabilidad
del hardware subyacente y del sistema operativo. SQLite no añade
redundancia al archivo de base de datos con el fin de detectar la
corrupción o I / O error. SQLite asume que los datos que lee es
exactamente los mismos datos que previamente escribió.
De forma predeterminada, SQLite asume que un sistema operativo
llamado a escribir una serie de bytes no dañará ni alterará ningún bytes
fuera de ese rango, incluso si la pérdida de potencia o accidente OS ocurre
durante
esa
escritura. A
esto
le
llamamos
la
" PowerSafe
sobrescribir "propiedad. Antes de la versión 3.7.9, SQLite no asumió
PowerSafe sobrescribir. Pero con el aumento de tamaño del sector norma
512-4096 bytes en la mayoría de las unidades de disco, se ha hecho
necesario para asumir PowerSafe sobrescribe con el fin de mantener los
niveles históricos de rentabilidad y por lo PowerSafe sobrescribir se asume
por defecto en las últimas versiones de SQLite. La asunción de PowerSafe
propiedad sobrescribir puede desactivarse en tiempo de compilación o en
tiempo de ejecución si se desea. Ver la PowerSafe sobrescribir la
documentación para más detalles.

3.0 solo archivo Encomienda
Comenzamos con una visión general de los pasos SQLite toma con el fin
de realizar una confirmación atómica de una operación contra un único
archivo de base de datos. Los detalles de los formatos de archivo
utilizados para protegerse contra los daños causados por fallas de energía
y técnicas para realizar una confirmación atómica a través de múltiples
bases de datos se tratan en
secciones posteriores.

3.1 Estado inicial
El estado de la computadora cuando
se abrió por primera vez una
conexión de base de datos se
muestra conceptualmente por el
diagrama de la derecha. El área de

Corp.

la figura de la extrema derecha (con la etiqueta "Disco") representa la
información almacenada en el dispositivo
de
almacenamiento
masivo. Cada rectángulo es un sector. El color azul representa que los
sectores contienen datos originales. La zona media es la caché de disco de
sistemas operativos. En el inicio de nuestro ejemplo, la memoria caché es
frío y esto está representado por salir de los rectángulos de la caché de
disco vacío. La zona izquierda del diagrama muestra el contenido de la
memoria para el proceso que utiliza SQLite. La conexión de base de datos
sólo se ha abierto y no hay información que se ha leído todavía, por lo que
el espacio de usuario está vacía.

3.2 La adquisición de un bloqueo de lectura
Antes de SQLite puede escribir en
una base de datos, debe leer
primero la base de datos para ver lo
que está ahí ya. Incluso si es sólo
anexando nuevos datos SQLite
todavía tiene que leer en el
esquema de la base de la
mesasqlite_master para
que
pueda saber cómo analizar las
sentencias INSERT y descubrir en
qué parte del archivo de base de
datos se debe almacenar la nueva
información.
El primer paso hacia la lectura del
archivo de base de datos es obtener un bloqueo compartido en el archivo
de base de datos. Una cerradura "compartida" permite que dos o más
conexiones de base de datos a leer desde el archivo de base de datos al
mismo tiempo. Sin embargo, un bloqueo compartido evita otra conexión
de base de datos de escribir en el fichero de base de datos mientras
estamos leyendo. Esto es necesario porque si otra conexión de base de
datos se escribe en el archivo de base de datos al mismo tiempo que
estamos leyendo desde el archivo de base de datos, podemos leer algunos
datos antes de que el cambio y otros datos después del cambio. Esto haría
que parezca como si el cambio realizado por el otro proceso no es
atómica.
Observe que el bloqueo compartido se encuentra en la caché de disco del
sistema operativo, no en el propio disco. Los bloqueos de archivo
realmente son banderas en el núcleo del sistema operativo, por lo
general. (Los detalles dependen de la interfaz específica capa del sistema
operativo.) Por lo tanto, la cerradura se desvanecerá al instante si se
Corp.

bloquea el sistema operativo o si hay una pérdida de potencia. Por lo
general es también el caso de que la cerradura se desvanecerá si el
proceso que crea las salidas de bloqueo.

3.3 leer una información en la base de datos
Una vez adquirido el bloqueo
compartido, podemos comenzar a
leer la información del archivo de
base de datos. En este escenario,
estamos asumiendo una caché frío,
así que la información primero debe
leerse de almacenamiento masivo
en el caché del sistema operativo y
luego
transferidos
desde
la
memoria
caché
del
sistema
operativo
en
el
espacio
de
usuario. En lecturas posteriores,
algunos o la totalidad de la
información que ya se puede
encontrar en la caché del sistema operativo y por lo que sólo se requeriría
la transferencia al espacio de usuario.
Por lo general, sólo un subconjunto de las páginas del archivo de base de
datos se leen. En este ejemplo estamos mostrando tres páginas de los
ocho que se lee. En una aplicación típica, una base de datos tendrá miles
de páginas y una consulta normalmente sólo tocar un pequeño porcentaje
de esas páginas.

3.4 La obtención de un bloqueo reservados
Antes de realizar cambios en la
base de datos SQLite primero
obtiene un bloqueo "reservado" en
el archivo de base de datos. Una
cerradura reservada es similar a un
bloqueo compartido en el que tanto
un bloqueo reservado y bloqueo
compartido permiten otros procesos
para leer desde el archivo de base
de
datos. Una
sola
cerradura
reserva
puede
coexistir
con
múltiples bloqueos compartidos de
otros procesos. Sin embargo, sólo

Corp.

puede haber un único bloqueo reservada en el archivo de base de
datos. Por lo tanto sólo un único proceso puede ser intentando escribir en
la base de datos a la vez.
La idea detrás de un bloqueo reservada es que señala que un proceso
tiene la intención de modificar el archivo de base de datos en un futuro
próximo, pero aún no ha empezado a realizar las modificaciones. Y debido
a que las modificaciones aún no han comenzado, otros procesos pueden
continuar leer en la base de datos. Sin embargo, ningún otro proceso
también debe comenzar a tratar de escribir en la base de datos.

3.5 Creación de un archivo de diario Rollback
Antes de hacer cualquier cambio en
el archivo de base de datos SQLite
primero crea un archivo de diario de
reversión independiente y escribe
en el diario de reversión el
contenido original de las páginas de
base de datos que se van a
modificar. La idea detrás de la
revista rollback es que contiene
toda la información necesaria para
restaurar la base de datos de nuevo
a su estado original.
La revista reversión contiene una
pequeña cabecera (se muestra en
verde en el diagrama) que registra
el tamaño original del archivo de
base de datos. Así que si un cambio
hace que el archivo de base de
datos para crecer, todavía podemos saber el tamaño original de la base de
datos. El número de página se almacena junto con cada página de base de
datos que se escribe en el diario de reversión.
Cuando se crea un nuevo archivo, los sistemas operativos más de
escritorio (Windows, Linux, Mac OS X) no llevarán a escribir nada en el
disco. El nuevo archivo se crea en el sistema operativo sólo caché de
disco. El archivo no se crea en la memoria masiva hasta un tiempo
después, cuando el sistema operativo tiene un momento libre. Esto crea la
impresión a los usuarios que I / O está sucediendo mucho más rápido de
lo que es posible cuando se hace real del disco I / O. Nos ilustran esta
idea en el diagrama de la derecha, mostrando que la nueva revista

Corp.

rollback aparece en la caché de disco del sistema operativo y no en el
propio disco.

3.6 Modificación de páginas de base de datos en el espacio
de usuario
Después de que el contenido de la
página original se ha guardado en
el diario de reversión, las páginas
se pueden modificar en la memoria
del usuario. Cada conexión de base
de datos tiene su propia copia
privada del espacio de usuario, por
lo que los cambios que se realizan
en el espacio de usuario son
accesibles solamente a la conexión
de base de datos que está haciendo
los cambios. Otras conexiones de
base de datos todavía ven la
información en el sistema de buffers
de caché de disco de operación que
aún no se han cambiado. Y así, a
pesar de que un solo proceso está
ocupado modificar la base de datos,
otros procesos pueden continuar
leyendo sus propias copias del contenido de base de datos original.

3.7 Vaciado del archivo de
Diario Rollback Para
almacenamiento masivo
El siguiente paso es eliminar el
contenido del archivo de diario de
reversión de almacenamiento no
volátil. Como
veremos
más
adelante, este es un paso crítico
para asegurar que la base de datos
puede sobrevivir a una pérdida de
energía
inesperada. Este
paso
también necesita una gran cantidad
de tiempo, ya que la escritura para
Corp.

el almacenamiento no volátil es normalmente una operación lenta.
Este paso es generalmente más complicado que simplemente tirar de la
revista reversión en el disco. En la mayoría de las plataformas se
requieren dos operaciones separadas ras (o fsync ()). La primera oleada
escribe el contenido de la revista rollback base. A continuación, la
cabecera de la revista rollback se modifica para mostrar el número de
páginas en el diario de reversión. A continuación, la cabecera se vacía en
el disco. Los detalles sobre por qué hacemos esta modificación
encabezado y al ras adicionales se proporcionan en una sección posterior
de este artículo.

3.8 La obtención de un bloqueo exclusivo
Antes de realizar cambios en el
mismo archivo de base de datos,
debemos
obtener
un
bloqueo
exclusivo en el archivo de base de
datos. La obtención de un bloqueo
exclusivo es realmente un proceso
de
dos
pasos. Primero
SQLite
obtiene un bloqueo "pendiente". A
continuación,
se
intensifica
el
bloqueo pendiente para un bloqueo
exclusivo.
Un bloqueo en espera permite que
otros procesos que ya tienen un
bloqueo compartido para seguir
leyendo el archivo de base de
datos. Pero evita nuevos bloqueos
compartidos se establezca. La idea
detrás de un bloqueo en espera es
de impedir la hambruna escritor
causado por un gran número de lectores. Puede haber docenas, incluso
cientos, de otros procesos que tratan de leer el archivo de base de
datos. Cada proceso tiene un bloqueo compartido antes de que comience
la lectura, lee lo que necesita, entonces libera el bloqueo compartido. Si,
sin embargo, hay muchos procesos diferentes toda la lectura de la misma
base de datos, podría suceder que un nuevo proceso siempre adquiere su
bloqueo compartido antes de que el proceso anterior libera su bloqueo
compartido. Y lo que nunca hay un instante en que no hay bloqueos
compartidos en el archivo de base de datos y por lo tanto, nunca hay una
oportunidad para que el escritor para aprovechar el bloqueo
exclusivo. Una cerradura de pendiente está diseñada para evitar que el

Corp.

ciclo al permitir bloqueos compartidos existentes para proceder, pero el
bloqueo de nuevos bloqueos compartidos de ser establecido. Finalmente,
todos los bloqueos compartidos se borrará y la cerradura pendiente será
entonces capaz de escalar a un bloqueo exclusivo.

3.9 Cambios escribir en el archivo de base de datos
Una vez que se mantiene un
bloqueo exclusivo, sabemos que
hay otros procesos leen desde el
archivo de base de datos y es
seguro escribir los cambios en el
archivo de base de datos. Por lo
general, esos cambios sólo llegan
hasta los sistemas de caché de
disco operativo y no lo hacen hasta
el final a almacenamiento masivo.

3.10 enviando cambios del almacenamiento masivo
Otra
ras
debe
ocurrir
para
asegurarse de que todos los
cambios de base de datos se
escriben en el almacenamiento no
volátil. Este es un paso crítico para
asegurar que la base de datos va a
sobrevivir
a una pérdida de
potencia y sin daños. Sin embargo,
a causa de la lentitud inherente a
escribir en el disco o en la memoria
flash, este paso junto con la revista
rollback ras del archivo en la

Corp.

sección 3.7 anterior tienen en la mayor parte del tiempo requerido para
completar una transacción cometen en SQLite.

3.11 Eliminación El Diario Rollback
Después de los cambios de base de
datos están a salvo en el dispositivo
de almacenamiento masivo, se
elimina el archivo de diario de
reversión. Este es el instante en
que se confirme la transacción. Si
un corte de energía o fallo del
sistema se produce antes de este
punto, entonces los procesos de
recuperación que se describirán
más adelante hacen que parezca
como si no hubo cambios jamás se
ha hecho en el fichero de base de
datos. Si un corte de energía o fallo
del sistema se produce después de
que se elimina el diario de
reversión, entonces parece como si
todos los cambios se han escrito en
el disco. Por lo tanto, SQLite da la
apariencia de haber realizado cambios en el archivo de base de datos o
haber hecho el conjunto completo de los cambios realizados en el archivo
de base de datos en función de si existe o no el archivo de diario de
reversión.
Eliminación de un archivo no es realmente una operación atómica, pero
que parece ser desde el punto de vista de un proceso de usuario. Un
proceso siempre es capaz de hacer que el sistema operativo "no existe
este archivo?"y el proceso se pondrá en un sí o un no. Después de un
corte de energía que se produce durante una confirmación de transacción,
SQLite le pedirá el sistema operativo si existe o no el archivo de diario de
reversión. Si la respuesta es "sí", entonces la transacción es incompleta y
se revierte. Si la respuesta es "no", entonces significa que la transacción
había cometido.
La existencia de una operación depende de si existe o no el archivo de
diario de reversión y la eliminación de un archivo que parece ser una
operación atómica desde el punto de vista de un proceso en espacio de
usuario. Por lo tanto, una transacción parece ser una operación atómica.
El acto de borrar un archivo es costoso en muchos sistemas. Como una
optimización, SQLite puede ser configurado para truncar el fichero de
Corp.

diario a cero bytes de longitud o sobrescribir la cabecera del fichero de
diario con ceros. En cualquiera de los casos, el archivo de diario resultante
ya no es capaz de rodar hacia atrás y por lo que la transacción aún
comete. Truncamiento de un archivo de longitud cero, como borrar un
archivo, se supone que es una operación atómica desde el punto de vista
de un proceso de usuario. Sobrescribir la cabecera de la revista con ceros
no es atómica, pero si alguna parte de la cabecera es incorrecto la revista
no se deshace. Por lo tanto, se puede decir que la confirmación se
produce tan pronto como el encabezado se cambia lo suficiente como para
que sea válido. Típicamente, esto sucede tan pronto como se pone a cero
el primer byte de la cabecera.

3,12 liberar el bloqueo
El último paso en el proceso de
confirmación es para liberar el
bloqueo exclusivo para que otros
procesos puedan volver a iniciar el
acceso al archivo de base de datos.
En el diagrama de la derecha, se
muestra que la información que se
celebró en el espacio de usuario se
borra
cuando
se
libera
el
bloqueo. Esto solía ser literalmente
cierto para versiones anteriores de
SQLite. Sin embargo, versiones más
recientes de SQLite mantener la
información de espacio de usuario
en la memoria en caso de que podría ser necesario de nuevo al comienzo
de la siguiente transacción. Es más barato reutilizar la información que ya
está en la memoria local de la transferencia de la información de vuelta de
la caché de disco del sistema operativo o de leer fuera de la unidad de
disco nuevo. Antes de volver a utilizar la información en el espacio de
usuario, primero debe volver a adquirir el bloqueo compartido y luego
tenemos que comprobar para asegurarse de que ningún otro proceso
modificado el archivo de base de datos mientras no estábamos celebrando
una cerradura.Hay un contador en la primera página de la base de datos
que se incrementa cada vez que el archivo de base de datos es
modificado. Podemos averiguar si otro proceso ha modificado la base de
datos mediante la comprobación de ese contador. Si se ha modificado la
base de datos, el caché de espacio de usuario debe ser limpiado y
releer. Pero suele suceder que no se han realizado cambios y la caché de
espacio de usuario pueden ser reutilizados para un ahorro de rendimiento
significativas.

Corp.

4.0 Rollback
Una
confirmación
atómica
se
supone
que
debe
ocurrir
instantáneamente. Sin embargo, el procesamiento descrito anteriormente
tiene claramente una cantidad finita de tiempo. Supongamos que la
energía a la computadora se cortaron parte del camino a través de la
operación de confirmación se ha descrito anteriormente. A fin de
mantener la ilusión de que los cambios fueron instantáneos, hay que
"deshacer" los cambios parciales y restaurar la base de datos al estado en
que estaba antes del inicio de la operación.

4.1 Cuando algo va mal ...
Supongamos
que
el
apagón
ocurrido en el paso 3.10 anterior,
mientras que los cambios de base
de datos se están escribiendo en el
disco. Después
de
que
se
restablezca el suministro eléctrico,
la situación podría ser algo así como
lo
que
se
muestra
a
la
derecha. Estábamos tratando de
cambiar tres páginas del archivo de
base de datos, pero sólo una página
se escribió correctamente. Otra
página fue escrita en parte y una
tercera página no se ha escrito
nada.
El diario de reversión es completo e intacto en el disco cuando se
restablezca la alimentación. Este es un punto clave. El motivo de la
operación de vaciado en el paso 3.7 es estar absolutamente seguro de
que todos los de la revista rollback es con seguridad en el
almacenamiento no volátil antes de hacer cualquier cambio en el mismo
archivo de base de datos.

4.2 Revistas Rollback calientes

Corp.

La primera vez que un proceso de
SQLite intenta acceder al archivo de
base de datos, se obtiene un
bloqueo
compartido
como
se
describe
en el
apartado
3.2anterior. Pero entonces se da
cuenta de que hay una reversión
revista archivo presente. SQLite
continuación, comprueba si el diario
de
reversión
es
un
"diario
caliente". Un diario caliente es un
diario de reversión que necesita ser
reproducido con el fin de restaurar
la base de datos a su estado
normal. Un diario caliente sólo
existe cuando un proceso anterior
fue en el medio de confirmar una
transacción cuando se estrelló o se
pierde el poder.
Un diario de reversión es un diario "caliente" si todas las condiciones
siguientes son verdaderas:
Existe la revista rollback.
El diario de reversión no es un archivo vacío.
No hay bloqueo reservada en el archivo de base de datos principal.
La cabecera de la revista rollback está bien formado y, en particular,
no se ha llevado a cero.
El diario de reversión no contiene el nombre de un archivo de diario
master (véase la sección 5.5 más adelante) o si contiene el nombre
de un diario principal, luego que existe archivo de diario maestro.
La presencia de una revista caliente es nuestra indicación de que un
proceso anterior estaba tratando de confirmar una transacción pero
abortado por alguna razón antes de la finalización de la confirmación. Un
diario caliente significa que el archivo de base de datos está en un estado
inconsistente y necesita ser reparado (por rollback) antes de ser utilizado.

4.3 La obtención de un
bloqueo exclusivo en la
base de datos
El primer paso para hacer frente
a una revista caliente es obtener

Corp.

un bloqueo exclusivo en el archivo de base de datos. Esto evita que dos o
más procesos de intentar deshacer la misma revista caliente al mismo
tiempo.

4.4 Anulación de los cambios incompletas
Una vez que un proceso obtiene un
bloqueo
exclusivo,
se
permite
escribir en el archivo de base de
datos. A continuación, se procede a
leer el contenido original de las
páginas de la revista rollback y
escribir ese contenido de nuevo a
donde vino en el archivo de base de
datos. Recordemos que la cabecera
de la revista reversión registra el
tamaño original del archivo de base
de datos antes del inicio de la
transacción abortada. SQLite utiliza
esta información para truncar el
archivo de base de datos de nuevo a
su tamaño original en caso de que la
transacción incompleta causado la
base de datos crezca. Al final de
este paso, la base de datos debe ser
del mismo tamaño y contener la
misma información como lo hizo antes del inicio de la transacción
abortada.

4.5 Eliminación El Diario
caliente
Después de toda la información en
el diario de reversión se ha
reproducido en el archivo de base
de datos (y volcado a disco en caso
de que nos encontramos con otro
corte de corriente), la revista
rollback caliente se puede eliminar.

Corp.

Al igual que en la sección 3.11 , el archivo de diario se puede truncar a
cero la longitud o el encabezado podría ser sobrescribe con ceros como
una optimización de los sistemas en eliminar un archivo es caro. De
cualquier manera, la revista ya no está caliente después de este paso.

4.6 continuará como si el Uncompleted Escribe nunca había
sucedido
El paso final es la recuperación para
reducir el bloqueo exclusivo de
nuevo
a
un
bloqueo
compartido. Una vez que esto
sucede, la base de datos se
encuentre de nuevo en el estado
que habría sido si la transacción
abortada
nunca
había
comenzado. Dado que toda esta
actividad de recuperación ocurre de
forma totalmente automática y
transparente,
parece
que
el
programa que utiliza SQLite como si
la transacción anulada nunca había
comenzado.

5.0 Multi-file Encomienda
SQLite permite que una sola conexión de base de datos para hablar con
dos o más archivos de base de datos simultáneamente a través de la
utilización de la Adjuntar base de datos de comandos. Cuando hay varios
archivos de base de datos se modifican en una sola transacción, todos los
archivos se actualizan atómicamente. En otras palabras, ya sea en todos
los archivos de bases de datos se actualizan o ninguna otra cosa de ellos
son. Lograr una confirmación atómica a través de múltiples archivos de
bases de datos es más complejo que hacerlo para un solo archivo. En esta
sección se describe cómo funciona SQLite ese poco de magia.

5.1 Revistas Rollback independiente
para cada base de datos
Cuando hay varios archivos de base de datos
están involucrados en una transacción, cada
base de datos tiene su propio diario de
reversión y cada base de datos está bloqueado
por separado. El diagrama de la derecha

Corp.

muestra un escenario en tres archivos de bases de datos diferentes se han
modificado dentro de una transacción. La situación en este paso es
análogo al escenario de operación de un solo archivo en el paso 3.6 . Cada
archivo de base de datos tiene un bloqueo reservado. Para cada base de
datos, el contenido original de las páginas que están siendo cambiados
haber sido escrito en la revista de reversión para esa base de datos, pero
el contenido de las revistas aún no han sido volcado a disco. No se han
realizado cambios en el propio archivo de base de datos, sin embargo,
aunque presumiblemente se producen cambios que se celebra en memoria
del usuario.
Por razones de brevedad, los diagramas de esta sección se han
simplificado de los que vinieron antes. El color azul significa todavía el
contenido original y rosa significa todavía el nuevo contenido. Sin
embargo, las páginas individuales en el diario de reversión y el archivo de
base de datos no se muestran y no están haciendo la distinción entre la
información en la caché del sistema operativo y la información que está en
el disco. Todos estos factores se aplican todavía en un escenario de
confirmación de varios archivos. Ellos sólo ocupan mucho espacio en el
gráfico y que no añaden ninguna información nueva, por lo que se omiten
aquí.

5.2 El archivo de diario Maestro
El siguiente paso en una
confirmación
de
varios
archivos es la creación de
un
archivo
"maestro
revista". El
nombre
del
archivo de diario maestro
es el mismo nombre que el
nombre del archivo de
base de datos original (la
base de datos que se abrió
con elsqlite3_open () de la
interfaz, no es uno de
los adjuntos bases
de
datos auxiliares) con el
texto "-mj HHHHHHHH" añadido

enHHHHHHHH es

una

número

Corp.

hexadecimal
de
32
bits
al
azar. Los
cambios
aleatorios HHHHHHHH para cada nueva publicación principal.

sufijos

(Nota bene:.. La fórmula para el cálculo de la revista master nombre de
archivo indicado en el párrafo anterior se corresponde con la ejecución al
SQLite versión 3.5.0 Pero esta fórmula no es parte de la especificación de
SQLite y está sujeto a cambios en versiones futuras)
A diferencia de las revistas de reversión, el diario principal no contiene
ningún contenido de la página base de datos original. En cambio, el diario
principal contiene la ruta completa de las revistas de reversión para cada
base de datos que participa en la transacción.
Después de la publicación principal está construido, su contenido se vacía
en el disco antes de tomar cualquier otra acción. En Unix, el directorio que
contiene la revista principal también se sincroniza con el fin de asegurarse
de que el archivo de diario principal aparecerá en el directorio raíz de una
falla de energía.

5.3 Actualización de Rollback Journal Cabeceras
El
siguiente
paso
es
registrar la ruta completa
del archivo principal revista
en la cabecera de todas las
revistas
de
reversión. Espacio
para
mantener la revista del
archivo maestro se reservó
al principio de cada revista
rollback como se crearon
las revistas rollback.
El contenido
de
cada
revista reversión se vacía
en el disco, tanto antes como después de la revista nombre del archivo
Corp.

maestro está escrito en la cabecera del diario de reversión. Es importante
hacer estas dos oleadas. Afortunadamente, el segundo color es
generalmente de bajo costo desde lo general sólo una página del archivo
de diario (la primera página) ha cambiado.
Este paso es análogo a la etapa 3.7 en el archivo de un solo escenario
compromiso descrito anteriormente.

5.4 Actualización de los archivos de base de datos
Una vez que todos los
archivos de diario de
reversión se han volcado a
disco,
que
es
seguro
comenzar a actualizar los
archivos
de
base
de
datos. Tenemos
que
obtener
un
bloqueo
exclusivo en todos los
archivos de base de datos
antes
de
escribir
los
cambios. Después de todos
los cambios que se han
escrito, es importante para
eliminar los cambios en el disco para que se mantendrán en el caso de un
corte de energía o fallo del sistema operativo.
Esta etapa corresponde a los pasos 3.8 , 3.9 y 3.10 en el escenario de
compromiso único archivo descrito anteriormente.

5.5 Elimine el archivo Diario Maestro
El
siguiente
paso
es
eliminar el archivo de
diario maestro. Este es el
punto en el que se
confirme la transacción de
varios archivos. Esta etapa
corresponde
a un
paso
3,11 en la hipótesis de
cometer un solo archivo en
el que se elimina el diario
de reversión.

Si un corte de energía o
fallo del sistema operativo
se produce en este punto, la operación no se retrotraerá cuando se

Corp.

reinicia el sistema, aunque hay retrotracción revistas presentan. La
diferencia es la ruta principal diario en la cabecera de la revista
rollback. Al reiniciar, SQLite sólo considera un diario para estar caliente y
sólo se podrá reproducir la revista, si no existe ninguna revista principal
nombre en la cabecera (que es el caso para un solo archivo commit) o si
el archivo de diario amo todavía existe en el disco.

5.6 Limpiar el Journals Rollback
El paso final en un compromiso de varios
archivos es borrar las revistas rollback
individuales y soltar los bloqueos exclusivos
sobre los archivos de base de datos para que
otros procesos puedan ver los cambios. Esto
se corresponde con el paso 3.12 en la
secuencia de confirmación en una archivo.
La transacción ya se ha comprometido en este
punto lo que el calendario no es crítico en la
eliminación de las revistas de rollback. Los
actuales elimina la aplicación de una sola
revista rollback luego desbloquea el archivo de
base de datos correspondiente antes de pasar
al siguiente diario de reversión. Pero en el
futuro podemos cambiar esto para que todas las revistas rollback se
eliminan antes de que los archivos de base de datos se
desbloquean. Mientras el diario de reversión se elimina antes de que se
abrió su correspondiente archivo de base de datos, no importa en qué
orden las revistas rollback se eliminan o los archivos de base de datos
están desbloqueados.

6.0 Detalles adicionales del proceso de confirmación
Sección 3.0 anterior proporciona una visión general de cómo atómica
cometer obras en SQLite. Pero se pasa por alto una serie de detalles
importantes. En los apartados siguientes se tratará de llenar los vacíos.

6.1 Siempre Journal Sectores completos
Cuando el contenido original de una página de base de datos se escribe en
el diario de reversión (como se muestra en la sección 3.5 ), SQLite
siempre escribe una completa sectores por valor de datos, incluso si el
tamaño de página de la base de datos es menor que el tamaño de
sector. Históricamente, el tamaño del sector en SQLite ha sido codificado
a 512 bytes, y dado que el tamaño mínimo de la página también es 512
bytes, esto nunca ha sido un problema. Sin embargo, comenzando con
Corp.

SQLite versión 3.3.14, es posible para SQLite de usar dispositivos de
almacenamiento masivo con un tamaño de sector mayor que 512
bytes. Así, a partir de la versión 3.3.14, cada vez que una página dentro
de un sector se escribe en el archivo de diario, todas las páginas de ese
mismo sector se guardan con él.
Es importante almacenar todas las páginas de un sector en la revista
reversión con el fin de prevenir la corrupción de base de datos después de
una pérdida de potencia durante la escritura del sector. Supongamos que
las páginas 1, 2, 3, y 4 se almacenan en el sector 1 y la página 2 se
modifica. Para escribir los cambios en la página 2, el hardware subyacente
también debe volver a escribir el contenido de las páginas 1, 3 y 4 ya que
el hardware debe escribir el sector completo. Si esta operación de
escritura se interrumpe por un corte de energía, una o más de las páginas
1, 3, o 4 podría quedar con datos incorrectos. Por lo tanto, para evitar la
corrupción duradera a la base de datos, el contenido original de todas
esas páginas deben estar contenidos en la revista rollback.

6.2 Manejo de basura escrita en archivos de diario
Cuando los datos se añaden al final de la revista reversión, SQLite
normalmente hace la suposición pesimista de que el archivo se extiende
primero con datos no válidos "basura" y que después los datos correctos
sustituye a la basura. En otras palabras, SQLite asume que el tamaño del
archivo se aumenta primero y luego después el contenido se escribe en el
archivo. Si se produce un corte de energía después de que el archivo se
ha incrementado, pero antes de que el contenido del archivo se ha escrito,
la revista rollback se puede dejar que contiene datos de la basura. Si
después de que se restablezca la energía, otro proceso SQLite ve la
revista rollback que contiene los datos de la basura y trata de tirar de
nuevo en el archivo de base de datos original, puede copiar algo de la
basura en el archivo de base de datos y por lo tanto dañar el archivo de
base de datos.
SQLite utiliza dos defensas contra este problema. En primer lugar, SQLite
registra el número de páginas en el diario de reversión en la cabecera de
la revista rollback. Este número es inicialmente cero. Así que durante un
intento de deshacer un diario de reversión incompleta (y posiblemente
corrupto), el proceso de hacer la restauración se encargará de que la
revista contiene cero páginas y por lo tanto no hará cambios a la base de
datos. Antes de la confirmación, el diario de reversión se vacía en el disco
para asegurarse de que todo el contenido se ha sincronizado en el disco y
no hay "basura" que queda en el archivo, y sólo entonces es el número de
páginas en la cabecera del pasado de cero a cierto número de páginas del
diario de reversión. La cabecera revista reversión se mantiene siempre en
Corp.

un sector separado de los datos de página de modo que se puede
sobrescribir y eliminará sin correr el riesgo de daño a una página de datos
si se produce un corte de energía. Tenga en cuenta que la revista rollback
se vacía en el disco dos veces: una para escribir el contenido de la página
y una segunda vez para escribir el número de página en el encabezado.
El párrafo anterior describe lo que sucede cuando la configuración pragma
síncrono está "lleno".
PRAGMA síncrono = COMPLETO;
El ajuste síncrono predeterminado está lleno así que lo anterior es lo que
suele ocurrir. Sin embargo, si el ajuste síncrono baja a SQLite, sólo vuelca
"normales" de la revista reversión una vez, después de que el número de
páginas que se ha escrito. Esto conlleva un riesgo de corrupción, ya que
podría ocurrir que la (no-cero) número de páginas modificadas alcanza la
superficie del disco antes de que todos los datos que hace. Los datos se
han escrito en primer lugar, pero SQLite asume que el sistema de archivos
subyacente puede cambiar el orden de las solicitudes de escritura y que el
número de páginas se puede grabar en óxido de primera a pesar de que
su solicitud de escritura se produjo el pasado. Así como una segunda línea
de defensa, SQLite también utiliza una suma de comprobación de 32 bits
en todas las páginas de datos en el diario de reversión. Esta suma de
control se evalúa para cada página durante la restitución al deshacer un
diario como se describe en la sección 4.4 . Si se observa un checksum
incorrecto, el retroceso es abandonado. Tenga en cuenta que la suma de
comprobación no garantiza que los datos de la página es correcta ya que
hay una pequeña pero finita probabilidad de que la suma podría ser
correcto, incluso si los datos son corruptos. Pero la suma de comprobación
no por lo menos hacer este tipo de error probable.
Tenga en cuenta que las sumas de comprobación en el diario de reversión
no son necesarios si el ajuste síncrono está llena. Sólo dependemos de las
sumas de comprobación síncrona cuando se baja a NORMAL. Sin embargo,
las sumas de comprobación no le hace mal y por lo que se incluyen en la
revista rollback independientemente del ajuste síncrono.

6.3 caché derrame antes de enviarlo
El proceso de confirmación se muestra en la sección 3.0 asume que todos
los cambios de base de datos encajan en la memoria hasta que es el
momento de cometer. Este es el caso común. Pero a veces un cambio más
grande se desbordará la memoria caché de espacio de usuario antes de la
confirmación de la transacción. En esos casos, el caché debe derrame a la
base de datos antes de que se complete la transacción.

Corp.

Al comienzo de un derrame de caché, el estado de la conexión de base de
datos es como se muestra en el paso 3.6 .Contenido de la página original
se ha guardado en la revista rollback y existen modificaciones de las
páginas en la memoria de usuario. Verter la caché, SQLite ejecuta los
pasos 3.7 a través de 3.9 . En otras palabras, la revista rollback se vacía
en el disco, un bloqueo exclusivo se adquiere, y los cambios se escriben
en la base de datos. Pero los pasos restantes son diferidos hasta que la
transacción se compromete realmente. Una nueva cabecera revista se
añade al final de la revista rollback (en su sector) y se mantiene el
bloqueo exclusivo de base de datos, pero el procesamiento de lo contrario
regresa al paso 3.6 . Cuando se confirma la transacción, o si se produce
otro derrame de caché, los pasos 3.7 y 3.9 se repiten. (Paso 3.8 se omite
en la segunda y subsiguientes pases desde un bloqueo exclusivo de base
de datos que ya se lleva a cabo debido a la primera pasada.)
Un derrame de caché hace que el bloqueo en el archivo de base de datos
en aumento desde reservado exclusiva. Esto reduce la concurrencia. Un
derrame de caché también hace operaciones de vaciado o fsync disco de
reserva a ocurrir y estas operaciones son lentas, por lo tanto, un derrame
de caché puede reducir seriamente el rendimiento. Por estas razones, un
derrame de caché se evita siempre que sea posible.

7.0 Optimizaciones
Profiling indica que para la mayoría de los sistemas y en la mayoría de
circunstancias SQLite pasa la mayor parte de su tiempo haciendo el disco
I / O. Se deduce entonces que cualquier cosa que podamos hacer para
reducir la cantidad de disco probabilidades de E / S a tener un gran
impacto positivo en el desempeño de SQLite. Esta sección describe
algunas de las técnicas utilizadas por SQLite para tratar de reducir la
cantidad de disco I / O al mínimo al mismo tiempo conservar confirmación
atómica.

7.1 caché retenidas entre las transacciones
Paso 3.12 del proceso de confirmación muestra que una vez que el
bloqueo compartido ha sido puesto en libertad, todas las imágenes de
caché de espacio de usuario de base de datos de contenido deben
desecharse. Esto se hace porque sin un bloqueo compartido, otros
procesos son libres de modificar el contenido de un archivo de base de
datos por lo que cualquier imagen de espacio de usuario de ese contenido
podría llegar a ser obsoletos. En consecuencia, cada nueva transacción

Corp.

comenzaría por releer los datos que previamente había sido leídos. Esto
no es tan malo como parece al principio, ya que los datos sean leídos
sigue siendo probable que en los sistemas de caché de archivos
operativo. Así que la "lectura" es en realidad una copia de los datos en el
espacio del núcleo al espacio de usuario.Pero aún así, se necesita tiempo.
Comenzando con la versión 3.3.14 SQLite un mecanismo ha sido añadido
para tratar de reducir la relectura innecesaria de datos. En las nuevas
versiones de SQLite, los datos en el espacio de usuario del localizador
caché se conserva cuando se libera el bloqueo en el archivo de base de
datos. Más tarde, después de que el bloqueo compartido se adquiere en el
comienzo de la siguiente transacción, SQLite comprueba para ver si algún
otro proceso ha modificado el archivo de base de datos. Si la base de
datos ha cambiado de alguna forma desde que el bloqueo fue lanzado el
pasado, la memoria caché de espacio de usuario se borra en ese
punto. Sin embargo, comúnmente el archivo de base de datos no se
modifica y la memoria caché de espacio de usuario puede ser retenida, y
algunas operaciones de lectura innecesarios se puede evitar.
Con el fin de determinar si o no el archivo de base de datos ha cambiado,
SQLite utiliza un contador en la cabecera de base de datos (en bytes 24 a
27) que se incrementa durante cada operación de cambio. SQLite guarda
una copia de este contador antes de liberar su bloqueo de base de
datos. Luego, después de la adquisición de la siguiente bloqueo de base
de datos se compara el valor del contador guardado contra el valor del
contador actual y borra la memoria caché si los valores son diferentes, o
vuelve a utilizar la memoria caché si son la misma.

7.2 Modo de acceso exclusivo
SQLite versión 3.3.14 añade el concepto de "modo de acceso
exclusivo". En el modo de acceso exclusivo, SQLite mantiene el bloqueo
exclusivo de base de datos al final de cada transacción. Esto evita que
otros procesos de acceso a la base de datos, pero en muchas
implementaciones sólo un único proceso está utilizando una base de datos
por lo que este no es un problema grave. La ventaja del modo de acceso
exclusivo es que la E / S se puede reducir de tres maneras:
1. No es necesario para incrementar el contador de cambio en el
encabezado de base de datos para las transacciones después de la
primera transacción. A menudo, esto ahorrará una escritura de la
primera página tanto a la revista rollback y el archivo de base de
datos principal.
2. Ningún otro proceso puede cambiar la base de datos por lo que
nunca hay una necesidad de comprobar el contador de cambio y

Corp.

borrar la caché de espacio de usuario en el inicio de una
transacción.
3. Cada transacción puede ser cometido por sobrescribir el encabezado
revista rollback con ceros en lugar de eliminar el archivo de
diario. Esto evita tener que modificar la entrada de directorio para el
archivo de diario y evita tener que cancelar la asignación de
sectores de disco asociados con la revista. Por otra parte, la
siguiente transacción se sobrescribe el contenido del archivo de
diario existente en lugar de anexar nuevos contenidos y en la
mayoría de los sistemas de sobre escritura es mucho más rápido
que añadiendo.
La tercera optimización, puesta a cero del encabezado del archivo diario
en lugar de eliminar el archivo de diario de reversión, no depende de la
celebración de un bloqueo exclusivo en todo momento. Esta optimización
se puede ajustar de forma independiente de modo de bloqueo exclusivo
mediante el pragma journal_mode como se describe en la sección 7.6 a
continuación.

7.3 No utilizar Journal freelist Páginas
Cuando la información se borra de una base de datos SQLite, las páginas
que se utiliza para mantener la información borrada se añaden a una
" lista libre ". Inserciones posteriores se basarán páginas fuera de esta
lista libre en lugar de ampliar el archivo de base de datos.
Algunas páginas freelist contienen datos críticos, específicamente la
ubicación de otras páginas freelist. Pero la mayoría de las páginas freelist
contienen nada útil. Estas páginas freelist últimos se denominan páginas
"hoja". Somos libres para modificar el contenido de una página de lista
libre de la hoja en la base de datos sin cambiar el sentido de la base de
datos en modo alguno.
Debido a que el contenido de las páginas freelist hoja no es importante,
evita el almacenamiento de SQLite hoja freelist contenido de la página en
el diario de reversión en el paso 3.5 del proceso de confirmación. Si se
cambia una página freelist hoja y que el cambio no se expanden de nuevo
durante una recuperación de la transacción, la base de datos no se ve
perjudicada por la omisión. Del mismo modo, el contenido de una página
nueva lista libre nunca se escribe de nuevo en la base de datos en el paso
3.9 ni lee de la base de datos en el paso 3.3 . Estas optimizaciones
pueden reducir en gran medida la cantidad de E / S que se produce
cuando se realizan cambios en un archivo de base de datos que contiene
el espacio libre.

Corp.

7.4 simples actualizaciones de la página y el sector
Atómica Graba
A partir de SQLite versión 3.5.0, la nueva interfaz del sistema de archivos
virtual (VFS) contiene un método denominado xDeviceCharacteristics que
informa sobre las propiedades especiales que el dispositivo de
almacenamiento masivo subyacente podría tener. Entre las propiedades
especiales que xDeviceCharacteristics puede informar es la capacidad de
hacer una escritura sector atómico.
Recordemos que por defecto SQLite asume ese sector escribe son lineales,
pero no atómica. Una escritura lineal comienza en un extremo del sector y
cambios byte de información por byte hasta que llega al otro extremo del
sector. Si se produce una pérdida de potencia en el medio de una
escritura lineal entonces parte del sector podría ser modificada mientras
que el otro extremo es sin cambios. En una escritura sector atómico, ya
sea todo el sector se sobrescribe o si no se cambia nada en el sector.
Creemos que las unidades de disco más modernos implementan sector
atómico escribe. Cuando se pierde la alimentación, la unidad utiliza la
energía almacenada en los condensadores y / o el momento angular del
plato de disco para proporcionar energía para completar cualquier
operación en curso. Sin embargo, hay muchas capas de entre la llamada
al sistema de escritura y la electrónica de la unidad de disco de a bordo
que tomamos el enfoque de seguridad en Unix y w32 VFS
implementaciones y asumimos ese sector escribe no son atómicas. Por
otro lado, los fabricantes de dispositivos con un mayor control sobre sus
sistemas de ficheros podría considerar que permite la propiedad de
escritura atómica de xDeviceCharacteristics si su hardware realmente
hace atómica escribe.
Cuando sector escribe son atómica y el tamaño de página de una base de
datos es el mismo que un tamaño de sector, y cuando hay un cambio de
base de datos que sólo toca una página única base de datos, entonces se
salta SQLite todo el proceso diario y sincronización y simplemente escribe
la página modificada directamente en el archivo de base de datos. El
contador de cambio en la primera página del archivo de base de datos se
modifica por separado, ya no se haga daño si se pierde la energía antes
de que el contador de cambio se puede actualizar.

7.5 Sistemas de archivos con la semántica Anexar Segura
Otra optimización introducida en SQLite versión 3.5.0 hace uso de la
conducta "append seguro" del disco subyacente. Recordemos que SQLite
asume que cuando los datos se añaden a un archivo (específicamente

Corp.

para la revista rollback) que el tamaño del archivo se aumenta primero y
que el contenido se escriben segundos. Así que si se pierde el poder tras
el tamaño del archivo es mayor, pero antes de que el contenido está
escrito, se deja el archivo que contiene los datos de "basura" no
válidos. El método xDeviceCharacteristics de los VFS puede, sin embargo,
indican que el sistema de archivos implementa "Añadir seguros"
semántica. Esto significa que el contenido está escrito antes de que se
aumentó el tamaño de archivo de modo que es imposible para la basura
que se introduce en la revista reversión por una pérdida de potencia o
fallo del sistema.
Cuando semántica append seguros están indicados para un sistema de
archivos, SQLite siempre almacena el valor especial de -1 para el recuento
de páginas en la cabecera de la revista rollback. El valor de recuento de
páginas -1 dice cualquier proceso de intentar deshacer la revista que el
número de páginas de la revista debe ser computado desde el tamaño del
diario. Este valor -1 nunca se cambia. Así que cuando ocurre un commit,
salvamos una sola operación de vaciado y una escritura sector de la
primera página del archivo de diario. Por otra parte, cuando se produce un
derrame de caché que ya no tenemos que añadir una nueva cabecera
diario al final de la revista, sino que simplemente podemos seguir
añadiendo nuevas páginas al final del diario existente.

7.6 Revistas Rollback Persistentes
Eliminación de un archivo es una operación costosa en muchos
sistemas. Así como una optimización, SQLite se puede configurar para
evitar la operación de eliminación de la sección 3.11 . En lugar de eliminar
el archivo de diario con el fin de confirmar una transacción, el archivo se
truncan a cero bytes de longitud o su cabecera se sobrescribe con
ceros. Truncar el archivo de longitud cero ahorra tener que hacer
modificaciones al directorio que contiene el archivo desde el archivo no se
elimina del directorio. Sobrescribir la cabecera tiene el ahorro adicional de
no tener que actualizar la longitud del archivo (en el "inodo" en muchos
sistemas) y no tener que lidiar con los sectores del disco recién
liberados. Además, en la próxima operación de la revista se creará al
sobrescribir el contenido existente en lugar de anexar nuevos contenidos
en el final de un archivo, y sobre escritura es a menudo mucho más
rápido que añadiendo.
SQLite se puede configurar para confirmar transacciones sobrescribiendo
la cabecera diario con ceros en lugar de eliminar el archivo de diario

Corp.

estableciendo
el
modo
de
diario
el journal_mode PRAGMA. Por ejemplo:
Journal_mode PRAGMA = persistir;

"PERSIST"

utilizando

El uso del modo de diario persistente proporcionar una mejora notable en
el rendimiento de muchos sistemas. Por supuesto, el inconveniente es que
los ficheros de diario permanecen en el disco, el uso de espacio de disco y
que saturan directorios, mucho después de que se confirme la
transacción. La única forma segura de eliminar un archivo de diario
persistente es cometer una transacción con el modo SET para borrar el
diario:
PRAGMA journal_mode = BORRAR;
INICIAR EXCLUSIVA;
COMMIT;

Tenga cuidado de borrar archivos de diario persistentes por cualquier otro
medio desde el archivo de diario puede estar caliente, en cuyo caso
eliminarlo dañará el archivo de base de datos correspondiente.
A partir de SQLite versión 3.6.4, el modo de diario TRUNCATE también es
compatible:
PRAGMA journal_mode = TRUNCATE;

En el modo de diario truncado, la transacción se confirma al truncar el
archivo de diario de longitud cero en lugar de eliminar el archivo de diario
(como en el modo DELETE) o mediante la reducción a cero de la cabecera
(como en el modo PERSISTE). TRUNCATE acciones modo la ventaja de
PERSIST modo que no es necesario en el directorio que contiene el
archivo de diario y la base de datos para actualizar. Por lo tanto truncar
un archivo es a menudo más rápido que eliminarlo. TRUNCATE tiene la
ventaja adicional de que no es seguido por una llamada al sistema (por
ejemplo: fsync ()) para sincronizar el cambio en el disco. Podría ser más
seguro si lo hizo. Pero en muchos sistemas de ficheros modernos, un
truncado es una operación atómica y sincrónica y por lo que considera que
TRUNCATE por lo general será seguro en la cara de fallos de
alimentación. Si no está seguro acerca de si o no TRUNCATE será
sincrónica y atómica en su sistema de ficheros, y es importante para
usted que su base de datos de sobrevivir a un corte de energía o fallo del
sistema operativo que se produce durante la operación de truncamiento,
entonces usted podría considerar el uso de un modo de diario diferentes.
En los sistemas integrados con sistemas de archivos sincronizados,
TRUNCATE como resultado un comportamiento más lento que
persisten. La operación de confirmación es la misma velocidad. Pero las
transacciones posteriores son más lentos después de un TRUNCATE
porque es más rápido para sobrescribir el contenido existente que desea

Corp.

añadir a la final de un archivo. Nuevas entradas del archivo de diario
siempre se añaden después de un TRUNCATE pero por lo general se
sobrescribe con persisten.

8.0 Pruebas de Comportamiento Commit Atómica
Los desarrolladores de SQLite están seguros de que es robusto frente a
los apagones y caídas del sistema debido a que los procedimientos de
prueba automáticos hacen controles extensos sobre la capacidad de
SQLite para recuperarse de la pérdida de potencia simulado. Los llamamos
los "crash test".
Las pruebas de choque en SQLite utiliza un VFS modificados que pueden
simular los tipos de daños del sistema de archivos que se producen
durante un corte de energía o fallo del sistema operativo. El VFS las
pruebas de choque pueden simular sector incompleta escribe, páginas
llenas de datos de la basura debido a una operación de escritura no se ha
completado, y fuera de orden escribe, todos los que ocurren en puntos
diferentes durante un escenario de prueba. Las pruebas de choque
ejecutan operaciones una y otra, la variación de la hora a la que se
produce una pérdida de potencia simulado y las propiedades de los daños
infligidos. Cada prueba a continuación, se vuelve a abrir la base de datos
después de la simulación de accidentes y verifica que se produjo la
transacción ya sea completamente o no en absoluto y que la base de
datos está en un estado completamente consistente.
Las pruebas de choque en SQLite han descubierto una serie de errores
muy
sutiles
(actualmente
fijado)
en
el
mecanismo
de
recuperación. Algunos de estos errores eran muy oscuro y es improbable
que se han encontrado sólo con la inspección de código y técnicas de
análisis. A partir de esta experiencia, los desarrolladores de SQLite se
sienten seguros de que cualquier otro sistema de base de datos que no
utiliza un sistema de pruebas de choque similares probablemente
contenga errores no detectados que conduzcan a la corrupción de bases
de datos después de una caída del sistema o fallo de alimentación.

9.0 Actividades que pueden surgir
El mecanismo de confirmación atómica en SQLite ha demostrado ser
sólida, pero puede ser eludido por un adversario suficientemente creativo
o una implementación del sistema operativo suficientemente roto. Esta
sección describe algunas de las formas en que una base de datos SQLite
podría estar dañado por un corte de energía o fallo del sistema. (Ver
también: Cómo corromper sus archivos de base de datos .)

Corp.

9.1 Implementaciones bloqueo rotos
SQLite utiliza bloqueos de sistema de archivos para asegurarse de que
sólo un proceso de conexión de base de datos y está tratando de
modificar la base de datos a la vez. El mecanismo de bloqueo del sistema
de archivos se implementa en la capa VFS y es diferente para cada
sistema operativo. SQLite depende de esta aplicación es correcta. Si algo
sale mal, y dos o más procesos son capaces de escribir el mismo archivo
de base de datos al mismo tiempo, puede dar lugar a graves daños.
Hemos recibido informes de las implementaciones de sistemas de ficheros
de red de Windows y NFS en el que cierre estaba roto sutilmente. No
podemos verificar estos informes, pero como bloqueo es difícil hacerlo
bien en un sistema de archivos de red no tenemos ninguna razón para
dudar de ellos. Se recomienda evitar el uso de SQLite en un sistema de
archivos de red, en primer lugar, ya que el rendimiento será lenta. Sin
embargo, si debe utilizar un sistema de archivos de red para almacenar
los archivos de base de datos SQLite, considere el uso de un mecanismo
de bloqueo secundario para evitar simultánea escribe a la misma base de
datos, incluso si el sistema de archivos nativo de bloqueo mecanismo
averías.
Las versiones de SQLite que vienen preinstaladas en computadoras Apple
Mac OS X contiene una versión de SQLite que se ha extendido el uso de
estrategias de fijación alternativos que funcionan en todos los sistemas de
archivos de red que Apple apoya. Estas extensiones utilizadas por Apple
funcionan muy bien, siempre y cuando todos los procesos que están
accediendo
al
archivo
de
base
de
datos
en
la
misma
forma. Desafortunadamente, los mecanismos de bloqueo no se excluyen
entre sí, por lo que si un solo proceso está accediendo a un archivo
utilizando (por ejemplo) AFP bloqueo y otro proceso (tal vez en un equipo
diferente) es el uso de bloqueos de archivos punto-, los dos procesos
pueden colisionar porque AFP cerraduras no excluyen cerraduras dot-file o
viceversa.

9.2 Vacía disco incompletas
SQLite utiliza fsync () llamada al sistema en Unix y los FlushFileBuffers ()
llamada al sistema de w32 con el fin de sincronizar los buffers del sistema
de archivos en óxido de disco, como se muestra en el paso 3.7 y paso
3.10 . No se ha recibido información de que ninguno de estas interfaces
funciona como se anuncia en muchos sistemas. Nos enteramos de que
FlushFileBuffers () se pueden desactivar por completo con la configuración
del Registro en algunas versiones de Windows. Algunas versiones antiguas
de Linux contienen versiones de fsync () que son no-ops en algunos

Corp.

sistemas de archivos, se nos dice. Incluso en sistemas donde
FlushFileBuffers fsync () y () se dice que están trabajando, a menudo el
control de disco IDE miente y dice que los datos ha alcanzado el óxido,
mientras que todavía se lleva a cabo sólo en la memoria caché de control
volátil.
En el Mac, puede establecer esta pragma:
PRAGMA fullfsync = ON;
Configuración fullfsync en un Mac garantizará que los datos realmente no
quedarse relegados a la bandeja de disco en un color. Pero la aplicación
de fullfsync implica restablecer el controlador de disco. Y no sólo es
profundamente lento, también ralentiza otro disco sin relación I / O. Por lo
tanto no se recomienda su uso.

9.3 Las supresiones de archivos parciales
SQLite asume que la eliminación de archivos es una operación atómica
desde el punto de vista de un proceso de usuario. Si falla la alimentación
del medio de eliminación de un archivo, a continuación, después de que se
restablezca la alimentación SQLite espera para ver ya sea el archivo
completo con todos sus datos originales intactas, o se espera que no
encontrar el archivo en absoluto. Las transacciones pueden no ser atómico
en sistemas que no funcionan de esta manera.

9.4 de basura escrita en archivos
Archivos de base de datos SQLite son archivos de disco normales que se
pueden abrir y escritas por los procesos de usuario común. Un proceso
pícaro puede abrir una base de datos SQLite y llenarlo con los datos
corruptos. Datos corruptos también pueden ser introducidos en una base
de datos SQLite por fallos en el sistema operativo o el controlador de
disco, especialmente insectos provocadas por un fallo eléctrico. No hay
nada SQLite puede hacer para defenderse de este tipo de problemas.

9.5 Eliminar o cambiar el nombre de un diario caliente
Si un accidente o pérdida de potencia se produce y una revista caliente se
deja en el disco, es esencial que el archivo de base de datos original y la
revista caliente permanecen en el disco con su nombre original hasta que
el archivo de base de datos es abierta por otro proceso SQLite, removió
. Durante la recuperación en el paso 4.2 SQLite localiza la revista caliente
mediante la búsqueda de un archivo en el mismo directorio que la base de
datos se abre y cuyo nombre se deriva del nombre del archivo que se

Corp.

abrió. Si bien el archivo de base de datos original y la revista caliente se
han movido o cambiado de nombre, entonces la revista caliente no se ve y
la base de datos no se puede deshacer.
Tenemos la sospecha de que un modo de fallo común para la recuperación
SQLite sucede así: Un fallo en la alimentación. Después de que se
restablezca el suministro eléctrico, un usuario o administrador del sistema
bienintencionado comienza mirando a su alrededor en el disco
dañado. Ven a su archivo de base de datos llamada "important.data". Este
archivo es quizá familiar para ellos. Pero después del accidente, también
hay un diario caliente llamado "important.data-journal". A continuación, el
usuario elimina la revista caliente, pensando que están ayudando a la
limpieza del sistema. No sabemos de ninguna manera de prevenir esto
con excepción de la formación de usuarios.
Si hay varios (duro o simbólico) enlaces a un archivo de base de datos, la
revista se crea con el nombre de la conexión a través del cual se abrió el
archivo. Si se produce un bloqueo y la base de datos se vuelve a abrir con
un enlace diferente, la revista caliente no se encuentra y no se producirá
ninguna reversión.
A veces, un corte de energía hará que un sistema de archivos que se
corrompe de forma que nombres de archivos recientemente modificados
se olvidan y el archivo se mueve en un "/ lost + found" directorio. Cuando
eso sucede, la revista caliente no se encontró y no se producirá la
recuperación. SQLite intenta evitar esto mediante la apertura y sincronizar
el directorio que contiene el diario de reversión al mismo tiempo que
sincroniza la revista propio archivo.Sin embargo, el movimiento de
archivos en / lost + found puede ser causada por procesos no
relacionados creación de archivos no relacionados en el mismo directorio
que el archivo de base de datos principal. Y puesto que se trata de salir de
debajo el control de SQLite, no hay nada que SQLite puede hacer para
prevenirla. Si está ejecutando en un sistema que es vulnerable a este tipo
de sistema de archivos corrupción espacio de nombres (sistemas de
ficheros transaccional más modernos son inmunes, creemos), entonces es
posible que desee considerar la posibilidad de cada archivo de base de
datos SQLite en su propio subdirectorio privado.

10.0 Directrices para el futuro y la conclusión
De vez en cuando alguien descubre un nuevo modo de fallo del
mecanismo de confirmación atómica en SQLite y los desarrolladores
tienen que poner en un parche. Esto sucede cada vez menos y los modos
de fallo son cada vez más oscuro. Pero aún sería absurdo suponer que la

Corp.

lógica confirmación atómica de SQLite es totalmente libre de errores. Los
desarrolladores se han comprometido a la fijación de estos errores tan
rápido como pudieran ser encontrados.
Los desarrolladores también están en la búsqueda de nuevas formas de
optimizar el mecanismo de confirmación. Las implementaciones actuales
de VFS para Unix (Linux y Mac OS X) y Windows hacen suposiciones
pesimistas sobre el comportamiento de los sistemas. Tras consultar con
expertos sobre cómo funcionan estos sistemas, podríamos ser capaces de
relajar algunas de las hipótesis sobre estos sistemas y permitir que se
ejecuten más rápido. En particular, se sospecha que los sistemas de
archivos más modernos presentan la propiedad append y seguro que
muchos de ellos podrían apoyar sector atómico escribe. Pero hasta que no
se sabe a ciencia cierta, SQLite tomará el enfoque conservador y asumir lo
peor.

Base de datos SQL de mayor despliegue
Creemos que hay más copias de SQLite en uso en todo el mundo que
cualquier otro motor de base de datos SQL, y posiblemente todos los otros
motores de bases de datos SQL combinado. No podemos estar seguros de
esto, ya que no tenemos forma de medir ya sea el número de
implementaciones de SQLite ni el número de despliegues de otras bases
de datos. Pero creemos que el reclamo es defendible.
La creencia de que SQLite es el motor de base de datos SQL de mayor
despliegue se deriva de su uso como una base de datos integrada. Otros
motores de base de datos, como MySQL, PostgreSQL o Oracle, se
encuentran típicamente uno a un servidor. Y por lo general un único
servidor puede servir a varios usuarios. Con SQLite, por otro lado, un
único usuario tendrá típicamente el uso exclusivo de múltiples copias de
SQLite. SQLite se utiliza en los servidores, pero también se utiliza en el PC
de escritorio, y en los teléfonos móviles y PDAs y reproductores de MP3, y
set-top boxes.

Estimaciones
A finales de 2006, había 100 millones de sitios web en
Internet. [1] Vamos a usar ese número como un indicador de la cantidad
de motores de bases de datos SQL desplegados distintos SQLite. No todos
los sitios web se ejecuta un motor de base de datos SQL, y no todos los
motores de base de datos SQL tiene un sitio web. Páginas web más
grandes ejecutar múltiples motores de base de datos. Pero la gran
mayoría de los sitios web más pequeños (la larga cola) comparten un
motor de base de datos con varios otros sitios web, si utilizan un motor de

Corp.

base de datos en absoluto. Y muchas instalaciones de SQL bases de datos
grandes no tienen nada que ver con los sitios web. Así, utilizando el
número de sitios web como un sustituto para el número de motores de
bases de datos operacionales SQL es una burda aproximación, pero es lo
mejor que tenemos, así que vamos a ir con él. (Los lectores son alentados
a presentar una mejor estimación.)
Ahora vamos a considerar cuando se utiliza SQLite:
300 millones de copias de Mozilla Firefox.
20 millones de ordenadores Mac, cada uno de los cuales contiene
varias copias de SQLite
20 millones de sitios web que se ejecutan PHP SQLite construido
adentro [3] No tenemos forma de estimar qué fracción de estos
sitios utilizan activamente SQLite, pero creemos que es una fracción
significativa.
450 millones registrados de Skype los usuarios.
20 millones de teléfonos inteligentes Symbian enviados en Q3
2007 [5] Las nuevas versiones de los SymbianOS SQLite han
construido adentro No está claro exactamente cómo muchos
teléfonos Symbian contienen realmente SQLite, así que vamos a
utilizar las ventas de un solo trimestre en su límite inferior.
10 millones de instalaciones de Solaris 10, todos los cuales
requieren SQLite para poder arrancar.
Millones y millones de copias de McAfee software anti-virus de todo
el uso de SQLite interna.
Millones de iPhones utilizan SQLite
Millones y millones de otros teléfonos de fabricantes distintos de
Symbian y Apple utilizan SQLite. Esto no ha sido reconocido
públicamente por la fabrica, pero se sabe que los desarrolladores
SQLite.
Hay quizá millones de implementaciones adicionales de SQLite
SQLite que los desarrolladores no conocen.
Con estas estimaciones, vemos por lo menos 500 millones de utilizaciones
SQLite y unos 100 millones de despliegues de otros motores de bases de
datos SQL. Estas estimaciones son, evidentemente, muy duro y puede ser
significativamente. Pero
hay
un
amplio
margen. Así
que
los
desarrolladores SQLite piensan que es probable que SQLite es el motor de
base de datos SQL más utilizada en el mundo.

Corp.

SQLite autor
Todo el código y la documentación de
SQLite se ha dedicado al dominio público por
los autores. Todos los autores de código, y
representantes de las empresas para las
que trabajan, han firmado declaraciones
juradas dedicando sus contribuciones al
dominio público y los originales de esas
declaraciones
juradas
firmadas
se
almacenan en una prueba de fuego en la
sede de Hwaci . Cualquiera es libre de
SQLite es en el
copiar, modificar, publicar, usar, recopilar,
Dominio Público
vender o distribuir el código original SQLite,
ya sea en forma de código fuente o binario
compilado, para cualquier propósito, comercial o no comercial, y
por cualquier medio.

El párrafo anterior se aplica al código de entrega y documentación
en SQLite - las partes de la biblioteca de SQLite que realmente
paquete y envía con una aplicación más amplia. Algunas
secuencias de comandos utilizadas como parte del proceso de
construcción (por ejemplo, las secuencias de comandos
"configure" generados por autoconf) podrían caer bajo otras
licencias de código abierto. Nada de estos scripts de construcción
nunca llega a la biblioteca SQLite última entrega, sin embargo,
por lo que las licencias asociadas con estos scripts no deben ser
un factor en la evaluación de sus derechos a copiar y utilizar la
biblioteca SQLite.
Todo el código entregable en SQLite se ha escrito desde
cero. Ningún código se ha tomado de otros proyectos o de la
Internet abierta. Cada línea de código se puede remontar de
nuevo a su autor original, y todos los autores tienen dedicatorias
de dominio público en el archivo. Así que la base de código SQLite
está limpio y no está contaminada con el código de licencia de
otros proyectos.
La obtención de una Licencia explícito para usar SQLite

Corp.

A pesar de que SQLite es de dominio público y no requiere de una licencia,
algunos usuarios quieren obtener una licencia de todos modos. Algunas de
las razones para obtener una licencia son:
Está utilizando SQLite en una jurisdicción que no reconoce el
dominio público.
Está utilizando SQLite en una jurisdicción que no reconoce el
derecho de un autor a dedicar su trabajo al dominio público.
¿Quieres celebrar un documento legal como prueba tangible de que
tiene el derecho legal para usar y distribuir SQLite.
Su departamento jurídico le dice que usted tiene que comprar una
licencia.
Si usted siente que realmente tiene que comprar una licencia para
SQLite, Hwaci , la compañía que emplea el arquitecto y los desarrolladores
principales de SQLite, se venderle uno .

Código Contribuyó
Para mantener SQLite completamente libre y no sujeto a copyright, todos
los nuevos contribuyentes a la base de código SQLite se les pide que
dediquen sus contribuciones al dominio público. Si desea enviar un parche
o mejora para su posible inclusión en el árbol de fuentes SQLite, por
favor, con la modificación con la siguiente declaración:
El autor o los autores de este código dedican todos y cualquier derecho de
autor en este código para el dominio público. Hacemos esta dedicación en
beneficio del público en general y en detrimento de nuestros herederos y
sucesores. Tenemos la intención de esta dedicación a ser un acto abierto
de la cesión a perpetuidad de todos los derechos presentes y futuros a
este código bajo la ley de derechos de autor.
No estamos en condiciones de aceptar parches o modificaciones de SQLite
que no vayan acompañados de una declaración como la anterior. Además,
si realiza cambios o mejoras como un empleado, entonces una simple
declaración como la anterior es insuficiente. También debe enviar por
correo ordinario una liberación de derechos de autor firmada por un
funcionario de la compañía. Un original firmado de la liberación de
derechos de autor deben ser enviadas a:

Hwaci
6200 arce Lane Cove

Corp.

Charlotte, NC 28269
EE.UU.
Un comunicado de copyright plantilla está disponible en formato
PDF o HTML . Puede utilizar esta versión para hacer cambios en el futuro.

Estado actual
Versión 3.8.1 de SQLite se recomienda para todos los nuevos
desarrollos. Actualización desde la versión 3.7.17 y 3.8.0.2 es
opcional. Se recomienda actualizar desde el resto de versiones
anteriores de SQLite.

SQLite Release 3.8.1 El 17/10/2013 (3.8.1)
Añadido el improbable () y la probabilidad () Las funciones de SQL
para ser utilizados como pistas para el planificador de consulta.
Mejoras en el planificador de la consulta:
o Tener en cuenta el hecho de cláusula DONDE términos que no
se pueden utilizar con índices todavía probablemente reducen
el número de filas de salida.
o Estimar el tamaño de la tabla y las filas de índice y utilizar el
más pequeño aplicable B-Tree para las exploraciones
completas y "Count (*)" operaciones.
Añadido el pragma soft_heap_limit .
Añadido soporte para SQLITE_ENABLE_STAT4
Añadido soporte para "sz = NNN" parámetros al final
de sqlite_stat1.stat campos que se utilizan para especificar la
longitud promedio de bytes de la tabla y las filas de índice.
Evite ejecutar comprobaciones de restricción de clave externa en
una actualización si ninguna de las columnas modificadas están
asociados con las claves externas.
Añadido el SQLITE_MINIMUM_FILE_DESCRIPTOR opción en tiempo
de compilación
Añadido el VFS win32-LongPath en las ventanas, lo que permite
nombres de archivo de hasta 32 K caracteres.
Los de fecha y hora se han mejorado para que la hora actual (por
ejemplo: julianday ("ahora")) es siempre la misma para múltiples

Corp.

invocaciones de funciones dentro de la misma sqlite3_step
() llamada.
Agregue la extensión "totype.c", la aplicación de la tointeger () y
toreal () Las funciones de SQL.
FTS4 consultas son más capaces de hacer uso de iddoc <$ limitar
las restricciones para limitar la cantidad de obligado I / O.
Añadida la oculta la columna fts4aux LanguageID al fts4aux mesa
virtual.
El VACÍO comando paquetes de la base de datos de alrededor de
1% más fuerte.
El programa de utilidad sqlite3_analyzer se actualiza para ofrecer
mejores descripciones y para calcular una estimación más precisa de
"páginas no secuencial"
Refactorizar la ejecución de sentencias PRAGMA para mejorar el
rendimiento de análisis.
El directorio utilizado para almacenar los archivos temporales en
UNIX ahora se puede establecer mediante la variable de entorno
SQLITE_TMPDIR, que tiene prioridad sobre la variable de entorno
TMPDIR. Elsqlite3_temp_directory variable global todavía tiene
mayor prioridad que ambas variables de entorno, sin embargo.
Añadido el stats PRAGMA comunicado.
Corrección de errores: Devuelve la respuesta correcta para
"SELECT count (*) FROM tabla", incluso si hay uníndice parcial sobre
la mesa. Ticket a5c8ed66ca .
SQLITE_SOURCE_ID: "10/17/2013 12:57:35
c78be6d786c19073b3a6730dfe3fb1be54f5657a"
SHA1 para sqlite3.c:
0a54d76566728c2ba96292a49b138e4f69a7c391
Una lista completa de las versiones de SQLite en una sola página también
está disponible. Una historia detallada de cada check-in está disponible
en http://www.sqlite.org/src/timeline .

Corp.

Funciones básicas
Las funciones básicas que se muestran a continuación están disponibles de forma
predeterminada. Fecha y hora funciones y funciones de agregado se documentan por
separado. Una aplicación puede definir funciones adicionales escritos en C y se añadió a
la base de datos utilizando el motor de sqlite3_create_function () API.

abs (X)

La función abs (X) devuelve el valor absoluto del
argumento numérico X. Abs (X) devuelve NULL si
X es NULL. Abs (X) devuelve 0,0 si X es una
cadena o mancha que no se puede convertir en un
valor numérico. Si X es el número entero 9223372036854775807 a continuación, ABS (X)
genera un error de desbordamiento de enteros ya
que no hay 64 bits de dos valor equivalente
complemento positivo.

(cambios)

Los cambios () devuelve el número de filas de la
base de datos que han sido modificados o
insertados o borrados por el más reciente INSERT,
DELETE o UPDATE, exclusiva de los estados en
disparadores de nivel inferior. Los cambios ()
función SQL es una envoltura alrededor de
las sqlite3_changes () C / C + + y por lo tanto la
función sigue las mismas reglas para contar los
cambios.

char (X1, X2, ..., XN)

La función char (X1, X2, ..., XN) devuelve una
cadena compuesta de personajes que tienen los
valores de punto de código Unicode de enteros X1
a XN, respectivamente.

coalescer (X, Y, ...)

La coalescencia () devuelve una copia de su
primer argumento que no es nulo, o NULL si todos
los argumentos son NULL. Coalesce () debe ser de
al menos 2 argumentos.

glob (X, Y)

La función glob (X, Y) es equivalente a la
expresión "Y GLOB X". Tenga en cuenta que el X
y el Y argumentos se invierten en el glob ()
funciona
en
relación
con
el
infijo GLOB operador. Si el sqlite3_create_function
() se usa para anular la interfaz de glob (X, Y) con

Corp.

función de una implementación
continuación,
laGLOB operador
aplicación alternativa.

alternativa a
invocar
la

IFNULL (X, Y)

El IFNULL () devuelve una copia de su primer
argumento que no es NULL, o NULL si ambos
argumentos son NULL. IFNULL () debe tener
exactamente 2 argumentos. La función IFNULL ()
es equivalente a coalescer () con dos argumentos.

instr (X, Y)

El instr (X, Y) función busca la primera aparición
de cadena en cadena Y X y devuelve el número de
caracteres anterior más 1 o 0 si Y se encuentra en
ninguna parte dentro de X. O bien, si X e Y son
ambos BLOB, entonces instr (X, Y) devuelve uno
más que el número de bytes de antes de la
primera ocurrencia de Y, o 0 si Y no se produce en
cualquier lugar dentro de X. Si ambos argumentos
X e Y en Instrumento (X, Y) son no NULL y son no
BLOB
luego
ambos
se
interpretan
como
cadenas. Si X o Y son NULL en instr (X, Y),
entonces el resultado es NULL.

hex (X)

El hex () función interpreta su argumento como un
BLOB y devuelve una cadena que es la
representación hexadecimal en mayúsculas del
contenido de esa nota.

last_insert_rowid ()

El last_insert_rowid () devuelve el ROWID de la
última fila de inserción de la conexión de base de
datos
que
se
invoca
la
función. El
last_insert_rowid () de SQL es una envoltura
alrededor de la sqlite3_last_insert_rowid () función
de interfaz C / C + +.

longitud (X)

Para un valor de serie X, la longitud (X) devuelve
el número de caracteres (no bytes) en X antes del
primer carácter NUL. Desde cadenas SQLite
normalmente no contienen caracteres NUL, la
longitud (X) la función normalmente devolverá el

Corp.

número total de caracteres en la cadena de X.
Para un valor blob X, la longitud (X) devuelve el
número de bytes en el blob. Si X es NULL entonces
la longitud (X) es NULL. Si X es numérico a
continuación, la longitud (X) devuelve la longitud
de una representación de cadena de X.

como (X,
como (X, Y, Z)

Y)

El gusto () se utiliza para poner en práctica la "Y
COMO X [ESCAPE Z]" expresión.Si la cláusula
ESCAPE opcional está presente, entonces el estilo
() se invoca con tres argumentos. De lo contrario,
se invoca con sólo dos argumentos. Tenga en
cuenta que los parámetros X e Y se invierten en la
función
como
()
en
relación
con
el
infijo LIKE operador. El sqlite3_create_function
() interfaz puede utilizarse para anular el estilo ()
y por lo tanto cambiar el funcionamiento
del LIKE operador. Al reemplazar la función como
(), puede ser importante para reemplazar ambos
dos y tres versiones de argumentos de la función
como (). De lo contrario, el código diferente puede
ser llamado para implementar el LIKE operador en
función de si o no se ha especificado una cláusula
de escape.

probabilidad (X, Y)

La probabilidad (X, Y) devuelve argumento X sin
cambios. El valor de Y en la probabilidad (X, Y)
debe ser una constante de coma flotante entre 0.0
y 1.0, inclusive. La probabilidad (X) es una función
no-op que el generador de código de distancia
optimiza para que no consume ciclos de la CPU
durante el tiempo de ejecución (es decir, durante
las llamadas a sqlite3_step () ). El propósito de la
función de probabilidad (X, Y) es proporcionar una
pista para el planificador de consulta que el
argumento X es un valor booleano que es cierto
con una probabilidad de aproximadamente Y.
El poco probable (X) es la función de corto mano
para la probabilidad ( X, 0,0625).

load_extension (X)

El load_extension (X, Y) función carga SQLite
extensiones fuera del archivo de biblioteca

Corp.

load_extension (X, Y)

compartida llamada X utilizando el punto de
entrada Y. El resultado de load_extension () es
siempre un valor NULL. Y si se omite se utiliza el
nombre del punto de entrada por defecto. El
load_extension () función lanza una excepción si la
extensión no se puede cargar o inicializar
correctamente.
La función load_extension () fallará si la extensión
intenta modificar o eliminar una función de SQL o
secuencia de clasificación. La extensión puede
añadir nuevas funciones o secuencias de
clasificación, pero no puede modificar o eliminar
funciones existentes o secuencias de clasificación
porque esas funciones y / o secuencias de
clasificación pueden ser utilizados en la instrucción
SQL se está ejecutando en otro lugar. Para cargar
una extensión que cambia o elimina funciones o
secuencias
de
intercalación,
utilice
el sqlite3_load_extension () del lenguaje C API.
Por razones de seguridad, la extensión con carga
está desactivada de forma predeterminada y debe
habilitarse mediante una llamada antes de
lasqlite3_enable_load_extension () .

bajar (X)

Cuanto más bajo (X) devuelve una copia de
cadena X con todos los caracteres ASCII
convertidos a minúsculas. La función integrada
predeterminada en bajar () funciona sólo
caracteres ASCII. Para hacer conversiones de
casos sobre los caracteres no ASCII, cargar la
extensión UCI.

ltrim (X)
ltrim (X, Y)

El ltrim (X, Y) función devuelve una cadena
formada mediante la eliminación de cualquier y
todos los caracteres que aparecen en Y desde el
lado izquierdo de X. Si se omite el argumento Y,
ltrim (X) elimina los espacios desde el lado
izquierdo de X.

máx (X, Y, ...)

El multi-argumento max () devuelve el argumento
con el valor máximo, o NULL regreso si algún
argumento es NULL. El multi-argumento de la
función max () busca en sus argumentos de

Corp.

izquierda a derecha de un argumento que define
una función de clasificación y utiliza esa función
colateral para todas las comparaciones de
cadenas. Si ninguno de los argumentos para max
() define una función de clasificación, a
continuación, se utiliza la función de clasificación
binario. Tenga en cuenta que max () es una
función simple cuando tiene 2 o más argumentos,
pero opera como una función agregada si se les da
un solo argumento.

min (X, Y, ...)

El multi-argumento min () devuelve el argumento
con el valor mínimo. El multi-argumento min ()
función busca sus argumentos de izquierda a
derecha de un argumento que define una función
de clasificación y utiliza esa función colateral para
todas las comparaciones de cadenas. Si ninguno
de los argumentos a min () define una función de
clasificación, a continuación, se utiliza la función
de clasificación binario. Tenga en cuenta que min
() es una función simple cuando tiene 2 o más
argumentos, pero opera como una función
agregada si se les da un solo argumento.

NULLIF (X, Y)

El NULLIF (X, Y) devuelve su primer argumento si
los argumentos son diferentes y NULL si los
argumentos son los mismos. El NULLIF (X, Y)
función busca sus argumentos de izquierda a
derecha de un argumento que define una función
de clasificación y utiliza esa función colateral para
todas las comparaciones de cadenas. Si ni
argumento para NULLIF () define una función de
clasificación se utiliza el binario.

citar a (X)

La cita (X) devuelve el texto de un literal SQL que
es el valor de su argumento adecuado para su
inclusión en una sentencia SQL. Las cuerdas están
rodeados de comillas simples con escapes de citas
interiores, según sea necesario. BLOB se codifican
como
literales
hexadecimales. Cuerdas
con
caracteres NUL incorporadas no pueden ser
representados como literales de cadena en SQL y

Corp.

por lo tanto la cadena devuelta literal se truncan
antes de la primera NUL.

aleatorio ()

La función random () devuelve un entero pseudoaleatorio
entre
-9223372036854775808
y
9223372036854775807.

randomblob (N)

La función randomblob (N) devuelve un objeto
binario de N bytes que contiene bytes pseudoaleatorios. Si N es menor que 1, entonces se
devuelve una mancha aleatoria de 1 byte.
Sugerencia: las aplicaciones pueden generar
identificadores únicos globales utilizando esta
función junto con hex () y / o inferior () así:
hex

(randomblob

(16))

bajar (hex (randomblob (16)))

replace (X, Y, Z)

El reemplazo (X, Y, Z) función devuelve una
cadena formada mediante la sustitución de cadena
Z para cada ocurrencia de cadena de Y en la
cadena de X. ElBINARIO secuencia de clasificación
se utiliza para las comparaciones. Si Y es una
cadena vacía luego regresar X sin cambios. Si Z no
es inicialmente una cadena, se convierte en una
cadena antes de su procesamiento UTF-8.

round (X)
round (X, Y)

La ronda (X, Y) devuelve un valor de punto
flotante de X redondeado a un dígito Y a la
derecha del punto decimal. Si se omite el
argumento Y, que se supone que es 0.

rtrim (X)
rtrim (X, Y)

El rtrim (X, Y) función devuelve una cadena
formada mediante la eliminación de cualquier y
todos los caracteres que aparecen en Y desde el
lado derecho de X. Si se omite el argumento Y,
rtrim (X) elimina los espacios desde el lado
derecho de X.

Corp.

Base de Datos Relacional

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (17)

Similaire à Base de Datos Relacional

Similaire à Base de Datos Relacional (20)

Dernier

Dernier (20)

Base de Datos Relacional