昨天下午生产系统突然无法保存销售提单了，而且是全面爆发，所有用户都无法保存销售类单据了。事情比较紧急，所以公司的运维部门的电话很快就被打爆了。
我们马上检查了数据库服务器和应用服务器的网络状况及内存，cpu使用状况等等，发现这些都正常，于是我们又检查了数据库的文件大小及磁盘空间是否够用，日志
文件增长情况等等，也毫无头绪。
         在这个时候我们想起在前几天从线上取了一个完整备份库恢复到了测试服务器上，并搭建了一个测试环境，测试时发现库存单据也无法进行保存。当时由于测试服
务器空间有限，急需将测试库的数据清理一部分，所以我们就将所有数据量比较大的表列出来了，并首先将库存单据明细表和主表给清除了一部分数据，然后测试系统
中的库存单据又可以保存了。
         于是我们初步断定应该和数据库文件的空间大小有关系，经过查看系统日志发现日志果然存在错误信息，数据库日志自动增长时，分配日志空间失败。我们现在的
日志文件已经有80G了，数据库日志文件增长为每次增长10%，并且不限制大小。于是我们的DBA尝试将按照比例增长改为每次固定增长512MB，结果这次系统分配日志
文件空间就可以成功了。
         这样销售单据也可以重新保存，所以业务操作都ok了。可是为什么按照比例增长日志空间就会失败，而按照固定的大小增长就没有问题呢，我们排除了磁盘坏道，
空间不足，网络传输失败，IO瓶颈等等原因，一直无法给出合理的解答。求助基础架构的同事也没有结果，百度和google也没有找到合理的解释。
         但是由于日志文件自动增长分配空间失败引起的后果的确是非常的严重，让我们切实感受到了数据库维护的重要性。
 

--内存大小，cpu速度，磁盘速度，磁盘大小这四个因素哪个对数据库系统来说最重要？也就是说哪个因素是数据库性能的瓶颈？
其实是磁盘速度。数据库的作用就是把磁盘中东西读到内存中然后处理完毕后提交上去，操作系统能管理的内存也就是几GB，但是超过最大内存容量的数据库很普遍，所以瓶颈还是在磁盘上面。
sqlserver数据库存放数据用的是页，每8个连续的页叫做一个盘区，每页有若干个数据行。sqlserver每次读8页，这样减少了读盘的次数，读上来后放入内存缓存，sqlserver中一个页是8kb，页与页之间形成一个双向链表，首尾相连。
--数据库系统日志作用：怎样恢复数据的？里面都记录了些什么东西？
记录数据操作和被操作的数据，一般来说数据文件大于日志文件，插入或是删除操作时，日志中不但要记录操作还要记录数据，如果专门是插入的话，而且如果更新的次数太多的话，那么数据文件不会怎么改变，但是日志文件会越来越大，sqlserver采用归档模式，用5个日志文件来记录，如果5个都记录满了的话，就开始覆盖第一个日志文件，继续覆盖的方法重新存储这5个日志。
修改数据库时候，客户端发送一个update命令，数据库服务器收到update请求，数据库引擎首先会把表里面的数据先按照8页一个盘区的方式读到缓存里面，读入缓冲区后，就要在硬盘的日志文件中记录数据修改的操作过程以及原始参数，然后根据客户端的要求修改缓冲区中的数据，最后检查点程序向数据库中写入已经提交的事务（一次或者多次数据的修改，也就是批处理数据的修改，这样减少写盘的次数，提高效率）。如果内存里面的数据经过了修改，但是没有写入磁盘，也就是没有和磁盘里面的数据同步，这就是脏数据了。
当你的数据在内存当中但是还没有写入硬盘的数据库中的时候，突然断电了，假如这时候有个银行帐户的转帐，如果发生这种事情的话，银行系统一般如何处理这种情况呢？以前是通过填写单子的方式来保证避免这种问题，现在都是通过日志来保证的，因为先是写入日志，然后才在内存中修改数据，日志中有个叫做检查点的东西，这个checkpoint后面的数据为脏数据块，证明没有写入硬盘，下一次启动系统后，会检查日志中的脏数据块记录，然后把他们再重新作一遍。
Oracle中用的是还原模式，不是归档模式，如果执行delete from删除的话，如果是完全还原模式的话，删除的所有数据都必须记录日志，sqlserver中全表的删除是不写日志的，这是简单的还原模式，无法还原了。



转自：http://hi.baidu.com/zhangxuan1224/blog/item/e812e2f2ac96ef1bb07ec585.html

要了解数据库的日志系统首先得知道其存在的必要性：
数据库事务的ACID中的Durability-持久性就是依靠日志系统来实现的
日志模块：redo-log(InnoDB特有)
当数据库引擎InnoDB从服务层接收到一条更新语句，InnoDB 引擎就会先把记录写到 redo log中并更新到内存中(效率非常高)，并在空闲的时候将数据写入到磁盘中(此时才是实际更新)
值得注意的是 InnoDB 的 redo-log 记录的数据有限，当超过大小之后会先等日志写入到磁盘释放出一部分空间后才能继续写入到redo-log日志文件中
虽然redo-log 记录的数据有限但依旧可以保留大量数据，当数据库发生异常重启时，依旧可以通过redo-log恢复数据而不用担心数据写入磁盘过程中发生异常而产生的数据丢失
日志模块：bin-log(存在于server层 MySQL自带)
最开始 MySQL 里并没有 InnoDB 引擎。MySQL自带的引擎是 MyISAM。
bin-log是记录着mysql所有事件的操作，可以通过bin-log做完整恢复，因此当你不小心删库了也可以通过bin-log日志系统恢复数据，可以基于时间点恢复也可以基于位置恢复。你也可以利用二进制日期进行远程复制，通过主机上的二进制日志文件，将数据更改同步到备机。
值得注意的是 MyISAM 的bin-log日志系统并没有 crash-safe 能力，这也是 InnoDB 引入redo-log日志系统的原因。
bin-log日志文件没有大小限制，是可以线性增长的。当一个文件满了，会重新创建一个日志文件。一般情况下我们安装mysql之后binary log二进制日志并没有开启，需要我们自行开启。 (具体开启语句以及恢复数据语句可以自行百度查到)
日志的两阶段提交
上面我们讲了数据库存在的两种日志而其中一种日志不具有crash-safe 能力，那么问题来了：当发生数据库异常重启时，redo-log记录的数据比bin-log记录的数据多怎么办？
为了保证日志一致性需要引入事务控制，即日志的两阶段提交
可以看到 在最后三步 写入redo-log先prepare，然后写bin-log，最后提交事务。
当然MySQL还有很多其他的日志，这里只讲解了常用的两种，其余日志可以自行查阅学习

数据库日志

[root@rac1 ~]# find /u01/app/ -name alert*.log
节点的

/u01/app/11.2.0/grid/log/rac1/alertrac1.log
升级的

/u01/app/oracle/product/11.2.0/db_1/log/diag/rdbms/dbua0/DBUA0/trace/alert_DBUA0.log
数据库的

/u01/app/oracle/diag/rdbms/racdb/racdb1/trace/alert_racdb1.log
asm的

/u01/app/grid/diag/asm/+asm/+ASM1/trace/alert_+ASM1.log
oracle 下的alert日志

$ORACLE_BASE/diag/rdbms/orcl/orcl1/trace/alertorcl1.log
grid 下的 alert 日志

$ORACLE_HOME/log/rac1/alertrac1.log
css的日志

$ORACLE_HOME/log/rac1/cssd/cssd.log ocssd.log
crs的日志

$ORACLE_HOME/log/rac1/crsd/crsd.log
ohas的日志

$ORACLE_HOME/log/rac1/ohasd/ohasd.log
evm的日志

$ORACLE_HOME/log/rac1/evmd/evmd.log
系统日志

日志文件的默认路径是：/var/log

下面是几个重要的日志文件的路径及其包含的信息：
/var/log/syslog：它和/etc/log/messages日志文件不同，它只记录警告信息，常常是系统出问题的信息。

/var/log/messages：包括整体系统信息，其中也包含系统启动期间的日志。此外，还包括mail，cron，daemon，kern和auth等内容。
/var/log/user.log：记录所有等级用户信息的日志。
/var/log/auth.log：包含系统授权信息，包括用户登录和使用的权限机制等。
/var/log/daemon.log：包含各种系统后台守护进程日志信息。
/var/log/kern.log：包含内核产生的日志，有助于在定制内核时解决问题。