Bienvenido.
SQLite es una biblioteca de software que implementa un autónomo , sin
servidor , sin configuración , transacci...
SQLite es autónomo
SQLite es en gran medida autónomo. Se requiere apoyo muy mínima de
bibliotecas externas o desde el sist...
árbol de código fuente y compilarlo junto con el resto del código. SQLite
no se vincula contra ninguna biblioteca externa ...
configuración. Nada de lo que hay que hacer para decirle al sistema que
se está ejecutando SQLite. No se requieren accione...
serializa escribe a almacenamiento masivo, y la escritura de un solo sector
tiene una cantidad limitada de tiempo. Por lo ...
para cambiar esto, pero el código no se había probado con un valor
mayor. El supuesto sector de 512 bytes parecía razonabl...
predeterminado para Unix y Windows no indica sector atómico escribe y lo
que estas optimizaciones se suele omitir.
SQLite ...
de archivos en absoluto. Si después de la conexión se restaura el archivo
sólo se elimina parcialmente, si algunos de los ...
la figura de la extrema derecha (con la etiqueta "Disco") representa la
información almacenada en el dispositivo
de
almace...
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 de...
puede haber un único bloqueo reservada en el archivo de base de
datos. Por lo tanto sólo un único proceso puede ser intent...
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 ...
el almacenamiento no volátil es normalmente una operación lenta.
Este paso es generalmente más complicado que simplemente ...
ciclo al permitir bloqueos compartidos existentes para proceder, pero el
bloqueo de nuevos bloqueos compartidos de ser est...
sección 3.7 anterior tienen en la mayor parte del tiempo requerido para
completar una transacción cometen en SQLite.

3.11...
diario a cero bytes de longitud o sobrescribir la cabecera del fichero de
diario con ceros. En cualquiera de los casos, el...
4.0 Rollback
Una
confirmación
atómica
se
supone
que
debe
ocurrir
instantáneamente. Sin embargo, el procesamiento descrito ...
La primera vez que un proceso de
SQLite intenta acceder al archivo de
base de datos, se obtiene un
bloqueo
compartido
como...
un bloqueo exclusivo en el archivo de base de datos. Esto evita que dos o
más procesos de intentar deshacer la misma revis...
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 sobr...
muestra un escenario en tres archivos de bases de datos diferentes se han
modificado dentro de una transacción. La situaci...
hexadecimal
de
32
bits
al
azar. Los
cambios
aleatorios HHHHHHHH para cada nueva publicación principal.

sufijos

(Nota ben...
maestro está escrito en la cabecera del diario de reversión. Es importante
hacer estas dos oleadas. Afortunadamente, el se...
reinicia el sistema, aunque hay retrotracción revistas presentan. La
diferencia es la ruta principal diario en la cabecera...
SQLite versión 3.3.14, es posible para SQLite de usar dispositivos de
almacenamiento masivo con un tamaño de sector mayor ...
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...
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...
comenzaría por releer los datos que previamente había sido leídos. Esto
no es tan malo como parece al principio, ya que lo...
borrar la caché de espacio de usuario en el inicio de una
transacción.
3. Cada transacción puede ser cometido por sobrescr...
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...
para la revista rollback) que el tamaño del archivo se aumenta primero y
que el contenido se escriben segundos. Así que si...
estableciendo
el
modo
de
diario
el journal_mode PRAGMA. Por ejemplo:
Journal_mode PRAGMA = persistir;

"PERSIST"

utilizan...
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 l...
9.1 Implementaciones bloqueo rotos
SQLite utiliza bloqueos de sistema de archivos para asegurarse de que
sólo un proceso d...
sistemas de archivos, se nos dice. Incluso en sistemas donde
FlushFileBuffers fsync () y () se dice que están trabajando, ...
abrió. Si bien el archivo de base de datos original y la revista caliente se
han movido o cambiado de nombre, entonces la ...
lógica confirmación atómica de SQLite es totalmente libre de errores. Los
desarrolladores se han comprometido a la fijació...
base de datos en absoluto. Y muchas instalaciones de SQL bases de datos
grandes no tienen nada que ver con los sitios web....
SQLite autor
Todo el código y la documentación de
SQLite se ha dedicado al dominio público por
los autores. Todos los auto...
A pesar de que SQLite es de dominio público y no requiere de una licencia,
algunos usuarios quieren obtener una licencia d...
Charlotte, NC 28269
EE.UU.
Un comunicado de copyright plantilla está disponible en formato
PDF o HTML . Puede utilizar est...
invocaciones de funciones dentro de la misma sqlite3_step
() llamada.
Agregue la extensión "totype.c", la aplicación de la...
Funciones básicas
Las funciones básicas que se muestran a continuación están disponibles de forma
predeterminada. Fecha y ...
función de una implementación
continuación,
laGLOB operador
aplicación alternativa.

alternativa a
invocar
la

IFNULL (X, ...
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...
load_extension (X, Y)

compartida llamada X utilizando el punto de
entrada Y. El resultado de load_extension () es
siempre...
izquierda a derecha de un argumento que define
una función de clasificación y utiliza esa función
colateral para todas las...
por lo tanto la cadena devuelta literal se truncan
antes de la primera NUL.

aleatorio ()

La función random () devuelve u...
Base de Datos Relacional
Base de Datos Relacional
Base de Datos Relacional
Base de Datos Relacional
Base de Datos Relacional
Base de Datos Relacional
Base de Datos Relacional
Base de Datos Relacional
Base de Datos Relacional
Base de Datos Relacional
Upcoming SlideShare
Loading in...5
×

Base de Datos Relacional

339

Published on

SQLite es un sistema de gestión de bases de datos relacional compatible con ACID, contenida en una relativamente pequeña (~275 kiB)2 biblioteca escrita en C. SQLite es un proyecto de dominio público1 creado por D. Richard Hipp.
A diferencia de los sistema de gestión de bases de datos cliente-servidor, el motor de SQLite no es un proceso independiente con el que el programa principal se comunica. En lugar de eso, la biblioteca SQLite se enlaza con el programa pasando a ser parte integral del mismo. El programa utiliza la funcionalidad de SQLite a través de llamadas simples a subrutinas y funciones. Esto reduce la latencia en el acceso a la base de datos, debido a que las llamadas a funciones son más eficientes que la comunicación entre procesos. El conjunto de la base de datos (definiciones, tablas, índices, y los propios datos), son guardados como un sólo fichero estándar en la máquina host. Este diseño simple se logra bloqueando todo el fichero de base de datos al principio de cada transacción

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
339
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Base de Datos Relacional

  1. 1. Bienvenido. SQLite es una biblioteca de software que implementa un autónomo , sin servidor , sin configuración , transaccional motor de base de datos SQL. SQLite es el mayor despliegue de motor de base de datos SQL en el mundo. El código fuente de SQLite está en el dominio público . Patrocinadores El desarrollo continúo y el mantenimiento de SQLite es patrocinado en parte por el Consorcio SQLite miembros, entre ellos: Bentley - Comprehensive software solutions for Sustaining Infrastructure. Mozilla - Working to preserve choice and innovation on the internet. Nokia is the world leader in mobility, driving the transformation and growth of the converging internet and communications industries. Oracle - Software. Hardware. Complete. Adobe revolutionizes how the world engages with ideas and information - anywhere, anytime, and through any medium. Bloomberg - A world leader in information technology. financial- Corp.
  2. 2. 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.
  3. 3. á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.
  4. 4. 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.
  5. 5. 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.
  6. 6. 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.
  7. 7. 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.
  8. 8. 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.
  9. 9. 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.
  10. 10. 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.
  11. 11. 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.
  12. 12. 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.
  13. 13. 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.
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17. 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.
  18. 18. 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.
  19. 19. 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.
  20. 20. 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.
  21. 21. 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.
  22. 22. hexadecimal de 32 bits al azar. Los cambios aleatorios HHHHHHHH para cada nueva publicación principal. sufijos (Nota bene:.. La fórmula para el cálculo de la revista master nombre de archivo indicado en el párrafo anterior se corresponde con la ejecución al SQLite versión 3.5.0 Pero esta fórmula no es parte de la especificación de SQLite y está sujeto a cambios en versiones futuras) A diferencia de las revistas de reversión, el diario principal no contiene ningún contenido de la página base de datos original. En cambio, el diario principal contiene la ruta completa de las revistas de reversión para cada base de datos que participa en la transacción. Después de la publicación principal está construido, su contenido se vacía en el disco antes de tomar cualquier otra acción. En Unix, el directorio que contiene la revista principal también se sincroniza con el fin de asegurarse de que el archivo de diario principal aparecerá en el directorio raíz de una falla de energía. 5.3 Actualización de Rollback Journal Cabeceras El siguiente paso es registrar la ruta completa del archivo principal revista en la cabecera de todas las revistas de reversión. Espacio para mantener la revista del archivo maestro se reservó al principio de cada revista rollback como se crearon las revistas rollback. El contenido de cada revista reversión se vacía en el disco, tanto antes como después de la revista nombre del archivo Corp.
  23. 23. 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.
  24. 24. 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.
  25. 25. 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.
  26. 26. 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.
  27. 27. 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.
  28. 28. 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.
  29. 29. 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.
  30. 30. 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.
  31. 31. 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.
  32. 32. estableciendo el modo de diario el journal_mode PRAGMA. Por ejemplo: Journal_mode PRAGMA = persistir; "PERSIST" utilizando El uso del modo de diario persistente proporcionar una mejora notable en el rendimiento de muchos sistemas. Por supuesto, el inconveniente es que los ficheros de diario permanecen en el disco, el uso de espacio de disco y que saturan directorios, mucho después de que se confirme la transacción. La única forma segura de eliminar un archivo de diario persistente es cometer una transacción con el modo SET para borrar el diario: PRAGMA journal_mode = BORRAR; INICIAR EXCLUSIVA; COMMIT; Tenga cuidado de borrar archivos de diario persistentes por cualquier otro medio desde el archivo de diario puede estar caliente, en cuyo caso eliminarlo dañará el archivo de base de datos correspondiente. A partir de SQLite versión 3.6.4, el modo de diario TRUNCATE también es compatible: PRAGMA journal_mode = TRUNCATE; En el modo de diario truncado, la transacción se confirma al truncar el archivo de diario de longitud cero en lugar de eliminar el archivo de diario (como en el modo DELETE) o mediante la reducción a cero de la cabecera (como en el modo PERSISTE). TRUNCATE acciones modo la ventaja de PERSIST modo que no es necesario en el directorio que contiene el archivo de diario y la base de datos para actualizar. Por lo tanto truncar un archivo es a menudo más rápido que eliminarlo. TRUNCATE tiene la ventaja adicional de que no es seguido por una llamada al sistema (por ejemplo: fsync ()) para sincronizar el cambio en el disco. Podría ser más seguro si lo hizo. Pero en muchos sistemas de ficheros modernos, un truncado es una operación atómica y sincrónica y por lo que considera que TRUNCATE por lo general será seguro en la cara de fallos de alimentación. Si no está seguro acerca de si o no TRUNCATE será sincrónica y atómica en su sistema de ficheros, y es importante para usted que su base de datos de sobrevivir a un corte de energía o fallo del sistema operativo que se produce durante la operación de truncamiento, entonces usted podría considerar el uso de un modo de diario diferentes. En los sistemas integrados con sistemas de archivos sincronizados, TRUNCATE como resultado un comportamiento más lento que persisten. La operación de confirmación es la misma velocidad. Pero las transacciones posteriores son más lentos después de un TRUNCATE porque es más rápido para sobrescribir el contenido existente que desea Corp.
  33. 33. 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.
  34. 34. 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.
  35. 35. 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.
  36. 36. 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.
  37. 37. 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.
  38. 38. 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.
  39. 39. SQLite autor Todo el código y la documentación de SQLite se ha dedicado al dominio público por los autores. Todos los autores de código, y representantes de las empresas para las que trabajan, han firmado declaraciones juradas dedicando sus contribuciones al dominio público y los originales de esas declaraciones juradas firmadas se almacenan en una prueba de fuego en la sede de Hwaci . Cualquiera es libre de SQLite es en el copiar, modificar, publicar, usar, recopilar, Dominio Público vender o distribuir el código original SQLite, ya sea en forma de código fuente o binario compilado, para cualquier propósito, comercial o no comercial, y por cualquier medio. El párrafo anterior se aplica al código de entrega y documentación en SQLite - las partes de la biblioteca de SQLite que realmente paquete y envía con una aplicación más amplia. Algunas secuencias de comandos utilizadas como parte del proceso de construcción (por ejemplo, las secuencias de comandos "configure" generados por autoconf) podrían caer bajo otras licencias de código abierto. Nada de estos scripts de construcción nunca llega a la biblioteca SQLite última entrega, sin embargo, por lo que las licencias asociadas con estos scripts no deben ser un factor en la evaluación de sus derechos a copiar y utilizar la biblioteca SQLite. Todo el código entregable en SQLite se ha escrito desde cero. Ningún código se ha tomado de otros proyectos o de la Internet abierta. Cada línea de código se puede remontar de nuevo a su autor original, y todos los autores tienen dedicatorias de dominio público en el archivo. Así que la base de código SQLite está limpio y no está contaminada con el código de licencia de otros proyectos. La obtención de una Licencia explícito para usar SQLite Corp.
  40. 40. 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.
  41. 41. 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.
  42. 42. 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.
  43. 43. 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.
  44. 44. función de una implementación continuación, laGLOB operador aplicación alternativa. alternativa a invocar la IFNULL (X, Y) El IFNULL () devuelve una copia de su primer argumento que no es NULL, o NULL si ambos argumentos son NULL. IFNULL () debe tener exactamente 2 argumentos. La función IFNULL () es equivalente a coalescer () con dos argumentos. instr (X, Y) El instr (X, Y) función busca la primera aparición de cadena en cadena Y X y devuelve el número de caracteres anterior más 1 o 0 si Y se encuentra en ninguna parte dentro de X. O bien, si X e Y son ambos BLOB, entonces instr (X, Y) devuelve uno más que el número de bytes de antes de la primera ocurrencia de Y, o 0 si Y no se produce en cualquier lugar dentro de X. Si ambos argumentos X e Y en Instrumento (X, Y) son no NULL y son no BLOB luego ambos se interpretan como cadenas. Si X o Y son NULL en instr (X, Y), entonces el resultado es NULL. hex (X) El hex () función interpreta su argumento como un BLOB y devuelve una cadena que es la representación hexadecimal en mayúsculas del contenido de esa nota. last_insert_rowid () El last_insert_rowid () devuelve el ROWID de la última fila de inserción de la conexión de base de datos que se invoca la función. El last_insert_rowid () de SQL es una envoltura alrededor de la sqlite3_last_insert_rowid () función de interfaz C / C + +. longitud (X) Para un valor de serie X, la longitud (X) devuelve el número de caracteres (no bytes) en X antes del primer carácter NUL. Desde cadenas SQLite normalmente no contienen caracteres NUL, la longitud (X) la función normalmente devolverá el Corp.
  45. 45. número total de caracteres en la cadena de X. Para un valor blob X, la longitud (X) devuelve el número de bytes en el blob. Si X es NULL entonces la longitud (X) es NULL. Si X es numérico a continuación, la longitud (X) devuelve la longitud de una representación de cadena de X. como (X, como (X, Y, Z) Y) El gusto () se utiliza para poner en práctica la "Y COMO X [ESCAPE Z]" expresión.Si la cláusula ESCAPE opcional está presente, entonces el estilo () se invoca con tres argumentos. De lo contrario, se invoca con sólo dos argumentos. Tenga en cuenta que los parámetros X e Y se invierten en la función como () en relación con el infijo LIKE operador. El sqlite3_create_function () interfaz puede utilizarse para anular el estilo () y por lo tanto cambiar el funcionamiento del LIKE operador. Al reemplazar la función como (), puede ser importante para reemplazar ambos dos y tres versiones de argumentos de la función como (). De lo contrario, el código diferente puede ser llamado para implementar el LIKE operador en función de si o no se ha especificado una cláusula de escape. probabilidad (X, Y) La probabilidad (X, Y) devuelve argumento X sin cambios. El valor de Y en la probabilidad (X, Y) debe ser una constante de coma flotante entre 0.0 y 1.0, inclusive. La probabilidad (X) es una función no-op que el generador de código de distancia optimiza para que no consume ciclos de la CPU durante el tiempo de ejecución (es decir, durante las llamadas a sqlite3_step () ). El propósito de la función de probabilidad (X, Y) es proporcionar una pista para el planificador de consulta que el argumento X es un valor booleano que es cierto con una probabilidad de aproximadamente Y. El poco probable (X) es la función de corto mano para la probabilidad ( X, 0,0625). load_extension (X) El load_extension (X, Y) función carga SQLite extensiones fuera del archivo de biblioteca Corp.
  46. 46. 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.
  47. 47. 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.
  48. 48. por lo tanto la cadena devuelta literal se truncan antes de la primera NUL. aleatorio () La función random () devuelve un entero pseudoaleatorio entre -9223372036854775808 y 9223372036854775807. randomblob (N) La función randomblob (N) devuelve un objeto binario de N bytes que contiene bytes pseudoaleatorios. Si N es menor que 1, entonces se devuelve una mancha aleatoria de 1 byte. Sugerencia: las aplicaciones pueden generar identificadores únicos globales utilizando esta función junto con hex () y / o inferior () así: hex (randomblob (16)) bajar (hex (randomblob (16))) replace (X, Y, Z) El reemplazo (X, Y, Z) función devuelve una cadena formada mediante la sustitución de cadena Z para cada ocurrencia de cadena de Y en la cadena de X. ElBINARIO secuencia de clasificación se utiliza para las comparaciones. Si Y es una cadena vacía luego regresar X sin cambios. Si Z no es inicialmente una cadena, se convierte en una cadena antes de su procesamiento UTF-8. round (X) round (X, Y) La ronda (X, Y) devuelve un valor de punto flotante de X redondeado a un dígito Y a la derecha del punto decimal. Si se omite el argumento Y, que se supone que es 0. rtrim (X) rtrim (X, Y) El rtrim (X, Y) función devuelve una cadena formada mediante la eliminación de cualquier y todos los caracteres que aparecen en Y desde el lado derecho de X. Si se omite el argumento Y, rtrim (X) elimina los espacios desde el lado derecho de X. Corp.

×