数据库损坏的可能原因

数据库损坏的可能原因

1. 数据库文件被其他线程覆盖或删除

  1. 在文件描述符关掉以后,继续使用这个文件描述符访问
    1. 打开文件,获取文件描述符fd(其实是一个整形)
    2. 关闭文件
    3. 打开sqlite文件,获取文件描述符(碰巧也是)fd
    4. 另一个线程继续使用fd,写文件
    5. sqlite文件被损坏
  2. 在事务进行过程中,进行数据库备份或恢复
    在数据库事务过程中,数据库文件既包括老的内容,也包括新的内容。如果此时拷贝这个文件,数据库可能会被损坏。 备份数据库最好使用sqlite的api
  3. 删除日志文件
    日志文件中包括rollback需要的信息。删除以后,无法正确回滚,有可能会导致数据库损坏。

2. 文件锁相关

sqlite使用文件锁来在保证多线程访问。如果文件锁机制不正常,会导致同时读写文件等信息,导致数据库损坏

  1. 文件系统没有正确的实现文件锁的机制
    在网络操作系统中,比较常见
  2. 不正确使用close()函数
    在Unix中,close()函数会解除所有线程的文件锁。
    例如A、B线程打开了数据库文件,使用sqlite的api。此时,线程C依次调用了open(),read()以及close()。此时,这个文件的所有锁已经没了。因此A、B有可能会同时写数据到文件中。
  3. 两个进程使用不同的锁协议(locking protocols)
    默认使用POSIX advisory locking,可以用sqlite3_open_v2()函数修改。如果不一致,可能发生同时读写,数据库损坏。
  4. 在数据库文件使用时rename或unlink
    两个进程A、B,同时对一个数据库文件建立数据库连接。A关闭连接,unlink文件,用同样的名字创建一个新的数据库文件,在打开这个数据库。这样子A、B两个进程在使用不同的数据库,名字却是一样的。 然而,日志文件是根据数据库名字来区分数据库文件的。因此这两个进程的数据库文件会是同一个。导致数据库文件损坏。
  5. 一个文件有多个连接
    也就是说一个数据库文件有多个名字。假如A、B使用不同的名字打开同一个数据库链接,会有两个日志文件。 如果线程A crash了,B检测到需要进行rollback。找不到日志文件,无法回滚。

3. sync失败

为了保证数据库文件的一致性(consistent),会调用fsync()系统调用,把内存中的数据刷到磁盘中。如果这个sync操作失败,会导致数据库文件损坏

  1. sync系统调用和文档描述不一致
    USB闪存经常这样子。例如写大数据时,在函数返回已写入成功时,USB的指示灯还在亮着。
  2. 使用PRAGMAs禁用sync
    synchronous=OFF可以提高速度,却会导致文件不一致。

4. 硬盘、闪存损坏

5. 内存损坏

当野指针、内存溢出等原因,可能导致内存中的数据库结构损坏,从而有可能导致数据库文件损坏。
当进行memory-mapped I/O时,由于内存直接映射到磁盘,如果发生数组越界等,内存中的数据损坏,磁盘文件也会损坏

6. 其他操作系统问题

  1. 文件系统崩溃 ##7.sqlite的bug

posted on 2016-10-12 23:46  花老????  阅读(3658)  评论(0)  编辑  收藏

上一篇:在不root手机的情况上读取Data目录上的文件


下一篇:【Android】编写Drawable XML绘制底部带指示条的背景