日志文件

Oracle的存储结构分为：物理存储结构和逻辑存储结构。 一、物理存储结构：指硬盘上存在的文件 数据文件(data file) 一个数据库可以由多个数据文件组成的，数据文件是真正存放数据库数据的。一个数据文件就是一个操作系统文件。数据库的对象(表和索引)物理上是被存放在数据文件中的。当我们要查询一个表的数据的时候，如果该表的数据没有在内存中，那么oracle就要读取该表所在的数据文件，然后把数据存放到内存中。通过下面的语句可以查看当前存在的数据文件和对应的表空间： select file_name,tablespace_name from dba_data_files; 联机日志文件(online redo log file) 一个数据库可以有多个联机日志文件,联机日志文件包含了重做记录(undo records).联机日志文件记录了数据库的改变,例如当一次意外导致对数据的改变没有及时的写到数据文件中,那么oracle就会根据联机日志文件中 的信息获得这些改变,然后把这些改变写到数据文件中.这也是联机日志文件存在的意义.联机日志文件中重做记录的唯一功能就是用来做实例的恢复.比如,一次系统的意外掉电,导致内存中的数据没有被写到数据文件中.那么oralce就会根据联机日志文件中的重做记录功能包数据库恢复到失败前的状态。可以通过下面的语句查看当前存在的日志文件和对应的日志组信息：

版权声明：原创文章欢迎转载，不过要记得加出处哦 https://blog.csdn.net/wljk506/article/details/77146248 supervisord 是Linux/Unix系统下的一个进程管理工具 风.foxiswho 安装 yum install supervisor 设置开机启动 systemctl enable supervisord.service 配置文件 supervisord 的配置 文件是 /etc/supervisord.conf 自定义配置文件目录是 /etc/supervisord.d ,该目录下文件已 .ini 为后缀 supervisord 命令 启动 systemctl start supervisord.service 关闭 systemctl stop supervisord.service 重启 systemctl restart supervisord.service 配置进程 例如有个nginx 进程设置 vim /etc/supervisord.d/nginx.ini 内容如下 [program:nginx] ;directory = /www/lanmps/bin ; 程序的启动目录 command = /www/lanmps/bin/nginx start ; 启动命令

并发控制 锁粒度： 表级锁 行级锁 锁： 读锁：共享锁，只读不可写（包括 自己当前用户 和当前事务） ，多个读互不阻塞 写锁：独占锁，排它锁，写锁会阻塞其它事务（不包括当前事务）的读和它锁 实现 存储引擎：自行实现其锁策略和锁粒度 服务器级：实现了锁，表级锁，用户可显式请求 分类： 隐式锁：由存储引擎自动施加锁 显式锁：用户手动请求 锁策略：在锁粒度及数据安全性寻求的平衡机制 显式使用锁 LOCK TABLES 加锁 lock tables tbl_name [[AS] alias] lock_type [, tbl_name [[AS] alias] lock_type] ... lock_type: READ ,WRITE UNLOCK TABLES 解锁 FLUSH TABLES [tb_name[,...]] [WITH READ LOCK] 关闭所有正在打开的表，同时清除掉查询缓存以及准备好的语句缓存， 如果加上with read lock 选项的话，它代表关闭所有正在打开的表并加上全局锁（不清除缓存了）， 通常在备份前加全局读锁 SELECT clause [FOR UPDATE | LOCK IN SHARE MODE] 查询时加写或读锁 注意点1（加锁）： 注意，读锁加到表上之后，此表将只能读，不能进行其他任何操作。

一、简介 supervisord的官网： http://supervisord.org 。 看懂英文的可以不用看我的博客，直接看文档就行了，文档写得非常好。点个赞！！　　 Supervisor是一个客户/服务器系统，它可以在类Unix系统中管理控制大量进程。Supervisor使用python开发，有多年历史，目前很多生产环境下的服务器都在使用Supervisor。 Supervisor的服务器端称为supervisord，主要负责在启动自身时启动管理的子进程，响应客户端的命令，重启崩溃或退出的子进程，记录子进程stdout和stderr输出，生成和处理子进程生命周期中的事件。可以在一个配置文件中配置相关参数，包括Supervisord自身的状态，其管理的各个子进程的相关属性。配置文件一般位于/etc/supervisord.conf。 Supervisor的客户端称为supervisorctl，它提供了一个类shell的接口（即命令行）来使用supervisord服务端提供的功能。通过supervisorctl，用户可以连接到supervisord服务器进程，获得服务器进程控制的子进程的状态，启动和停止子进程，获得正在运行的进程列表。客户端通过Unix域套接字或者TCP套接字与服务端进行通信，服务器端具有身份凭证认证机制，可以有效提升安全性。当客户端和服务器位于同一台机器上时

实验步骤 控制文件是一个二进制文件，为了查看其内容，我们可以通过oracle命令转储出来进行查看（以下命令来自oracle 19c）： SQL> alter session set events 'immediate trace name controlf level 8'; Session altered. SQL> select value from v$diag_info where name='Default Trace File'; VALUE -------------------------------------------------------------------------------- /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_13639.trc 解读 19c trace trc 文件头简介 文件头对文件来源做出了简介：包括文件信息、数据库信息、DB版本号、系统信息、实例信息和进程信息 # 文件名 Trace file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_13639.trc ​ # 数据库信息 Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 -

LOG 信息查看方法 在设备的/VAR/LOG下面存储着设备的 LOG信息，可以在 CLI中直接查看这些 LOG文件的内容，包括通过 DEBUG 命令生成的日志文件。 查看目录下的日志文件列表 srx>file list /cf/var/log 查看日志文件内容 srx> show log kmd 来源： 51CTO 作者： tuolzb 链接： https://blog.51cto.com/13001500368/2481735

一、LogMiner的用途 日志文件中存放着所有进行数据库恢复的数据，记录了针对数据库结构的每一个变化，也就是对数据库操作的所有 DML 语句。 在 Oracle 8i 之前， Oracle 没有提供任何协助数据库管理员来读取和解释重作日志文件内容的工具。系统出现问题，对于一个普通的数据管理员来讲，唯一可以作的工作就是将所有的 log 文件打包，然后发给 Oracle 公司的技术支持，然后静静地等待 Oracle 公司技术支持给我们最后的答案。然而从 8i 以后， Oracle 提供了这样一个强有力的工具 -LogMiner 。 LogMiner 工具即可以用来分析在线，也可以用来分析离线日志文件，即可以分析本身自己数据库的重作日志文件，也可以用来分析其他数据库的重作日志文件。 总的说来， LogMiner 工具的主要用途有： 1 ．跟踪数据库的变化：可以离线的跟踪数据库的变化，而不会影响在线系统的性能。 2 ．回退数据库的变化：回退特定的变化数据，减少 point-in-time recovery 的执行。 3 ．优化和扩容计划：可通过分析日志文件中的数据以分析数据增长模式。 二、安装LogMiner 要安装 LogMiner 工具，必须首先要运行下面这样两个脚本， 1．$ORACLE_HOME/rdbms/admin/dbmslm.sql 2．$ORACLE_HOME

　　　　　　　　　　　　　　　　　　　　　1 .冷备份 （执行冷备份前必须关闭数据库） 物理备份 （备份物理数据库文件） 　　　　　　　　　　　　　　　　　　　　　2. 热备份 （热备份是当数据库正在运行时进行数据备份的过程。执行热备份的前提是：数据库运行在可归档日志模式。适用于24X7不间断运行的关键应用系统） 冷备份数据库的步骤 （1）关闭数据库； （2）备份所有相关的数据库文件：初始化参数文件、控制文件（可用select name from v$controlfile;列出所有控制文件）、数据文件（可用select name from v$datafile;列出所有数据文件）、Redo日志（可用select member from v$logfile;列出所有redo日志文件）、归档的Redo日志（可用select sequence#,first_time from v$loghist;列出所有归档redo日志文件的顺序号和产生时间）。 冷备份数据库的脚本文件coldbackup.bat 热备份数据库的前提条件：数据库运行在归档模式 Oracle数据库安装默认运行在非归档模式 从非归档模式转换为归档模式（ （1）设置数据库自动归档 log_archive_start = true # 设置归档日志文件的目录，该目录必须事先已建立，并有大量可利用的空间 log_archive

3 月，跳不动了？>>> 上次的 Kafka 重启失败事件，对为什么重启失败的原因似乎并没有解释清楚，那么我就在这里按照我对 Kafka 的认识，从源码和日志文件结构去尝试寻找原因。 从源码中定位到问题的根源 首先把导致 Kafka 进程退出的异常栈贴出来： 注：以下源码基于 kafka 0.11.0.2 版本。 我们直接从 index 文件损坏警告日志的位置开始： kafka.log.Log#loadSegmentFiles 从前一篇文章中已经说到，Kafka 在启动的时候，会检查kafka是否为 cleanshutdown，判断依据为 ${log.dirs} 目录中是否存在 .kafka_cleanshutDown 的文件，如果非正常退出就没有这个文件，接着就需要 recover log 处理，在处理中会调用 。 在 recover 前，会调用 sanityCheck() 方法用于检验每个 log sement 的 index 文件，确保索引文件的完整性 ，如果发现索引文件损坏，删除并调用 recoverSegment() 方法进行索引文件的重构，最终会调用 recover() 方法： kafka.log.LogSegment#recover 源码中相关变量说明： log：当前日志 Segment 文件的对象； batchs：一个 log segment 的消息压缩批次；

今天发现数据库事务日志竟然达到500多M,这也难怪,修改数据如此频繁 想要清理,发现没有办法,上GOOGLE上一搜,在ZDNET上找到答案也 先分离数据库,然后删掉日志文件,接下来再attach数据库,SQL会显示日志文件丢失,按确定ATTACH的时候,会提示你创建新的日志文件,只要确定即可完成,简单方便 不过,需要提醒的是,第一,在删除日志前,最好将老的日志文件全都备份一下 第二,如果你的事务日志存放于多个物理文件中,那么,上面的方面就没办法帮你清理喽 不过,下面的方法绝对快 backup log db_name with no_log dbcc shrinkfile (northwind_log,5) 来源： https://www.cnblogs.com/Heroman/archive/2004/12/15/77572.html