日志文件

ORA-00001: 违反唯一约束条件 (.) ORA-00017: 请求会话以设置跟踪事件 ORA-00018: 超出最大会话数 ORA-00019: 超出最大会话许可数 ORA-00020: 超出最大进程数 () ORA-00021: 会话附属于其它某些进程；无法转换会话 ORA-00022: 无效的会话 ID；访问被拒绝 ORA-00023: 会话引用进程私用内存；无法分离会话 ORA-00024: 单一进程模式下不允许从多个进程注册 ORA-00025: 无法分配 ORA-00026: 丢失或无效的会话 ID ORA-00027: 无法删去当前会话 ORA-00028: 您的会话己被删去 ORA-00029: 会话不是用户会话 ORA-00030: 用户会话 ID 不存在。 ORA-00031: 标记要删去的会话 ORA-00032: 无效的会话移植口令 ORA-00033: 当前的会话具有空的移植口令 ORA-00034: 无法在当前 PL/SQL 会话中 ORA-00035: LICENSE_MAX_USERS 不能小于当前用户数 ORA-00036: 超过递归 SQL () 级的最大值 ORA-00037: 无法转换到属于不同服务器组的会话 ORA-00038: 无法创建会话: 服务器组属于其它用户 ORA-00050: 获取入队时操作系统出错 ORA-00051:

MySQL中的 redo 日志文件 MySQL中有三种日志文件，redo log、bin log、undo log。redo log 是 存储引擎层(innodb)生成的日志，主要为了保证数据的可靠性；bin log 是 MySQL 数据库层面上生成的日志，主要用于 point in time 恢复和主从复制。undo log 主要用于事务的回滚(undo log 记录的是每个修改操作的逆操作) 和 一致性非锁定读(undo log 回滚行记录到某种特定的版本---MVCC 多版本并发控制)。 redo log 和 undo log 都是存储引擎层面上生成的日志，并且都记录了数据的修改：只不过 redo log记录的是"物理级别"上的页修改操作，比如页号xxx、偏移量yyy写入了'zzz'数据；而undo log 记录的是逻辑操作日志，比如对某一行数据进行了INSERT语句操作，那么 undo log就记录一条与之相反的DELETE操作。 redo log 作用 MySQL作为一个存储系统，为了保证数据的可靠性，最终得落盘。但是，又为了数据写入的速度，需要引入基于内存的"缓冲池"。其实不止MySQL，这种引入缓冲来解决速度问题的思想无处不在。既然数据是先缓存在缓冲池中，然后再以某种方式刷新到磁盘，那么就存在因宕机导致的缓冲池中的数据丢失，为了解决这种情况下的数据丢失问题

在 Linux 系统上管理日志文件可能非常容易，也可能非常痛苦。这完全取决于你所认为的日志管理是什么。 如果你认为是如何确保日志文件不会耗尽你的 Linux 服务器上的所有磁盘空间，那么这个问题通常很简单。Linux 系统上的日志文件会自动翻转，系统将只维护固定数量的翻转日志。即便如此，一眼看去一组上百个文件可能会让人不知所措。在这篇文章中，我们将看看日志轮换是如何工作的，以及一些最相关的日志文件。 自动日志轮换 日志文件是经常轮转的。当前的日志会获得稍微不同的文件名，并建立一个新的日志文件。以系统日志文件为例。对于许多正常的系统 messages 文件来说，这个文件是一个包罗万象的东西。如果你 cd 转到 /var/log 并查看一下，你可能会看到一系列系统日志文件，如下所示: $ ls -l syslog* -rw-r----- 1 syslog adm 28996 Jul 30 07:40 syslog -rw-r----- 1 syslog adm 71212 Jul 30 00:00 syslog.1 -rw-r----- 1 syslog adm 5449 Jul 29 00:00 syslog.2.gz -rw-r----- 1 syslog adm 6152 Jul 28 00:00 syslog.3.gz -rw-r----- 1 syslog adm 7031

简介 SQL Server中的事务日志无疑是SQL Server中最重要的部分之一。因为SQL SERVER利用事务日志来确保持久性(Durability)和事务回滚(Rollback)。从而还部分确保了事务的 ACID 属性.在SQL Server崩溃时，DBA还可以通过事务日志将数据恢复到指定的时间点。当SQL Server运转良好时，多了解一些事务日志的原理和概念显得并不是那么重要。但是，一旦SQL SERVER发生崩溃时，了解事务日志的原理和概念对于快速做出正确的决策来恢复数据显得尤为重要.本系列文章将会从事务日志的概念，原理，SQL Server如何使用日志来确保持久性属性等方面来谈SQL Server的事务日志. 事务日志的物理组织构架 事务日志仅仅是记录与其对应数据库上的事务行为和对数据库修改的日志文件.在你新建数据库时，伴随着数据库文件，会有一个默认以ldf为扩展名的事务日志文件. 当然，一个数据库也可以配有多个日志文件，但是在逻辑上，他们可以看成一个. 在SQL Server对于日志文件的管理，是将逻辑上一个ldf文件划分成多个逻辑上的虚拟日志文件(virtual log files,简称VLFs).以便于管理。用个类比方法来看，日志文件(ldf)好比一趟火车，每一节车厢都是一个虚拟日志文件(VLFs): 那为什么SQL

log4j.logger.stdout=debug #灵活设置日志格式 log4j.appender.stdout.layout=org.apache.log4j.PatternLayout #文件 log4j.appender.stdout=org.apache.log4j.FileAppender #控制台 log4j.appender.stdout=org.apache.log4j.ConsoleAppender #打印信息的具体格式 log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS} %c %M%n%p: %m%n #　文件大小到达指定size时产生一个新的文件log4j.appender.stdout=org.apache.log4j.RollingFileAppender#每天产生一个日志文件log4j.appender.stdout=org.apache.log4j.DailyRollingFileAppender#studo日志文件在xx/xx/目录下创建log4j.appender.studo.File=${webApp.root}/WEB-INF/logs/stdout.log log4j.appender.stdout.DatePattern ='_'yyyy

一、RDB的优缺点 1.1、RDB的优点 （1）RDB文件是紧凑的二进制文件，比较适合做冷备，全量复制的场景。 RDB做会生成多个文件，每个文件都代表了某一个时刻的Redis完整的数据快照; RDB这种多个数据文件的方式，非常适合做冷备，因为大量的一个个的文件，可以每隔一定的时间，复制出来； 可以将这种完整的数据文件发送到一些远程的云服务、分布式存储上进行安全的存储，以预定好的备份策略来定期备份Redis中的数据； AOF也可以做冷备，只有一个文件，但是你可以写个脚本，每隔一定时间，去copy一份这个文件出来，相对比较麻烦，不推荐; 问题：RDB做冷备，优势在哪儿呢？ 由Redis去控制固定时长生成快照文件的事情，比较方便; AOF，还需要自己写一些脚本去做这个事情，各种定时; RDB数据做冷备，在最坏的情况下，提供数据恢复的时候，速度比AOF快; （2）相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复Redis进程，更加快速； 问题：为什么恢复的时候RDB比AOF快？ AOF，存放的指令日志，做数据恢复的时候，其实是要回放和执行所有的指令日志，来恢复出来内存中的所有数据的； RDB，就是一份数据文件，恢复的时候，直接加载到内存中即可； RDB的时候，Redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可； （3

一、redis持久化的意义 redis持久化的意义，在于故障恢复 比如你部署了一个redis，作为cache缓存，当然也可以保存一些较为重要的数据 如果没有持久化的话，redis遇到灾难性故障的时候，就会丢失所有的数据 如果通过持久化将数据搞一份儿在磁盘上去，然后定期比如说同步和备份到一些云存储服务上去，那么就可以保证数据不丢失全部，还是可以恢复一部分数据回来的 二、为什么要持久化 我们已经知道对于一个企业级的redis架构来说，持久化是不可减少的 企业级redis集群架构：海量数据、高并发、高可用 持久化主要是做灾难恢复，数据恢复，也可以归类到高可用的一个环节里面去 比如你redis整个挂了，然后redis就不可用了，你要做的事情是让redis变得可用，尽快变得可用 重启redis，尽快让它对外提供服务，但是就像上一讲说，如果你没做数据备份，这个时候redis启动了，也不可用啊，数据都没了 很可能说，大量的请求过来，缓存全部无法命中，在redis里根本找不到数据，这个时候就死定了，缓存雪崩问题，所有请求，没有在redis命中，就会去mysql数据库这种数据源头中去找，一下子mysql承接高并发，然后就挂了 mysql挂掉，你都没法去找数据恢复到redis里面去，redis的数据从哪儿来？从mysql来。。。 如果你把redis的持久化做好，备份和恢复方案做到企业级的程度

资料来源： https://www.centos.bz/2011/03/split-nginx-logfile-eveyday/ Nginx产生的日志都是存在一个文件，随着网站运行时间越长，日志文件的大小也在不断增长，这对我们想分析当天日志非常的不方便，所以需要每天把日志文件分割出来，并以时间命名。 创建日志分割脚本 1、登录SSH，创建cut_logs.sh文件 vi /root/cut_logs.sh 2、粘贴下面代码到cut_logs.sh，并保存 #!/bin/bash # The Nginx logs path logs_path="/home/wwwlogs/" mkdir -p ${logs_path}$(date -d "yesterday" +"%Y")/$(date -d "yesterday" +"%m")/ mv ${logs_path}www.juzihc.com.log ${logs_path}$(date -d "yesterday" +"%Y")/$(date -d "yesterday" +"%m")/juzihc_$(date -d "yesterday" +"%Y%m%d").log kill -USR1 $(cat /usr/local/nginx/logs/nginx.pid) 3、添加cut_logs.sh执行权限 chmod +x

RDB持久化 1：redis中RDB持久化方式也叫快照方式是redis的默认持久化方式，当符合一定条件时redis会对当前数据库中所有的数据生成一份快照文件并保存到磁盘中。 2：redis.conf中有两个参数dbfilename和dir分别指定了rdb文件的名称和保存路径。默认文件名dump.rdb是一个二进制文件，默认保存路径./当前目录。 3：redis启动时会在当前目录下加载dump.rdb文件，然后使用此文件恢复数据。这就是我们在不同目录下启动redis会发现数据丢失的原因。当然我们也可以更改dir的配置让它指定一个绝对目录。 4：RDB持久化触发条件和关闭 save 900 1 到900秒后发现至少一个key被修改 save 300 10 到900秒后发现至少10个key被修改 save 60 10000 到60秒后发现至少10000个key被修改 以上三个条件任意一个满足则启动持久化，另外我们也可以根据业务来自行设定持久化触发条件。 注释掉触发条件新增一个配置save “” 就会关闭RDB功能，但是如果在redis-cli中手动执行save或bgsave命令会生成dump.rdb文件执行持久化。 5：RDB原理 当开始持久化时redis会调用一个fork函数复制当前进程生成一个子进程，子进程就会将当前数据库中所有的数据写入一个临时文件，写完后替换dump.rdb文件

对日志文件中的error进行监控，当日志文件中出现error关键字时，就截取日志 （grep -i error 不区分大小写进行搜索"error"关键字，但是会将包含error大小写字符的单词搜索出来）, 大家可以去看这编 文章 1）第一类日志 在每天的日志目录下生产的error日志，此日志文件每天都会自动生成，里面有没有error日志内容不一定，日志内容写入不频繁，日志文件比较小。 举例说明： 采用sendemail发送告警邮件，sendemail安装参考：http: //www .cnblogs.com /kevingrace/p/5961861 .html 监控脚本路径： [root@fk-databus01 ~]# cd /opt/log_error_script/ [root@fk-databus01 log_error_script]# ll total 20 -rw-r--r-- 1 root root 3782 Jun 29 12:13 DEJ_0001_error.log -rwxr-xr-x 1 root root 4274 Jun 29 11:38 prcc_log_error.sh -rwxr-xr-x 1 root root 1142 Feb 13 10:51 sendemail.sh 监控脚本内容 [root@fk-databus01 log_error