base de datos relacional
TRANSCRIPT
Corp.
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 financial-
information technology.
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 sufijos
aleatorios HHHHHHHH para cada nueva publicación principal.
(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 "PERSIST" utilizando
el journal_mode PRAGMA. Por ejemplo: Journal_mode PRAGMA = persistir;
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 copiar, modificar, publicar, usar, recopilar, 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
SQLite es en el
Dominio Público
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 alternativa a
continuación, laGLOB operador invocar la
aplicación alternativa.
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, Y)
como (X, Y, Z)
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 pseudo-
aleatorio entre -9223372036854775808 y
9223372036854775807.
randomblob (N) La función randomblob (N) devuelve un objeto
binario de N bytes que contiene bytes pseudo-
aleatorios. 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.
soundex (X) El soundex (X) devuelve una cadena que es la
codificación de la cadena soundex X. La cadena "?
000" se devuelve si el argumento es nulo o no
contiene caracteres alfabéticos ASCII. Esta función
se omite de SQLite de forma predeterminada. Sólo
está disponible si el SQLITE_SOUNDEX opción en
tiempo de compilación se utiliza cuando SQLite se
construye.
sqlite_compileoption_get(N) El sqlite_compileoption_get () de SQL es una
envoltura alrededor de
lasqlite3_compileoption_get () función de C / C +
+. Esta rutina devuelve la opción N-ésimo tiempo
de compilación utilizado para construir SQLite o
NULL si N está fuera de rango. Ver también
el pragma compile_options .
sqlite_compileoption_used(X) La función SQL sqlite_compileoption_used () es
una envoltura alrededor de
lasqlite3_compileoption_used () función de C / C +
+. Cuando el argumento X
sqlite_compileoption_used (X) es una cadena que
es el nombre de una opción en tiempo de
compilación, esta rutina devuelve verdadero (1) o
falso (0), en función de si esa opción fue utilizado
durante la construcción.
sqlite_source_id () El sqlite_source_id () devuelve una cadena que
identifica la versión específica del código fuente
que se utilizó para construir la biblioteca
SQLite. La cadena devuelta por sqlite_source_id ()
comienza con la fecha y hora en que el código
fuente se registró y se sigue por un hash SHA1
que identifica el árbol de fuentes. Esta función es
una envoltura alrededor del SQL sqlite3_sourceid
() C interfaz.
SQLITE_VERSION () El SQLITE_VERSION () devuelve la cadena de
versión de la biblioteca de SQLite que se está
ejecutando. Esta función es una envoltura
alrededor del SQLsqlite3_libversion () C-interface.
Corp.
substr (X, Y, Z)
substr (X, Y)
El substr (X, Y, Z) devuelve una subcadena de
cadena de entrada X que comienza con la Y-ésimo
carácter y que es Z caracteres de largo. Si se
omite Z a continuación, substr (X, Y) devuelve
todos los caracteres a través del final de la cadena
X que comienza con la Y-ésima. El carácter más a
la izquierda de la X es el número 1. Si Y es
negativo, el primer carácter de la subcadena se
encuentra contando desde la derecha y no la
izquierda. Si Z es negativo, se devuelven los
caracteres abs (z) que preceden al carácter Y-
th. Si X es una cadena de caracteres y luego los
índices se refieren a UTF-8 actual caracteres. Si X
es un BLOB a continuación, se refieren a los
índices de bytes.
total_changes () Los total_changes () devuelve el número de fila
cambia causados por INSERT, UPDATE o DELETE
desde que se abre la conexión de base de datos
actual. Esta función es una envoltura alrededor de
la sqlite3_total_changes () C / C + + interfaz.
trim (X)
trim (X, Y)
La función de ajuste (X, Y) devuelve una cadena
formada mediante la eliminación de cualquier y
todos los caracteres que aparecen en Y desde
ambos extremos de X. Si se omite el argumento Y,
el asiento (X) elimina los espacios de ambos
extremos de X.
typeof (X) El typeof (X) devuelve una cadena que indica
el tipo de datos de la expresión X: "null", "entero",
"reales", "texto", o "burbuja".
poco probable (X) El (X) Función improbable devuelve el argumento
X sin cambios. El (X) es poco probable que la
función de un no-op que el generador de código de
distancia optimiza para que no consume ciclos de
CPU en tiempo de ejecución (es decir, durante las
llamadas a sqlite3_step () ). El propósito de la (X)
Función probable es proporcionar una pista para el
planificador de consulta que el argumento X es un
Corp.
valor booleano que por lo general no es cierto. La
función poco probable (X) es equivalente a
la probabilidad (X, 0,0625).
unicode (X) La función unicode (X) devuelve el punto de
código Unicode numérico correspondiente al
primer carácter de la cadena X. Si el argumento
de unicode (X) no es una cadena, el resultado no
está definido.
superior (X) La parte superior (X) devuelve una copia de la
cadena de entrada X en la que todos los
caracteres ASCII minúsculas se convierten en
mayúsculas su equivalente.
zeroblob (N) La función zeroblob (N) devuelve un BLOB que
consiste en N bytes de 0x00. SQLite gestiona
estos zeroblobs muy eficiente. Zeroblobs se
pueden utilizar para reservar espacio para un
BLOB que se escribe más adelante mediante BLOB
incremental de E / S . Esta función SQL se
implementa mediante la sqlite3_result_zeroblob
() de rutina de la interfaz de C C / C + +.
De fecha y hora
SQLite apoya cinco funciones de fecha y hora de la siguiente manera:
1. fecha (TimeString, modificador modificador, ...)
2. tiempo (TimeString, modificador modificador, ...)
3. datetime (TimeString, modificador modificador, ...)
4. julianday (TimeString, modificador, modificador, ...)
5. strftime (formato, TimeString, modificador modificador, ...)
Las cinco funciones de fecha y hora tienen una cadena de tiempo como argumento. La
cadena de tiempo es seguido por cero o más modificadores. La función strftime ()
también toma una cadena de formato como primer argumento.
Las funciones de fecha y hora de utilizar un subconjunto de IS0-8601 formatos de fecha
y hora. La fecha () devuelve la fecha en este formato: AAAA-MM-DD. El tiempo ()
devuelve el tiempo HH: MM: SS. La fecha y hora () devuelve "AAAA-MM-DD HH: MM:
SS". La función julianday () devuelve el día juliano - el número de días desde el mediodía
en Greenwich el 24 de noviembre de 4714 antes de Cristo ( proléptico calendario
gregoriano ). El strftime () rutina devuelve la fecha con formato según la cadena de
formato especificado como el primer argumento. La cadena de formato compatible con
las sustituciones más comunes que se encuentran en la función strftime () de la librería
Corp.
estándar de C más dos nuevas sustituciones,% f y% J. La siguiente es una lista completa
de strftime () sustituciones válidas:
% D
día del mes: 00
% F
fracciones de segundo: ss.sss
% H
hora: 00-24
% J
día del año: 001-366
% J
Número de día juliano
% M
mes: 01-12
% M
minutos: 00-59
% S
segundos desde 1970-01-01
% S
segundo: 00-59
% W
día de la semana con el domingo 0-6 == 0
% W
semana del año: 00-53
% Y
año: 0000-9999
%%
%
Observe que todas las demás funciones de fecha y hora se pueden expresar en términos
de strftime ():
Función
Equivalente strftime ()
fecha (...)
strftime ("% Y-% m-% d ', ...)
tiempo (...)
strftime ('% H:% M:% S', ...)
datetime (...)
strftime ("% Y-% m-% d% H:% M:% S ', ...)
julianday (...)
strftime ("% J ', ...)
Las únicas razones para proporcionar funciones distintas de strftime () es para la
conveniencia y la eficiencia.
Cuerdas Tiempo
Una cadena de tiempo puede estar en cualquiera de los siguientes formatos:
1. AAAA-MM-DD
2. AAAA-MM-DD HH: MM
3. AAAA-MM-DD HH: MM: SS
4. AAAA-MM-DD HH: MM: ss.sss
5. AAAA-MM-DD T HH: MM
6. AAAA-MM-DD T HH: MM: SS
7. AAAA-MM-DD T HH: MM: ss.sss
8. HH: MM
9. HH: MM: SS
10. HH: MM: ss.sss
11. ahora 12. DDDDDDDDDD
En los formatos de 5 a 7, la "T" es un carácter literal que separa la fecha y la hora, como
lo requiere la norma ISO-8601 . Formatos de 8 a 10 que especifica sólo una vez asuma
Corp.
una fecha del 2000-01-01. Formato 11, la cadena 'ahora', se convierte en la fecha y la
hora actual como obtenido a partir del método de la xCurrentTime sqlite3_vfsobjeto en
uso. El "ahora" argumento para funciones de fecha y hora siempre devuelve exactamente
el mismo valor para invocaciones múltiples dentro de la misma sqlite3_step
() llamada. Tiempo Universal Coordinado (UTC) se utiliza. Formato 12 es el número de días Julian expresado como un valor de punto flotante.
Formatos de 2 a 10 pueden estar opcionalmente seguido de un indicador de zona horaria
de la forma "[+ -] HH: MM" o simplemente "Z". Las funciones de fecha y hora utilizan
UTC o la hora "zulu" internamente, por lo que el sufijo "Z" es un no-op. Cualquier "HH:
MM" distinto de cero sufijo se resta de la fecha y hora indicada, con el fin de calcular el tiempo zulu. Por ejemplo, todas las siguientes cadenas de tiempo son equivalentes:
10/07/2013 08:23:19.120
2013-10-07T08: 23:19.120 Z
10/07/2013 08:23:19.120-04:00
2456572.84952685
En los formatos de 4, 7 y 10, las fracciones de segundo ss.sss valor pueden tener uno o
más dígitos después del punto decimal. Exactamente tres dígitos se muestran en los
ejemplos debido a que sólo los primeros tres dígitos son significativos para el resultado,
pero la cadena de entrada pueden tener menos o más de tres dígitos y las funciones de
fecha / tiempo seguirá funcionando correctamente. Del mismo modo, el formato 12 se
muestra con 10 dígitos significativos, pero las funciones de fecha / hora realmente
aceptar tantas o tan pocas cifras que sean necesarias para representar el número de día
juliano.
Modificadores
La cadena de tiempo puede ser seguido por cero o más modificadores que alteran la
fecha y / o tiempo. Cada modificador es una transformación que se aplica al valor de
tiempo a su izquierda. Los modificadores se aplican de izquierda a derecha, el orden es
importante. Los modificadores disponibles son los siguientes.
1. Día NNN
2. Hora NNN
3. Minutos NNN
4. Nnn.nnnn segundos
5. Mes NNN
6. Año NNN
7. inicio de mes
8. inicio de año
9. comienzo del día
10. día de la semana N
11. unixepoch
12. localtime
13. utc
Los primeros seis modificadores (1 a 6) sólo tiene que añadir la cantidad de tiempo que
la fecha y hora indicada por el TimeString y modificadores anterior. Tenga en cuenta que
"± meses NNN" trabaja por la prestación de la fecha original en el formato AAAA-MM-DD,
añadiendo el ± NNN al valor MM mes, normalizar el resultado. Así, por ejemplo, los datos
Corp.
2001-03-31 modificado por '1 mes' produce inicialmente 31.04.2001, abril, pero sólo
tiene 30 días por lo que la fecha se normaliza a 2001-05-01. Un efecto similar se produce
cuando la fecha original es el 29 de Marzo de un leapyear y el modificador es de ± años
N donde N no es un múltiplo de cuatro.
El "principio de" modificadores (7 a 9) cambiar la fecha hacia atrás hasta el principio del
mes en curso, el año o el día.
Los "entre semana" avances modificadoras de la fecha con interés la próxima fecha en
que el número de días de la semana es N. El domingo es 0, el lunes es 1, y así
sucesivamente.
El modificador "unixepoch" (11) sólo funciona si se sigue inmediatamente un TimeString
en el formato DDDDDDDDDD. Este modificador hace que el DDDDDDDDDD no debe
interpretarse como un número de días Julian, ya que normalmente sería, pero como Unix
Tiempo - el número de segundos desde 1970. Si el modificador "unixepoch" no sigue un
TimeString del DDDDDDDDDD forma que expresa el número de segundos desde 1970 o
si otros modificadores separan el modificador "unixepoch" de antes dddddddddd entonces
el comportamiento no está definido. Debido a las limitaciones de precisión impuestos por
las implementaciones de uso de enteros de 64 bits, el modificador "unixepoch" sólo
funciona para las fechas entre el 0000-01-01 00:00:00 y 5352-11-01 10:52:47 (tiempos
unix de -62167219200 través 10675199167).
El modificador "localtime" (12) asume la cadena de tiempo a su izquierda está en Tiempo
Universal Coordinado (UTC) y ajusta la cadena de tiempo para que muestre localtime. Si
"localtime" sigue a un tiempo que no es UTC, el comportamiento no está definido. El
"UTC" es lo contrario de "localtime". "UTC" supone que la cadena a su izquierda se
encuentra en la zona horaria local y ajusta esa cadena sea UTC. Si la cadena antes no
está en localtime, entonces el resultado de "UTC" no está definido.
Ejemplos
Calcular la fecha actual.
Date ("ahora") SELECT;
Calcule el último día del mes en curso.
Fecha SELECT ('ahora', 'comienzo de mes "," 1 mes "," día-1');
Calcular la fecha y hora determinada una marca de tiempo Unix 1092941466.
Datetime SELECT (1092941466, 'unixepoch');
Calcular la fecha y hora determinada una marca de tiempo Unix 1092941466 y
compensar su zona horaria local.
Datetime SELECT (1092941466, 'unixepoch', 'localtime');
Calcule la corriente timestamp unix.
SELECT strftime ('% s', 'ahora');
Calcular el número de días desde la firma de la Declaración de Independencia de EE.UU..
SELECT julianday ("ahora") - julianday ('1776-07-04 ');
Corp.
Calcular el número de segundos desde un momento determinado en el año 2004:
SELECT strftime ('% s', 'ahora') - strftime ('% s', '2004-01-01 02:34:56 ');
Calcular la fecha del primer martes de octubre del año en curso.
Fecha SELECT ('ahora', 'comienzo de año "," 9 meses "," día de la semana 2');
Calcular el tiempo transcurrido desde la época Unix en segundos (como strftime ('% s',
'ahora'), excepto incluye parte fraccional):
SELECT (julianday ("ahora") - 2.440.587,5) * 86400.0;
Advertencias y errores
El cómputo de tiempo local depende en gran medida de los caprichos de los políticos y
por lo tanto difícil de conseguir correcta para todas las configuraciones regionales. En
esta aplicación, la norma C biblioteca de funciones localtime_r () se utiliza para ayudar
en el cálculo de la hora local. El localtime_r () de C normalmente sólo funciona para los
años comprendidos entre 1970 y 2037. Para las fechas fuera de este rango, SQLite
intenta mapear el año en un año equivalente dentro de este rango, hacer el cálculo, a
continuación, asignar el año nuevo.
Estas funciones sólo funcionan para las fechas entre el 0000-01-01 00:00:00 y 9999-12-
31 23:59:59 (números de días julidan 1.721.059,5 5.373.484,5 través). Para las fechas fuera de ese rango, los resultados de estas funciones no están definidos.
Plataformas no Windows Vista sólo admiten un conjunto de reglas de DST. Vista sólo
admite dos. Por lo tanto, en estas plataformas, los cálculos DST históricos serán
incorrectos. Por ejemplo, en los EE.UU., en 2007 cambiaron las reglas de
DST. Plataformas no de Windows Vista se aplicarán las nuevas reglas de DST 2007 a
todos los años anteriores también. Vista tiene algo mejor obtener resultados correctos de
nuevo a 1986, cuando también se cambiaron las reglas.
Todos los cálculos internos asumen el calendario gregoriano sistema. Se supone también
que cada día es exactamente 86.400 segundos de duración.
SQLite C Interface
Crear o redefinir las funciones de SQL int sqlite3_create_function (
sqlite3 * db,
const char * zFunctionName,
int nArg,
int eTextRep,
void * pApp,
void (* xFunc) (sqlite3_context *, int, sqlite3_value **),
void (* xstep) (sqlite3_context *, int, sqlite3_value **),
void (* xfinal) (sqlite3_context *)
);
int sqlite3_create_function16 (
sqlite3 * db,
const void * zFunctionName,
Corp.
int nArg,
int eTextRep,
void * pApp,
void (* xFunc) (sqlite3_context *, int, sqlite3_value **),
void (* xstep) (sqlite3_context *, int, sqlite3_value **),
void (* xfinal) (sqlite3_context *)
);
int sqlite3_create_function_v2 (
sqlite3 * db,
const char * zFunctionName,
int nArg,
int eTextRep,
void * pApp,
void (* xFunc) (sqlite3_context *, int, sqlite3_value **),
void (* xstep) (sqlite3_context *, int, sqlite3_value **),
void (* xfinal) (sqlite3_context *),
void (* xDestroy) (void *)
);
Estas funciones (conocidas colectivamente como "función de creación de rutinas") se
utilizan para añadir funciones o agregados de SQL o redefinir el comportamiento de las
funciones o agregados SQL existentes. Las únicas diferencias entre estas rutinas son la
codificación de texto esperado para el segundo parámetro (el nombre de la función que
se está creando) y la presencia o ausencia de una devolución de llamada destructor para
el puntero de datos de aplicación.
El primer parámetro es la conexión de base de datos a la que la función de SQL se va a
añadir. Si una aplicación utiliza más de una conexión de base de datos a continuación,
las funciones SQL definidas por la aplicación se deben agregar a cada conexión de base de datos por separado.
El segundo parámetro es el nombre de la función SQL para crear o redefinir. La longitud
del nombre está limitada a 255 bytes en una representación UTF-8, con exclusión de la
cero-terminator. Tenga en cuenta que el límite de longitud de nombre está en UTF-8
bytes, no personajes ni UTF-16 bytes. Cualquier intento de crear una función con un
nombre más largo resultará en SQLITE_MISUSE se devuelve.
El tercer parámetro (nArg) es el número de argumentos que la función de SQL o
agregado toma. Si este parámetro es -1, entonces la función de SQL o agregados pueden
tomar cualquier número de argumentos entre 0 y el límite establecido
por sqlite3_limit ( SQLITE_LIMIT_FUNCTION_ARG ). Si el tercer parámetro es menor que
1 o mayor que 127, entonces el comportamiento no está definido.
El cuarto parámetro, eTextRep, especifica el texto que codifica esta función SQL prefiere
para sus parámetros.Cada implementación de la función SQL debe ser capaz de trabajar
con UTF-8, UTF-16LE, o UTF-16BE. Sin embargo, algunas implementaciones pueden ser
más eficientes con una codificación que otro. Una aplicación puede invocar
sqlite3_create_function () o sqlite3_create_function16 () múltiples veces con la misma
función pero con diferentes valores de eTextRep. Cuando hay varias implementaciones
de la misma función están disponibles, SQLite recogerá el que implica la menor cantidad
de conversión de datos. Si sólo hay una única aplicación que no importa lo que se utiliza
la codificación de texto, luego el cuarto argumento debe ser SQLITE_ANY .
Corp.
El quinto parámetro es un puntero arbitraria. La implementación de la función puede
tener acceso a este puntero usando sqlite3_user_data () .
El sexto, séptimo y octavo parámetros, xFunc, xstep y xfinal, son punteros a funciones
del lenguaje C que implementan la función de SQL o agregado. Una función escalar SQL
requiere una implementación de la devolución de llamada sólo xFunc; punteros NULL
deben pasar como el xstep y parámetros xfinal. Una función SQL agregada requiere una
implementación de xstep y xfinal puntero NULL y se debe pasar por xFunc. Para eliminar
una función o de agregado de SQL existente, pasar punteros NULL para las tres devoluciones de llamada de función.
Si el noveno parámetro sqlite3_create_function_v2 () no es NULL, entonces es destructor
para el puntero de datos de la aplicación. El destructor se invoca cuando se elimina la
función, ya sea por estar sobrecargado o cuando la conexión de base de datos se
cierra. El destructor se invoca también si la llamada a sqlite3_create_function_v2 ()
falla. Cuando se invoca la devolución de llamada destructor del parámetro décimo, se
pasa un único argumento que es una copia del puntero de datos de la aplicación, que fue el quinto parámetro para sqlite3_create_function_v2 ().
Está permitido registrar varias implementaciones de las mismas funciones con el mismo
nombre pero con diferentes números de cualquiera de los argumentos o diferentes
codificaciones de texto preferidos. SQLite utilizará la aplicación que más se acerque a la
forma en que se utiliza la función de SQL. La implementación de la función con un
parámetro nArg no negativo es una opción mejor que una implementación de la función
con un nArg negativo. Una función en la codificación de texto preferido coincide con la
codificación de la base de datos es una opción mejor que una función en la que la
codificación es diferente. Una función en la que la diferencia entre la codificación es
UTF16le y UTF16be es un partido más que una función donde la diferencia es de entre codificación UTF8 y UTF16.
Las funciones integradas se puede sobrecargar las nuevas funciones definidas por la
aplicación.
Una función definida por la aplicación se le permite llamar a otras interfaces SQLite. Sin
embargo, este tipo de llamadas no deben cerrar la conexión de base de datos ni finalizar o restablecer la declaración preparada en el que la función se está ejecutando.
Véase también la lista de objetos , constantes y funciones .
Corp.
Links comunes
Características Preguntas más frecuentes Usuarios conocidos Introducción SQL Sintaxis
o Pragma o Las funciones de SQL o Funciones de fecha y hora o Las funciones de agregado
C / C + + interfaz Spec o Introducción o Lista de lenguaje C API
El TCL Interface Spec Cronología del Desarrollo Informar de un error
http://www.sqlite.org/