Oracle中终止会话KILL SESSION

Oracle中终止会话KILL SESSION

 

终止会话:

将例程置于受限模式后,在执行管理任务前可能想终止所有当前用户会话。此操作可通过以下命令来实现:

ALTER SYSTEM KILL SESSION ‘integer1,integer2’

其中:

  • integer1:V$SESSION 视图中的 SID 列的值
  • integer2:V$SESSION 视图中的 SERIAL# 列的值

注:会话 ID 和序列号用来唯一地标识会话。这样,即使用户注销身份并且新会话使用相
同的会话 ID,也可确保 ALTER SYSTEM KILL SESSION 命令能够应用于正确的会话。

终止会话的影响:

ALTER SYSTEM KILL SESSION 命令一执行,将使后台进程 PMON 立即执行以下步骤:

  • 回退用户的当前事务
  • 释放所有当前持有的表或行锁定
  • 释放用户当前保留的所有资源

终止特定实例上的会话

从 Oracle RAC 11gR1 开始,可以使用 ALTER SYSTEM KILL SESSION 语句终止特定实例上的会话。

幻灯片通过以下方式对此进行了说明:在另外一个不同于终止有问题会话的实例上,终止一个已启动的会话。

如果会话正在执行某个必须完成的活动(例如等待来自远程数据库的答复或者回退事务处理)则 Oracle DB 必须等待该活动完成,将该会话标记为“已终止”,然后将控制权返回给您。如果等待持续一段时间,则 Oracle DB 会将该会话标记为“待终止”并将控制权返回给您,同时向您发送一条消息说明会话被标记为“待终止”。然后,PMON 后台进程会在该活动完成后将该会话标记为“已终止”。

注:还可以在 ALTER SYSTEM 命令的末尾使用 IMMEDIATE 子句以便立即终止会话而不等待未完成活动完成。

 

 

SQL> SELECT SID, SERIAL#, INST_ID
  FROM GV$SESSION WHERE USERNAME='JFV';
SID    SERIAL#    INST_ID   
140       3340          2


SQL> ALTER SYSTEM KILL SESSION '140,3340,@2';
System altered.

SQL>


 

 

 

Oracle Archived log 归档重做日志/归档日志详解

Oracle Archived log 归档重做日志/归档日志详解

 

V$ARCHIVED_LOG
此视图显示包含归档日志名的控制文件中的归档日志信息 在联机重做日志成
功归档或清除后会插入归档日志记录 如果已清除日志 则名称列为
NULL 如果日志归档两次 将产生两个归档日志记录 它们具有相同的
THREAD# SEQUENCE# 和 FIRST_CHANGE# 但名称不同 使用备份集或
副本恢复归档日志后 也会插入归档日志记录

RECID 归档的日志记录 ID
STAMP 归档的日志记录标记
NAME 归档的日志文件名 如果设置为 NULL 则日志文件在归
档前被清除
THREAD# 重做线程编号
SEQUENCE# 重做日志序列号
RESETLOGS_
CHANGE#
写入此日志时数据库的重置日志更改 #
RESETLOGS_TIME 写入此日志时数据库的重置日志时间
FIRST_CHANGE# 归档日志中的第一更改 #
FIRST_TIME 第一更改的时间标记
NEXT_CHANGE# 下一日志中的第一更改
NEXT_TIME 下一更改的时间标记
BLOCKS 块中归档日志的大小
BLOCK_SIZE 重做日志块大小
COMPLETION_TIME 归档完成时的时间
DELETED YES/NO

V$ARCHIVE_PROCESSES

 

PROCESS 例程的 ARCH 进程标识符 编号为 0 至 9
STATUS ARCH 进程的状态 显示为一个关键字 可能的值有
STOPPED SCHEDULED STARTING ACTIVE
STOPPING 和 TERMINATED
LOG_SEQUENCE 这是当前正在归档的联机重做日志序列号 如果 STATE=BUSY
STATE 这是 ARCH 进程的当前状态 显示为一个关键字 可能的关键字为 IDLE 或 BUSY

 

归档日志文件配置

 

如果要归档 重要的是要有两个以上的重做日志组 当一个组切换到另外一个组时 DBWn 进程必须同往常一样进行检查 并且必须将一个文件归档 在LGWR 进程需要再次覆盖该文件之前 必须为上述两个操作留出时间

调整归档速度

有时 在非常繁忙的数据库中 单个 ARC0 进程跟不上写入重做日志的大量信息 Oracle8i 允许数据库管理员通过使用LOG_ARCHIVE_MAX_PROCESSES 参数 定义多个归档进程

只要当前的 ARCn 进程数不足以处理工作量 LGWR 进程就会启动新的ARCn 进程 如果预计有繁重的归档工作量 可通过运行下述命令 手动启动共享该工作的服务器进程
SQL>ALTER SYSTEM ARCHIVE LOG ALL TO ‘directory_name‘;

应监视 V$ARCHIVE_PROCESSES 以便任何时候 只要有两个以上的日志
需要归档 它就发出警报并产生额外的归档程序进程

 
SQL> select * from v$archive_processes;
PROCESS STATUS LOG_SEQUENCE STAT
——— ———- ———— —-
0 ACTIVE 122 BUSY
1 ACTIVE 0 IDLE
2 STOPPED 0 IDLE

 


当初始化参数 DBWR_IO_SLAVES 设置为大于 0 的值时 为归档重做日志
文件而由 ARC0 进程使用的多个 I/O 从属将自动设置为 4

不能在原始设备上创建归档重做日志文件

有关 LOG_ARCHIVE_MAX_PROCESSES, LOG_ARCHIVE_DEST_n, 和
LOG_ARCHIVE_DEST_STATE_n 参数的全面解释 请参照 Oracle8i 备份和恢复 课程的第 2 课

LOG_ARCHIVE_DEST_n 参数仅在已经安装了 Oracle 企业版时才有效 如果已经安装了 Oracle 企业版 则可以继续使用 LOG_ARCHIVE_DEST 但不能同时使用 LOG_ARCHIVE_DEST_n 和 LOG_ARCHIVE_DEST 因为它们不兼容

 

获得有关已归档日志文件及其位置的信息
若要从控制文件显示归档日志信息 包括归档日志名称 可以查询
V$ARCHIVED_LOG 动态性能视图 在联机重做日志已成功归档或清除 如果日志已清除 名称栏则为 NULL 之后 即会插入归档日志记录 如果日志归档两次 将产生两个归档日志记录 它们具有相同的 THREAD# SEQUENCE#和 FIRST_CHANGE# 但名称不同

对于当前的例程 动态性能视图 V$ARCHIVE_DEST 描述所有的归档日志目标 它们的当前值 模式和状态

Oracle Redo Online Logfile 重做在线日志

Oracle Redo Online Logfile 重做在线日志负责:

  • 记录数据库变更
  • 应该多路复用以避免遗失

 

重做日志文件是用来记录数据库的变更情形,而这些变更源自事务及内部Oracle是数据库服务器操作。

 

注意:【事务(Transaction)】是工作的逻辑单元,它是由的单一使用者所执行的一或多个SQL命令组成。当发生电源中断、从磁盘错误等问题时,重做日志文件能保护数据库以避免损坏完整性。平时应该多路复用重做日志文件,以确保在磁盘发生错误的时候,不至于遗失储存在其中的信息。

 

重做日志是由一组组的重做日志文件构成,而每个重做日志文件组则是由一个重做日志文件及其多重备份的副本组成。每个完全相同的副本是该组的成员之一。而每个组是透过一组号码来识别。日志写入器进程(LGWR)会从重做日志缓冲区讲重做记录写入重做日志组,一直到组中的文件被填满,或是出现日志切换要求为止。接着写入器就会进行切换,然后写入下一个组的文件中。重做日志组是以循环方式来使用的。

 

您可以查看数据库中重做日志文件的相关信息,请在【服务器(Server)】页面的【存储(Storage)】区中按一下【重做日志组(Redo Log Groups)】链接。您可以选择一个组,再按【查看(View)】来查看各种详细信息,例如重做日志文件名称。

 

 

 

多路复用重做日志

 

您可以在现有的日志组中新增一个成员,制作重做日志的多路复用。请按照下列步骤执行,将成员新增到重做日志组中:

  1. 在【服务器(Server)】页面的【存储(Storage)】区中按一下【重做日志组(Redo Log Groups)】。会出现【重做日志组(Redo Log Groups)】页面。
  2. 选择一个组,再按一下【编辑(Edit)】,或是按一下组的编号链接。接着会出现【编辑重做日志(Edit Redo Log)】.
  3. 在【重做日志成员(Redo Log Members)】区按一下【添加(Add)】。会出现【添加重做日志成员(Add Redo Log Member)】页面。
  4. 输入文件名称与文件目录。按一下【继续(Continue)】。之后点【应用(Apply)】。

 

 

注意: 建议您在不同的磁盘上储存成员,以免重做日志项目因磁盘失败事件而全部遗失。

  1. 为每个现有大的日志组重复执行这些步骤。

 

当您将重做日志成员加入日志组时,组的状态会标示为INVALID,这是因为此组的成员还没有被写入。当发生日志切换,而无效日志组成为当前组时,,状态就会变为CURRENT。

 

丢失了重做日志文件

 

丢失了单个重做日志组成员后进行恢复并不会影响运行的实例。要执行这种恢复,请执行以下步骤:

1. 检查预警日志,确定是否有缺失的日志文件。

2. 通过以下方式恢复缺失的文件,先删除丢失的重做日志成员:

SQL> ALTER DATABASE DROP LOGFILE MEMBER ‘redo01a.log’;

然后添加新的成员以替换丢失的重做日志成员:

SQL> ALTER DATABASE ADD LOGFILE MEMBER ‘redo01a.log’
TO GROUP 2;

注:如果使用的是重做日志文件的 OMF,并使用上述语法将新重做日志成员添加到现有组,则此新的重做日志成员文件不会是 OMF 文件。如果要确保新的重做日志成员是 OMF 文件,最简便的恢复方式是新建一个重做日志组,然后删除缺少重做日志成员的重做日志组。

3. 如果介质故障是由于丢失了磁盘驱动器或控制器造成的,请重命名缺失文件。

 

4. 如果重做日志组已归档,或者您处于 NOARCHIVELOG 模式下,则可选择在清除日志 组后重新创建缺失文件来解决问题。选择相应的组,然后选择“Clear Logfile(清除 日志文件)”操作。还可以使用以下命令手动清除受影响的组:

 

SQL> ALTER DATABASE CLEAR LOGFILE GROUP #;

注:Database Control 不允许清除尚未归档的日志组。这样做会打断重做信息链。如果必 须清除未归档的日志组,则应立即执行整个数据库完全备份。否则,在发生其它故障的 情况下,会导致数据丢失。要清除未归档的日志组,请使用以下命令:

 

SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP #;

 

日志写入程序 (LGWR) 将重做日志缓冲区中注册的更改写入重做日志文件

在重做日志缓冲区中 服务器进程记录将要对回退和数据进行的更改

  •  回退块更改记录数据修改以前的值 回退块用于存储成图象前的数据以便必要的情况下 DML 语句能够回退
  • 数据块更改记录数据的新值

 

归档程序进程

其它所有的后台进程都是可选的 这取决于数据库的配置 但是 其中的ARC0 对于磁盘丢失后的数据库恢复起着至关重要的作用 当联机重做日志文件填满时 Oracle 服务器开始写入下一个联机重做日志文件 从一个重做日志到另一个的切换过程称为日志切换

将重做日志文件归档

DBA 必须做出的一个重要决策是配置数据库以 ARCHIVELOG 模式还是以NOARCHIVELOG 模式操作

 

NOARCHIVELOG 模式 在 NOARCHIVELOG 模式中 每发生一次日志切换
都会覆盖联机重做日志文件 LGWR 直到重做日志组的检查点完成才覆盖该
组 这确保当发生例程崩溃时提交的数据能够得以恢复 在例程崩溃过程中
只丢失 SGA 磁盘没有任何丢失 只有内存会丢失 例如 操作系统的崩溃引
起例程崩溃

 

ARCHIVELOG 模式 如果配置数据库使它以 ARCHIVELOG 模式运行 那么已满的联机重做日志文件的非活动组必须归档之后才能够再次使用 因为对数据库所做的更改记录在联机重做日志文件中 所以 DBA 能够使用数据文件的物理备份和归档的联机重做日志文件来恢复数据库 而不会由于任何单个出错点 包括磁盘的丢失 而丢失任何已提交数据 通常将生产数据库配置为以ARCHIVELOG 模式运行

ARC0 进程

ARC0 进程在每次日志切换时启动已满日志组的备份或归档 在日志能够重新使用之前 它自动将联机重做日志归档 以便对数据库做的所有更改得以保留这样即使磁盘驱动器破坏 DBA 也能够将数据库恢复到出错时的程度

 

重做日志文件用途

Oracle 服务器维护联机重做日志文件以使数据库中的数据丢失减到最小 重做 日志文件记录对数据库缓冲区高速缓存内数据所做的所有更改 但也有例外 例如 在直接写入情况下 重做日志文件用来在诸如例程失败的情况下恢复尚未写入数据文件的提交数 据 重做日志文件仅用于恢复

 

重做日志文件结构

数据库管理员可设置 Oracle 数据库以维护联机重做日志文件副本 来避免由于 单点故障丢失数据库信息

 

联机重做日志组

一组相同的联机重做日志文件副本称作联机重做日志组

  • LGWR 后台进程向组内所有联机重做日志文件并发写入相同信息
  • 为保证数据库的正常操作 Oracle 服务器最少需要两个联机重做日志文件组

 

联机重做日志成员

  • 组内的每个联机重做日志文件称为成员
  • 组内的每个成员都有相同的日志序列号和同样的大小 Oracle 服务器每次开始写入日志组时 都分配一个日志序列号以唯一识别每个重做日志文件 当前日志序列号存储在控制文件和所有数据文件的标题内

创建初始重做日志文件
联机重做日志组和成员的初始集是在数据库创建时创建的
下面的参数限制了联机重做日志文件的数量

  • CREATE DATABASE 命令中的 MAXLOGFILES 参数指定联机重做日志组的绝对最大数量MAXLOGFILES 的最大值和缺省值取决于您的操作系统
  • CREATE DATABASE 命令所使用的 MAXLOGMEMBERS 参数决定每个组成员的最大数量 MAXLOGMEMBERS 的最大值和缺省值取决于您的操作系统
  • LOG_FILES 初始化参数设置在运行时可以为数据库打开的日志组的当前最大数量 该参数不能超过 MAXLOGFILES

技术注释
LOG_FILES 参数在 8.1 版本内已作废以简化数据库管理

 

重做日志缓冲区和 LGWR 后台进程

Oracle 服务器将对数据库所做的所有更改连续记录到重做日志缓冲区中 重做 日志缓冲区以循环方式使用 在下列情况下 LGWR 进程将重做条目写入到被 称为当前联机重做日志组的联机重做日志组之一:

  • 当提交事务时
  • 当重做日志缓冲区三分之一满时
  • 当重做日志缓冲区内有超过 1 MB 的已更改记录时
  • 当发生超时时 每三秒钟
  • 在 DBWn 将数据库缓冲区高速缓存内的修改块写入数据文件之前

 

日志切换

LGWR 连续向联机重做日志文件写入 也就是说 当当前联机重做日志组已满 时 LGWR 开始向下一个组写入 当最后一个可用联机重做日志文件已满时 LGWR 返回到第一个联机重做日志组并再次开始写入

 

数据库管理员也可以强制日志切换 见后续部分 每次发生日志切换并且 LGWR 开始向新日志组写入时 Oracle 服务器都会指定一个所谓的日志序列号 以识别重做条目集。

当发生日志切换时 将启动一个称为检查点的事件。

日志切换 是一个事件 在该事件期间 LGWR 停止向一个联机重做日志组写入 并开始向另一个联机重做日志组写入。

 

检查点

在检查点期间:

  • DBW n 将许多由正在经历检查点事件的日志覆盖的灰数据库缓冲区写入到 数据文件中 由 DBWn 写入的缓冲区数量由参数 FAST_START_IO_TARGET 决定 如果指定了的话 这在 Enterprise DBA Part 1B: Backup and Recovery 企业 DBA 1B 部分 备份和恢复 课程 中有更详细阐述
  • 检查点后台进程 CKPT 更新所有数据文件和控制文件的标题以反映该进程已 成功完成

 

检查点可以为数据库内所有 数据文件发生或者仅为特定数据文件发生

例如 检查点可发生在下面情况中

 

• 每次日志切换时
• 当已通过正常 事务处理或者立即选项关闭例程时
• 当通过设置初始化参数 LOG_CHECKPOINT_INTERVALLOG_CHECKPOINT_TIMEOUT 和 FAST_START_IO_TARGET 强制时见后续部分
• 当数据库管理员手动请求时 见后续部分

如果初始化参数 LOG_CHECKPOINTS_TO_ALERT 设置为 TRUE 则每个检查 点信息都记录在 ALERT 文件内 该参数缺省值为 FALSE 不记录检查点

 

 

决定是否应当启用将重做日志文件归档

数据库管理员必须做的一个重要决策是数据库配置为在 ARCHIVELOG 模式下
还是在 NOARCHIVELOG 模式下操作

NOARCHIVELOG 模式 在 NOARCHIVELOG 模式下 在每次联机重做日志
文件已满并发生日志切换时 都要覆盖联机重做日志文件 直到该重做日志组
检查点完成 LGWR 才覆盖该重做日志组
ARCHIVELOG 模式 如果数据库配置为在 ARCHIVELOG 模式运行下 那么
必须将已满联机重做日志文件的不活动组归档 因为对数据库所做的所有更改
都记录在联机重做日志文件内 数据库管理员可以使用物理备份和归档的联机
重做日志文件恢复数据库 而不会丢失任何已提交数据
归档联机重做日志文件有两种方法
• 手动
• 自动

LOG_ARCHIVE_START 初始化参数表明例程启动时 使用手动还是自动归档
• TRUE 表明归档是自动的 ARCn 将在每次日志切换时启动将已满日志组归

• FALSE 缺省值 表明数据库管理员将手动 将已满重做日志文件归档 在
每次归档联机重做日志文件时 数据库管理员必须手动执行一条命令 可以
对所有或特定的联机重做日志文件进行手动归档。

获取日志组信息
若要查看联机重做日志组数量 当前日志组和序列号 请查询动态性能视图
V$THREAD Parallel Server 并行服务器 管理员对这一点尤为感兴趣
SQL> SELECT groups, current_group#, sequence#
2 FROM v$thread;
GROUPS CURRENT_GR SEQUENCE#
———- ———- ———-
2 1 689
1 row selected.
下面的查询返回控制文件中关于联机重做日志文件的信息
SQL> SELECT group#, sequence#, bytes, members, status
2 FROM v$log;
GROUP# SEQUENCE# BYTES MEMBERS STATUS
——— ———- ——– ——— ———
1 688 1048576 1 CURRENT
2 689 1048576 1 INACTIVE
2 rows selected.
下面的项是 STATUS 列的常见值

• UNUSED 表明从未对联机重做日志组进行写入 这是刚添加的联机重做日
志文件的状态
• CURRENT 表明当前的联机重做日志组 这意味着该联机重做日志组是活动

• ACTIVE 表明联机重做日志组是活动的 但是并非当前联机重做日志组 崩
溃恢复需要该状态 它可能正用于块恢复 它可能归档 也可能不归档

• CLEARING 表明在 ALTER DATABASE CLEAR LOGFILE 命令后正在将该
日志重建为一个空日志 日志清除后 其状态更改为 UNUSED

• CLEARING_CURRENT 表明正在清除当前日志文件中的已关闭线程 如果
切换时发生某些故障 如写入新日志标题时的 I/O 错误 则该日志可以停
留在该状态

• INACTIVE 表明例程恢复不再需要联机重做日志组 它可能归档 也可能不
归档
获取日志成员信息

若要获取组内所有成员的名称 请查询动态性能视图 V$LOGFILE
SQL> SELECT *
2> FROM v$logfile;
GROUP#STATUSMEMBER
—————– —————————–
1 /DISK3/log1a.rdo
2 /DISK4/log2a.rdo
STATUS 列的值可以为下列之一
• INVALID 表明该文件不可访问
• STALE 表明该文件内容不完全 例如 正在添加一个日志文件成员
• DELETED 表明该文件已不再使用
• 空白表明文件正在使用中
强制日志切换和检查点
当 LGWR 停止向一个联机重做日志组写入并开始向另一个联机重做日志组写入时 就发生了日志切换
日志切换和检查点是自动发生的事件 例如 当当前联机日志文件组已满时
但日志切换和检查点也可以强制执行
强制日志切换
可以使用下面的 SQL 命令来强制日志切换
SQL> ALTER SYSTEM SWITCH LOGFILE;
强制检查点
可以使用下面的 SQL 命令手动强制检查点
SQL> ALTER SYSTEM CHECKPOINT;

设置数据库检查点时间间隔
当数据库使用大型联机重做日志文件时 您可以通过设置以下初始化参数来设
置其它数据库检查点
• LOG_CHECKPOINT_INTERVAL
• LOG_CHECKPOINT_TIMEOUT
• FAST_START_IO_TARGET 版本 8.1 但只限于企业版
LOG_CHECKPOINT_INTERVAL 对于低于 8.1 的版本 LGWR 一写入参数
LOG_CHECKPOINT_INTERVAL 指定的块数 就启动了检查点
LOG_CHECKPOINT_INTERVAL 值在操作系统块中指定而不是在 Oracle 数据
库块中指定
无论该值如何 当从一个联机重做日志文件切换到另一个时 检查点始终发

如果该值超过实际联机重做日志文件大小 那么检查点仅在日志切换时发生
请注意将时间间隔值指定为 0 可能导致非常频繁地启动检查点 因为即使上一
个请求启动后仅对单个重做日志缓冲区写入 仍会启动新的请求
在版本 8.1 内 当指定了 LOG_CHECKPOINT_INTERVAL 后 检查点位置目标
相对于日志尾的滞后不能大于该参数指定的重做日志块数 这确保了在例程恢
复期间 需要读取不超过固定数目的重做块
LOG_CHECKPOINT_TIMEOUT 对于低于 8.1 的版本 该初始化参数值指
定了另一个检查点发生前的最大时间量 该值按秒指定 该时间从前一个检查
点启动时开始 经过该参数指定的时间量后发生另一个检查点
将超时值指定为 0 以禁用基于时间的检查点
在 8.1 版本内 当指定了 LOG_CHECKPOINT_TIMEOUT 后 该参数将检查点
位置目标设置到日志文件中的某个位置 而该日志在该参数指定的秒数前结
束 这确保了在恢复期间 需要读取的重做块数不超过与指定秒数相当的块

FAST_START_IO_TARGET 参数 FAST_START_IO_TARGET 改善了崩溃和
例程恢复的性能 该参数值越小 由于需要恢复的块就越少 因而恢复性能就
越好 该参数设置后 DBWn 更积极地将灰缓冲区写出 该参数在版本 8.1 中
引入
添加重做日志组
在某些情况下 您可能需要创建其它日志文件组 例如 添加组可以解决可用
性问题 若要创建一个新的联机重做日志文件组 请使用下面的 SQL 命令
ALTER DATABASE [database]
ADD LOGFILE [GROUP integer] filespec
[, [GROUP integer] filespec]…]
您可以通过文件说明来指定成员名称和位置 可以选择每个重做日志文件组的
GROUP 参数值 如果您省略了该参数 Oracle 服务器自动生成其值

添加重做日志成员
您可以使用下面的 ALTER DATABASE ADD LOGFILE MEMBER 命令向现有的
重做日志文件组添加新成员
ALTER DATABASE [database]
ADD LOGFILE MEMBER
[ ‘filename’ [REUSE]
[, ‘filename’ [REUSE]]…
TO {GROUP integer
|(‘filename'[, ‘filename’]…)
}
]…
请使用日志文件成员的完全指定名 否则将在数据库服务器缺省目录下创建该
文件
如果该文件已经存在 其大小必须与指定值相同 并且必须指定 REUSE 选项
您可以通过指定一个或多个组内成员或者指定组号来识别目标组

重命名重做日志文件
可以通过重命名联机重做日志文件来更改联机重做日志文件的位置 在重命名
联机重做日志文件之前 请确保新的联机重做日志文件存在 Oracle 服务器仅
更改控制文件内的指针 并不从物理上重命名或创建任何操作系统文件
下面的 ALTER DATABASE RENAME FILE 命令可更改联机重做日志文件的名

ALTER DATABASE [database]
RENAME FILE ‘filename'[, ‘filename’]…
tO ‘filename'[, ‘filename’]..

丢弃重做日志组
若要增大或者减小联机重做日志组的大小 请添加新的联机重做日志组 具有
新的大小 然后丢弃旧组
可以使用下面的 ALTER DATABASE DROP LOGFILE 命令丢弃整个联机重做日
志组
ALTER DATABASE [database]
DROP LOGFILE
{GROUP integer|(‘filename'[, ‘filename’]…)}
[,{GROUP integer|(‘filename'[, ‘filename’]…)}]…
限制
• 一个例程至少需要两组联机重做日志文件
• 无法丢弃活动组或者当前组
• 如果数据库运行在 ARCHIVELOG 模式下并且未将日志文件组归档 那么无
法丢弃该组
• 在丢弃联机重做日志组时 并没有删除操作系统文件
您可能因为一个联机重做日志成员状态为 INVALID 而想丢弃它 如果您想丢弃
一个或者多个特定的联机重做日志成员 请使用下面的 ALTER DATABASE
DROP LOGFILE MEMBER 命令
ALTER DATABASE [database]
DROP LOGFILE MEMBER ‘filename'[, ‘filename’]…
限制
• 如果要丢弃的是组内的最后一个有效成员 那么您不能丢弃该成员
• 如果该组是当前组 那么在能够丢弃该成员之前 您必须强制日志文件切

• 如果数据库正运行在 ARCHIVELOG 模式下并且未将该成员所属日志文件组
归档 那么您无法丢弃该成员
• 在丢弃联机重做日志成员时 并未删除操作系统文件
清除联机重做日志文件
如果一个重做日志文件的所有成员都已破坏 数据库管理员可以通过重新初始
化这些日志文件来解决该问题
SQL 命令 ALTER DATABASE CLEAR LOGFILE 重新初始化联机重做日志文

ALTER DATABASE [database]
CLEAR [UNARCHIVED] LOGFILE
{GROUP integer|(‘filename'[, ‘filename’]…)}
[,{GROUP integer|(‘filename'[, ‘filename’]…)}]…

使用该命令等效于添加和丢弃联机重做日志文件 但即使只有两个日志组 每
个组内只有一个文件 并且即使已清除组可用但没有归档 您仍可以发出该命令
限制
无论联机重做日志文件是否归档 您都可以清除它 但是 在其没有归档时
您必须包含关键字 UNARCHIVED 如果恢复需要该联机重做日志文件 这将
使得备份不可用

联机重做日志文件数量

要确定一个数据库例程的联机重做日志文件的合适数量 您必须测试不同的配置
在某些情况下 数据库例程可能只需要两个组 在其它情况下 数据库例程可
能需要其它组以保证组始终可供 LGWR 使用 例如 如果 LGWR 跟踪文件或
者 ALERT 文件中的消息表明 LGWR 经常不得不因为检查点尚未完成或者组尚
未归档而等待 您就需要添加组
尽管 Oracle 服务器允许多路复用的组包含不同数量的成员 但请尽量建立对称
配置 不对称配置应仅是非常情况 如磁盘故障 的临时结果
联机重做日志文件位置
在多路复用联机重做日志文件时 请将组内的成员放置在不同磁盘上 这样即使一个成员不可用而其它成员可用 该例程也不会关闭将归档日志文件和联机重做日志文件分隔在不同磁盘上 以减少 ARCn 和LGWR 后台进程之间的争用
数据文件和联机重做日志文件应当放置在不同的磁盘上以减少 LGWR 和 DBWn
的争用 并减少在发生介质失败事件时同时丢失数据文件和联机重做日志文件
的风险
调整联机重做日志文件的大小
联机重做日志文件的大小最小为 50 KB 最大大小因操作系统而定 不同组的
成员可以有不同的大小 但是 大小不同的组不会带来任何好处
应当仅在想更改联机重做日志组内成员的大小时才需要大小不同的组作为临时
结果 在这种情况下 您必须创建新的大小不同的联机重做日志组 然后删除
旧组
下面的情况可能影响联机重做日志文件的配置
• 日志切换和检查点的数量
• 重做条目的量和个数
• 存储介质的空间量 例如 启用归档时磁带上的空间量
不可用重做日志成员

当某些联机重做日志成员不可用时 LGWR 反应不一
• 如果 LGWR 至少能够访问一个组内成员 对组内可访问成员的写入将照常
进行 LGWR 忽略组内的不可用成员 如果该组不活动 即检查点已完
成 那么丢弃和添加一个新的重做日志成员就可以解决问题 否则 您必
须首先强制日志切换
• 如果在日志切换时 LGWR 无法访问下一个组的所有成员 则该例程关闭
如果组不活动 那么丢弃和添加一个新的重做日志组就可解决问题 如果活
动 数据库可能需要从联机重做日志文件残留物进行介质恢复
• 如果正在写入当前组的所有成员时 LGWR 突然无法访问这些成员 则该数
据库例程关闭 在这种情况下 数据库可能需要从联机重做日志文件残留物
进行介质恢复

LogMiner 能用来干什么 ?

LogMiner 提供了一个处理重做日志文件并将其内容翻译成代表对数据库的逻辑
操作的 SQL 语句的过程
使用 LogMiner 之前应当做什么
无论数据库装载或卸载 LogMiner 都可在 Oracle 例程上运行 LogMiner 使用字典文件 该特殊文件表明创建它的数据库以及文件创建时间 字典文件并非必需 但建议使用
没有字典文件 等效 SQL 语句将使用 Oracle 内部对象 ID 作为对象名称并以十
六进制数据提供列值

创建字典文件

• 指定初始化参数 UTL_FILE_DIR 以指定一个允许 PL/SQL 文件 I/O 的目录
• 执行 BMS_LOGMNR_D.BUILD 过程以创建字典文件
设置 LogMiner 会话

一旦创建了字典文件 您就可以开始分析重做日志 第一步是使用DBMS_LOGMNR.ADD_LOGFILE 过程指定要分析的日志文件

使用下列常量
• DBMS_LOGMNR.NEW 创建一个新列表并指定第一个日志文件
• DBMS_LOGMNR.ADDFILE 向列表中添加其它日志文件
• DBMS_LOGMNR.REMOVEFILE 从列表中删除重做日志

LogMiner 可以分析联机和归档日志文件
启动 LogMiner 会话

一旦创建了字典文件并指定了重做日志列表 您就可以启动 LogMiner 并开始
分析 启动时 使用如下选项来缩小搜索范围
选项 说明
StartScn 系统更改号 (SCN) 范围的起始
EndScn SCN 范围的终止
StartTime 时间间隔的开始
EndTime 时间间隔的结束
DictFileName 字典文件名
选项 使用 logmnr.opt 文件中指定的列映射 值为
USE_COLMAP

追踪对表的更改

可通过 V$LOGMNR_CONTENTS 视图查看输出 只有执行分析的会话可以查
看日志信息 其它会话无法查看该信息 如果其它会话要查看结果 可将信息
存储在其它表中

停止 LogMiner 会话

执行 DBMS_LOGMNR.END_LOGMNR 过程以完成分析重做日志的会话
查看数据字典

LogMiner 一旦启动 就可以使用下面的数据字典视图视图 说明

V$LOGMNR_DICTIONARY 正在使用的字典文件
V$LOGMNR_PARAMETERS LogMiner 的当前参数设置
V$LOGMNR_CONTENTS 正在分析的重做日志文件内容

 

了解Oracle Alert.log 警报/告警/日志文件

Oracle Alert.log警报日志文件

每个 Oracle 例程都有一个警报日志文件。如果该文件尚未创建,将在例程启动过程中进行创建。警报日志文件由您进行管理,并随着数据库的继续运行而不断增长。诊断日常操作或错误时,应该首先查看警报日志文件。警报日志文件还包含指向跟踪文件的指针,从而可获得更详细的信息。

警报日志文件记录了以下信息:

  • 数据库启动或关闭的时间
  • 所有非缺省初始化参数的列表
  • 后台进程的启动
  • 例程使用的线程
  • 正在向其中写入信息的日志序列号 LGWR
  • 有关日志切换的信息
  • 表空间的创建和撤消段
  • 已发出的警报声明
  • 有关 ORA-600 等错误消息和区错误的信息

 

  • alertSID.log 文件:
    • 记录命令
    • 记录主要事件结果
    • 用于记录日常操作信息
    • 用于诊断数据库错误
  • 每个条目都带有与之相关联的时间戳
  • 必须由 DBA 进行管理
  • 存储位置由 BACKGROUND_DUMP_DEST 定义

 

 

告警日志这个文件里包含了依照之间排列的信息与错误日志。告警日志包括下列项目:

  • 所有发生的内部错误(ORA-600)、数据块损坏错误(ORA-1578)以及死锁错误(ORA-60)的记录。
  • 例如create、alter、drop命令以及startup、shutdown、archivelog命令等管理操作记录。
  • 与共享服务器与调度器进程功能相关的信息及错误。
  • 所有在实例启动时有非预设值的初始化参数数值。

Oracle服务器会将这些作业都记录在告警日志中,作为在操作员主控台(Operator’s console)显示信息的替代方式。如果操作成功,则会在告警日志中写入”completed”信息,并加上时间戳。

在Enterprise Manager中,您可以藉由按一下”数据库(Database)”首页中”相关链接(Related Links)”区域的”告警日志内容(Alert Log Content)”来检查告警日志中的内容。会显示”最近的告警日志项(Most Recent Alert Log Entries)”页面。

 

 

警报日志文件中的信息示例

ALTER DATABASE CLOSE NORMAL
ORA-1507 signalled during:ALTER DATABASE CLOSE NORMAL...
控制文件和联机表空间备份

Fri Jun 4 10:54:20
alter tablespace user_data begin backup
Fri Jun 4 10:54:21
ORA-1123 signalled during:alter tablespace user_data begin backup
...

由于轮换重做日志文件太快而导致未完成检查点

Thread 1 advanced to log sequence 1597
Current log# 2 seq# 1597 mem# 0:/users/cours/tun8_08/DATA/DISK3/
log2a.rdo
Thread 1 cannot allocate new log, sequence 1598
Checkpoint not complete

创建表空间

Fri Jun 4 10:57:20
create tablespace SYSTEM datafile '/home/disk3/user30/DATA/DISK1/
sys01.dbf' size 20m
default storage (initial 10K next 10K) online
Fri Jun 4 10:57:30
Completed:create tablespace SYSTEM datafile '/home/disk3/user30/
DATA/DISK1/sys01.dbf'
create tablespace rbs
datafile '/home/disk3/user30/DATA/DISK2/rbs01.dbf' size 30m
Fri Jun 4 10:58:48
Completed:create tablespace rbs datafile '/home/disk3/user30/DATA/
DISK2/rbs01.dbf'

创建和修改回退段

Fri Jun 4 11:57:48
create rollback segment SYSTEM tablespace SYSTEM
storage (initial 50K next 50K)
Completed:create rollback segment SYSTEM tablespace SYSTEM
Fri Jun 4 12:07:58
alter rollback segment rbs01 online
Completed:alter rollback segment rbs01 online
Fri Jun 4 12:58:48

由于警报日志文件会越来越大 占用的磁盘空间也会不断增加 所以应该经常
对其进行归档并删除 或者定期进行整理

 

 

找到 警报日志的SQL :

 


For Unix / Linux 

select
   vp.value||'/alert_'||INSTANCE_NAME||'.log'
from
   v$parameter vp ,v$instance  vi
where
   vp.name = 'background_dump_dest';


For Windows 

select
   vp.value||'\alert_'||INSTANCE_NAME||'.log'
from
   v$parameter vp ,v$instance  vi
where
   vp.name = 'background_dump_dest';

Oracle Controlfile 控制文件详解

Oracle Controlfile 控制文件详解

 

Oracle Controlfile控制文件

  • 包含物理数据库结构信息
  • 多路复用以免遗失
  • 在挂载mount阶段读取

 

当您启动数据库实例和挂载数据库时,就会读取控制文件。而控制文件中的项目则指定了构成数据库的物理文件。

当您将其他文件加入到数据库时,会自动更新控制文件。

您必须在CONTROL_FILES初始化参数中指定控制文件的位置。

为了避免数据库因为遗失控制文件而失败,您必须【多路复用(multiplex)】控制文件。在初始化参数中指定多个文档,就可以让Oracle数据库保有控制文件的多个副本。

您可以存取数据库中控制文件的相关信息,只要在Enterprise Manager的【服务器(Server)】页面【存储(Storage)】区中按一下【控制文件(Controlfiles)】链接。在【控制文件(Controlfiles General)】页面中会显示数据库控制文件的名称与位置。另外,【高级(Advanced)】页面中会提供建立控制文件和数据库识别的相关信息。而【记录文档段(Record Section)】页面则显示控制文件中项目的相关信息。

 

打开数据库与控制文件

 

当数据库从关闭阶段转到完全打开阶段时,数据库会执行内部一致性检查。这些阶段包括:

  • NOMOUNT:实例要达到 NOMOUNT(又称 STARTED)状态,就必须读取初始化参数文件。实例进入 NOMOUNT 状态时,不会检查任何数据库文件。
  • MOUNT:实例进入 MOUNT 状态时,会检查初始化参数文件中列出的所有控制文件是否都存在且已同步。即使有一个控制文件缺失或损坏,实例也会向管理员返回错误(指明缺失了控制文件)并保持在 NOMOUNT 状态。
  • OPEN:实例从 MOUNT 状态转到 OPEN 状态时,它会:- 检查控制文件知道的所有重做日志组是否都至少有一个成员。任何缺失的成员都会记录在预警日志中。

 

丢失了控制文件

执行以下步骤可在丢失了控制文件后进行恢复(只要至少保留了一个控制文件):

  1. 如果实例尚未失败,可使用 SHUTDOWN ABORT 关闭实例。
  2. 将剩余的一个控制文件复制到缺失文件的位置。如果介质故障是由于丢失了磁盘驱动器或控制器而造成的,则将剩余的一个控制文件复制到其它某个位置,然后通过更新实例的参数文件来指向新位置。也可从初始化参数文件中删除对缺失的控制文件的引用。记住,Oracle 建议在任何时间至少要保留两个控制文件。
  3. 启动实例。

 

维护控制文件

1 现有控制文件的位置及其名称是什么
提示 查询动态性能视图 V$CONTROLFILE 或 V$PARAMETER或者执行 SHOW PARAMETER 命令以显示控制文件的名称和位置
2 试着在无任何控制文件的情况下启动数据库 可以通过更改参数文件中的控制文件名称或只是更改控制文件名来模拟此操作 发生了什么提示 该问题没有提示
3 使用 DISK2 目录对现有的控制文件进行多元备份 并将新的控制文件命名为control02.con 确保 Oracle 服务器可以写入新的控制文件 例如 在UNIX 上使用 chmod 660 命令 确认两个控制文件都在使用

 

提示
关闭数据库
将现有的控制文件复制到 DISK2 目录下名为 control02.con 的新文件中
在 UNIX 上使用命令 chmod 660
修改参数文件以包含新文件名
启动数据库
查询动态性能视图 V$CONTROLFILE 或 V$PARAMETER 或使用 SHOW PARAMETER 命令确认两个控制文件都在使用

 

 

控制文件的使用

数据库的控制文件是成功启动和操作数据库所必需的小型二进制文件 每个控制文件只与一个 Oracle 数据库相关联。因为 Oracle 服务器在数据库使用的过程中会不断更新控制文件 所以控制文件必须在数据库打开时随时都可供写入 只有 Oracle 服务器能修改控制文件中的信息 DBA 或最终用户不能编辑控制文件。如果由于某些原因控制文件无法访问 则数据库将无法正确运行。

如果数据库控制文件的所有副本都丢失 则必须先恢复数据库 然后才能将其打开。

控制文件内容

  • 数据库名称取自初始化参数 DB_NAME 所指定的名称或 CREATE DATABASE 语句中所用的名称
  • 当创建数据库时会记录数据库标识
  • 当创建数据库时 还记录创建数据库的时间戳
  • 当在数据库中添加 重命名或删除数据文件或重做日志时 会更新相关数据文件和联机重做日志文件的名称和位置
  • 当添加或删除表空间时会更新表空间信息
  • 在日志切换过程中会记录日志历史信息
  • 归档日志的位置和状态会在归档时记录
  • 备份的位置和状态由恢复管理器实用程序记录
  • 在进行日志切换时记录当前日志序列号
  • 在建立检查点时记录检查点信息

控制文件由以下两种类型的部分组成

  • 可重用
  • 不可重用

可重用部分存储恢复管理器的信息 如备份数据文件名和备份重做日志文件
名 只有恢复管理器能够以循环方式重复使用该部分

 

多路复用控制文件

与联机重做日志文件相同 Oracle 允许同时打开并写入多个相同的控制文件
可以使用初始化参数 CONTROL_FILES 指定多达八个完全限定的控制文件名
称 Oracle 服务器在例程启动时创建和维护本参数中所列的全部文件
可以通过以下方法多路复用控制文件

  • 创建数据库时创建多个控制文件
  • 创建数据库后添加控制文件

随数据库创建控制文件 创建多个控制文件 数据库创建控制文件 最简便的方法是 在创建数据库时
将控制文件的名称包括在 CONTROL_FILES 初始化参数中
CONTROL_FILES = (/DISK1/control01.con,/DISK2/control02.con)
Oracle 服务器将创建该参数中列出的全部控制文件 在此参数中指定的文件名
应当包括完整的路径名 文件名规范与操作系统有关
如何添加控制文件 添加控制文件或更改控制文件的 如何添加控制文件 编号或位置

  1. 关闭数据库
  2. 使用操作系统命令复制当前的控制文件
  3. 将新的控制文件名添加到 CONTROL_FILES 参数中
  4. 启动数据库

控制文件的原则
• 您应该:
– 对控制文件进行多元备份
– 在 CONTROL_FILES 中包括完整的路径名
– 更改数据库结构后备份控制文件
• 控制文件:
– 大小由 CREATE DATABASE 关键字决定
– 具有可重用部分, Recovery Manager 的更新使之
可以扩展

多路复用的目的
若要防止控制文件的单点故障 我们强烈建议您多路复用控制文件 在不同的
物理磁盘上存储副本
如果某控制文件丢失 则使用该控制文件的副本重新启动例程
如果在不同磁盘上有当前控制文件的多个副本 则无须恢复数据库即可方便地
启动例程

CREATE DATABASE 关键字
在创建数据库过程中指定的关键字会影响控制文件的大小 当参数的值较大
时 这一点尤其明显 可能需要重新创建控制文件以更改一个或多个数据库限
制参数 该操作有可能增加或减小控制文件的大小
CREATE DATABASE 或 CREATE CONTROLFILE 命令中的下列关键字影响控
制文件的大小
• MAXLOGFILES
• MAXLOGMEMBERS
• MAXLOGHISTORY
• MAXDATAFILES
• MAXINSTANCES
必须创建新的控制文件 才可更改这些关键字所创建的空间大小
可重用部分可以扩展
当使用恢复管理器时 控制文件的可重用部分可以基于恢复管理器所要求的条
目数进行扩展
更改数据库结构后备份
由于控制文件记录数据库的物理结构 所以在更改数据库的物理结构后应当立
即备份控制文件
获取关于控制文件的信息
若要获得控制文件的位置和名称 请使用动态性能视图 V$CONTROLFILE

SQL> SELECT name FROM v$controlfile;
NAME
———————–
/DISK1/control01.con
/DISK2/control02.con
2 rows selected.
也可以使用 V$PARAMETER 视图 但是因为列长度的原因 控制文件名称可
能会被截断

若要获得控制文件不同部分的信息 查询
V$CONTROLFILE_RECORD_SECTION 动态性能视图
SQL> SELECT type, record_size, records_total, records_used
2 FROM v$controlfile_record_section
3 WHERE type=’DATAFILE’;
TYPE RECORD_SIZ RECORDS_TO RECORDS_US
————- ———- ———- ———-
DATAFILE 180 30 4
1 row selected.
RECORDS_TO 列指定分配给某特殊部分的记录数 例如 在我们的示例中您可以看到数据文件的最大数为 30 该数由 CREATE DATABASE 命令中的MAXDATAFILES 参数确定
其它几个动态性能视图中的信息从控制文件获取
• V$BACKUP
• V$DATAFILE
• V$TEMPFILE
• V$TABLESPACE
• V$ARCHIVE
• V$LOG
• V$LOGFILE
• V$LOGHIST
• V$ARCHIVED_LOG
• V$DATEBASE
• 其它

快速参考
上下文 参考
初始化参数 CONTROL_FILES
动态性能视图 V$CONTROLFILE
V$CONTROLFILE_RECORD_SECTION
V$PARAMETER
数据字典视图 无
命令 无
程序包过程和打包函数 无

Oracle PFILE/SPFILE 初始化参数文件

Oracle PFILE/SPFILE 初始化参数文件

初始化参数文件

要启动一个例程,Oracle 服务器必须读取初始化参数文件。

 

初始化参数文件

  • 文件中的条目专用于要启动的例程
  • 有两种类型的参数:

显式:文件中有一个条目

隐式:文件中没有条目,但假定取 Oracle 缺省值

  • 可存在多个初始化参数文件
  • 对文件中条目的更改的生效时间,取决于使用的初始化参数文件类型

静态参数文件 PFILE

永久参数文件 SPFILE

Oracle 服务器在启动例程时读取初始化参数文件。共有两种类型的初始化参数文件:

  • 静态参数文件 PFILE,一般名为 initSID.ora。
  • 永久参数文件 SPFILE,一般名为 spfileSID.ora。

初始化参数文件内容:

  • 例程参数列表
  • 与该例程相关联的数据库的名称
  • 系统全局区 (SGA) 的内存结构的分配
  • 如何处理已满的联机重做日志文件
  • 控制文件的名称和位置
  • 有关撤消段的信息

为在各种不同情况下优化性能,一个例程可有多个初始化参数文件。

初始化参数文件

使用 Oracle Enterprise Manager 查看初始化参数

从“OEM 控制台”(OEM Console):

  1. 导航到“数据库”(Databases) >“例程”(Instance) >“配置” (Configuration)。

2.从“常规”(General) 页选择“全部初始化参数”( All Initialization Parameters)。

 

 

PFILE initSID.ora

  • 文本文件
  • 使用操作系统编辑器进行修改
  • 手动进行修改
  • 所作更改在下次启动时生效
  • 仅在例程启动过程中打开
  • 缺省位置为 $ORACLE_HOME/dbs

PFILE

PFILE 是可使用标准的操作系统编辑器进行维护的文本文件。PFILE 在例程启动过程
中是只读的。如果文件发生修改,则必须关闭然后重新启动例程以使新的参数值生效。

缺省情况下,该文件位于 $ORACLE_HOME/dbs 目录中,文件名是 initSID.ora。

 

创建 PFILE  

cp init.ora $ORACLE_HOME/dbs/initdba01.ora

使用样本 init.ora 文件创

  • 样本文件由 Oracle Universal Installer 安装
  • 使用操作系统复制命令复制样本
  • 由数据库 SID 唯一标识

修改 initSID.ora
编辑参数
针对数据库要求

 

样本 init.ora 文件由 Universal Installer 在安装过程中创建。该样本 init.ora 文件可用于创建特定于某一例程的 initSID.ora。可使用文本编辑器修改 initSID.ora 文件中的参数。

 

PFILE 示例

 

# Initialization Parameter File: initdba01.ora
db_name              = dba01
instance_name        = dba01
control_files        = ( 		home/dba01/ORADATA/u01/control01dba01.ctl,
	home/dba01/ORADATA/u02/control01dba02.ctl)
db_block_size        = 4096
db_cache_size        = 4M
shared_pool_size     = 50000000
java_pool_size       = 50000000 			
max_dump_file_size   = 10240
background_dump_dest = /home/dba01/ADMIN/BDUMP
user_dump_dest       = /home/dba01/ADMIN/UDUMP
core_dump_dest       = /home/dba01/ADMIN/CDUMP
undo_management      = AUTO
undo_tablespace      = UNDOTBS
. . .


以这样的格式指定值:keyword=value(关键字 = 值)。
服务器为每个参数都设置了缺省值。根据参数的不同,缺省值可能与操作系统相关。
可以按任意顺序指定参数,但也存在例外。
注释行以 # 符号开头。
参数中如果包括字符文字,可将参数用双引号括起。
可以使用关键字 IFILE 使参数中包括其它文件。
如果使用的操作系统区分大小写,那么文件名也区分大小写。
如果有多个值,应该用圆括号将它们括起来,用逗号隔开。
注:请为参数的列出顺序指定一个标准:按字母顺序列出或按功能进行分组。PFILE 根据例程的不同而变化,不一定与上例相同。

 

PFILE 与SPFILE的差异

SPFILE spfileSID.ora

SPFILE

SPFILE 是 Oracle9i 中新增的二进制文件。该文件不能手动修改,且必须始终驻留在服务器端。创建该文件后,即由 Oracle 服务器进行维护。如果进行手动修改,SPFILE 将无效。SPFILE 具有对数据库进行永久更改的功能,不受关闭和启动操作的影响,它还提供自动调节记录在文件中的参数值的功能。使用 SPFILE,RMAN 可以支持初始化参数文件的备份,因为 SPFILE 驻留在服务器端。缺省情况下,它位于 $ORACLE_HOME/dbs 目录中,缺省名称为 spfileSID.ora。

 

  • 二进制文件
  • Oracle 服务器进行维护
  • 始终驻留在服务器端
  • 所做更改永久有效,不受关闭和启动的影响
  • 可以自行调节参数值
  • 使恢复管理器能够备份初始化参数文件

创建 SPFILE

SPFILE 是使用 CREATE SPFILE 命令从 PFILE 文件创建的。该命令需要具有 SYSDBA 权限才能执行。该命令可在例程启动之前或之后执行。

SQL> CREATE SPFILE [=’SPFILE-NAME’]

2 FROM PFILE[=’PFILE-NAME’]

其中:

  • SPFILE-NAME:要创建的 SPFILE 的名称
  • PFILE-NAME:用于创建 SPFILE 的 PFILE 的名称。PFILE 必须在服务器端可用

如果在语法中未包括 SPFILE-NAME 和 PFILE-NAME,Oracle 将使用缺省 PFILE 来生成 SPFILE(其名称由系统生成)。

SQL> CREATE SPFILE FROM PFILE;

 

从 PFILE 文件创建

CREATE SPFILE = $ORACLE_HOME/dbs/spfileDBA01.ora’ FROM PFILE = $ORACLE_HOME/dbs/initDBA01.ora;

 

其中
SPFILE-NAME:要创建的 SPFILE
PFILE-NAME:用于创建 SPFILE 的 PFILE
可在例程启动之前或之后执行

导出 SPFILE  

可将 SPFILE 的内容导出到 PFILE 中。

SQL> CREATE PFILE FROM SPFILE;

以上命令在服务器端创建了一个文本文件格式的 PFILE 。该命令可在例程启动之前或
之后执行。这样就提供了一种查看 SPFILE 并进行修改的简单方法:

  • 将 SPFILE 导出到 PFILE
  • 编辑 PFILE
  • 从编辑过的 PFILE 重新创建 SPFILE

将 SPFILE 导出到 PFILE 还可用作创建永久参数文件的备份的备用方法。

注:使用 Oracle9i,RMAN 还可备份永久参数文件。

V$SPPARAMETER

如上所述,查看 SPFILE 内的参数设置时有几个选项。V$SPPARAMETER 是显示和查看 SPFILE 的内容的另一种方法。

 

 

创建 SPFILE

使用 Oracle Enterprise Manager 创建 SPFILE

从 OEM 控制台:

  1. 从主菜单选择“对象”(Object) >“创建 spfile”(Create spfile)。

使用 Oracle Enterprise Manager 导出 SPFILE

从 OEM 控制台:

1.从主菜单选择“对象”(Object)>“创建 pfile”(Create pfile)。

 

SPFILE 示例

 

*.background_dump_dest=‘/home/dba01/ADMIN/BDUMP’
*.compatible='9.0.0'
*.control_files='/home/dba01/ORADATA/u01/ctrl01.ctl’ *.core_dump_dest=‘/home/dba01/ADMIN/CDUMP’
*.db_block_size=4096
*.db_name='dba01‘
*.db_domain=‘world’
*.global_names=TRUE
*.instance_name='dba01'
*.remote_login_passwordfile='exclusive‘
*.java_pool_size=50000000’
*.shared_pool_size=50000000
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS'
. . .

SPFILE 示例

PFILE 中的参数设置行上指定的注释保留在 SPFILE 中。所有其它注释都被忽略。

尽管 SPFILE 中的文本在 UNIX 中易于查看,但 SPFILE 是一个二进制文件,对
SPFILE 进行手动修改将使之无效。如果需要查看 SPFILE 的特定内容或进行一些
更改,可将 SPFILE 导出到 PFILE。

 

STARTUP 命令行为

优先顺序:

  • 使用命令 STARTUP 时,服务器端的 spfileSID.ora 用于启动例程。
  • 如果找不到 spfileSID.ora,则使用服务器端的缺省 SPFILE 来启动例程。
  • 如果找不到缺省 SPFILE,将使用服务器端的 initSID.ora 来启动例程。

指定的 PFILE 可覆盖缺省 SPFILE 来启动例程。

可在 PFILE 中包含一个定义以指示要使用 SPFILE。这是在非缺省位置使用 SPFILE
启动例程的唯一方法。要使用非缺省位置的 SPFILE 启动数据库,必须在 PFILE 中指
定 SPFILE=<完整路径和文件名>。

示例:SPFILE=$HOME/ADMIN/PFILE/$ORACLE_SID.ora。

 

 

优先顺序

  • spfileSID.ora
  • 缺省 SPFILE
  • initSID.ora
  • 缺省 PFILE
  • 指定的 PFILE 可覆盖优先顺序

STARTUP PFILE = $ORACLE_HOME/dbs/initDBA1.ora
PFILE 可指示要使用 SPFILE

SPFILE = /database/startup/spfileDBA1.ora

 

修改 SPFILE 中的参数

ALTER SYSTEM SET 命令用于更改例程参数的值。

ALTER SYSTEM SET parameter_name = parameter_value

[COMMENT ‘text’] [SCOPE = MEMORY|SPFILE|BOTH]

[SID= ‘sid’|’*’]

其中

parameter_name:要更改的参数的名称

parameter_value:要将参数更改为的值

COMMENT:添加在 SPFILE 中被更改的参数旁的注释

SCOPE:确定应在内存中、在 SPFILE 中还是同时在这两个位置进行更改

MEMORY:只能在当前运行的例程中更改参数值

SPFILE:只能在 SPFILE 中更改参数值

BOTH:在当前运行的例程和 SPFILE 中均可更改参数值

SID:标识要使用的 SPFILE 的 ORACLE_SID

‘sid’:更改 SPFILE 时使用的特定 SID

‘*’:使用缺省 SPFILE

 

  • 使用 ALTER SYSTEM 更改参数值
  • ALTER SYSTEM SET undo_tablespace = ‘UNDO2’;

  • 指定所做更改是临时的还是永久的
  • ALTER SYSTEM SET undo_tablespace = ‘UNDO2’ SCOPE=BOTH;

  • 删除或重置值
  • ALTER SYSTEM RESET undo_suppress_errors SCOPE=BOTH SID=’*’;

示例:

SQL>  SHOW PARAMETERS undo_suppress_errors

NAME                   TYPE        VALUE

———————- ———– ——-

undo_suppress_errors   boolean     FALSE

SQL> ALTER SYSTEM SET undo_suppress_errors = TRUE

2  COMMENT = ‘temporary testing’ SCOPE=BOTH

3  SID=‘DBA01’;

SQL> SHOW PARAMETERS undo_suppress_errors

NAME                   TYPE        VALUE

———————- ———– ——-

undo_suppress_errors   boolean     TRUE

ALTER SYSTEM RESET 命令用于删除或还原为缺省值。

SQL> ALTER SYSTEM RESET parameter_name [SCOPE = MEMORY|SPFILE|BOTH] [SID= ‘sid’|’*’]

示例:

SQL> ALTER SYSTEM RESET undo_suppress_errors

2  SCOPE=BOTH SID=‘dba01’;

从 SPFILE 中删除一个参数有以下几种方法:

  • 将参数重设为缺省值来模拟使用 ALTER SYSTEM SET 的删除操作。
  • 使用 CREATE SPFILE FROM PFILE 重新创建 SPFILE。
  • 使用 ALTER SYSTEM RESET 从 SPFILE 删除参数。

 

修改 SPFILE 中的参数(续

使用 Oracle Enterprise Manager 修改 SPFILE 配置

从 OEM 控制台:

1.导航到“数据库”(Databases) >“例程”(Instance)。

2.单击“配置”(Configuration)。

  1. 在“常规”(General) 页上,单击“全部初始化参数”( All Initialization Parameters)。
  2. 在参数值栏中修改参数 。
  3. 单击“确定”(OK)。

Oracle公司的创始人后来都去干嘛了?

这篇文章 主要摘译自 http://www.businessinsider.com/whatever-happened-to-oracles-founders-in-this-iconic-photo-2012-8

随着Oracle甲骨文CEO 70岁的Larry Ellison辞去CEO职位,甲骨文的未来将充满未知和新局面。 来回顾一下这家公司的过往,最初的创始人。

co-founders-of-oracle

 

 

这张拍摄于1978年的照片,对于大众而言是少数能帮助我们了解甲骨文公司在起步阶段情况的历史资料。

拍摄这张照片的时候,公司甚至还不叫甲骨文Oracle。

 左起为Ed Oates,Bruce Scott,Bob Miner,Larry Ellison(高个不戴眼镜)

拉里·埃里森从 Ed Oates(甲骨文的另一个联合创始人)那里获得了一份IBM的研究杂志,这份杂志上介绍的SYSTEM R系统引起了拉里的兴趣。一开始拉里希望让Oracle的产品能与SYSTEM R相兼容,但IBM封闭守旧的做法让这种想法泡汤了。

 

 

到了70年代末的1977年,拉里和Bob Miner 以及Ed Oates创立了软件开发实验室(Software Development Laboratories (SDL)), 1979年更名为 Relational Software, Inc. (RSI), 到1982年更名为Oracle Systems Corporation沿用至今,1986年Oracle上市时年收入暴增到5500万美元,甲骨文传奇从此为世人熟识。(https://www.askmac.cn/archives/maclean-write-oracle-basic.html)  

 

这四位创始人当初也难以料到Oracle公司竟会发展为市值数百亿美元的软件帝国,世界上最大的数据库软件供应商。 askmac.cn

 

 

 

ed-oates-the-project-manager

Ed Oates, 当时的项目经理

 

1996年ED Oates从Oracle公司退休,虽然之前他表达过当公司拥有10000名员工时就会退休的意愿,但显然当时oracle的扩展速度过于迅速了,

这导致Ed退休的时候Oracle已经拥有20000明员工了。

后来他买了一家高端家庭影院专卖店,为像乔布斯和Larry Ellison这样的人提供高端音响,在1999年他出售了这家店。

 

在oracle的最初岁月,Ed Oates负责项目管理

 

 

 

 

 

bruce-scott-the-first-employee

 

Bruce Scott, 第一位雇员

 

Bruce scott对中国用户来说更为熟悉,显然是因为scott/tiger的组合,每一家公司都有一个叫scott的人。

 

虽然大多数人以为Bruce scott是甲骨文的联合创始人,但实际的情况是scott只是Oracle的第一位雇员。如果算上创始人也算employee 雇员的话,那么Scott是第四位雇员。

Scott是Oracle数据库前三个版本(2、3、4,没有Version 1)的主要设计人员之一。

Scott在1982年离开了oracle,帮助另一位Oracle前员工成立另一家公司Centura Software。之后他参与创始了另一家数据库公司 PointBase, PointBase 被 DataMirror收购了,而DataMirror又被IBM收购。 讽刺的是在Oracle weblogic 软件中还有欧诺个到PointBase。

 

 

 

 

 

 

bob-miner-the-technical-genius

 

Bob Miner, 技术天才

 

Bob Miner是oracle数据库的主设计师,他在公司的大部分职业生涯都花在产品设计和开发上了。

如果说Larry是甲骨文的有冲劲的大脑,那么Miner是甲骨文心脏。他是受人爱戴的高管,其到了平衡Larry对公司影响的作用。他希望员工能不因为通宵工作,而忽略了家人。

 

1993年他由于一种罕见的肺癌去世,享年52岁。

 

 

 

 

 

larry-ellison-the-hard-driving-business-man

 

Larry Ellison, 有冲劲的商业天才

 

担当了37年的CEO后70岁的Larry在最近宣布主动卸任CEO,将在今后担任CTO的角色。其保持着担任科级公司最长时间CEO的历史记录。

他是世界上最富有的人之一,达到 $51 billion。

在过去的几年里他把注意力转到其他事情上,如购买了大量的夏威夷小岛拉奈,将该岛屿改造成生态友好的乐园和度假者的天堂。

2014年Oracle技术控 Orcl-Con活动报名

Create your free online surveys with SurveyMonkey , the world’s leading questionnaire tool.

诗檀软件成功使用PRM为某西南电信运行商恢复多张千万级别表

诗檀软件成功使用PRM为某西南电信运行商恢复多张千万级别表,由于工作人员误操作导致数张大表被truncate,通过PRM-DUL的快速恢复truncate截断功能很快将绝大部分数据还原出来。

 

 

ORACLE PRM是诗檀软件独立研发的ORACLE数据库灾难恢复软件,其具有全程图形化界面、简单高效等特点。

欢迎下载使用ORACLE PRM。 下载地址:http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

PRM用户使用手册。http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C%20v0.3.pdf

 

 

 

 

 

 

【Oracle数据库恢复】ORA-00600: [16513], [1403], [20]一例

某国内数据库系统由于存储故障导致ASM diskgroup损坏,后续恢复过程中在open  database阶段遇到了ORA-00600: [16513], [1403], [20]:ORA-00600: internal error code, arguments: [16513], [1403], [20], [], [], [], [], []

 


ORA-00600: internal error code, arguments: [16513], [1403], [20], [], [], [], [], []
Current SQL statement for this session:
alter database open
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ssd_unwind_bp: unhandled instruction at 0x76add1 instr=f
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?
                                                   7FFF04273960 ? 7FFF042739C0 ?
                                                   7FFF04273900 ? 000000000 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?
                                                   7FFF04273960 ? 7FFF042739C0 ?
                                                   7FFF04273900 ? 000000000 ?
ksfdmp()+63          call     ksedmp()             000000003 ? 000000001 ?
                                                   7FFF04273960 ? 7FFF042739C0 ?
                                                   7FFF04273900 ? 000000000 ?
kgeriv()+176         call     ksfdmp()             006AE9A20 ? 000000003 ?
                                                   7FFF04273960 ? 7FFF042739C0 ?
                                                   7FFF04273900 ? 000000000 ?
kgesiv()+119         call     kgeriv()             006AE9A20 ? 00DAC5398 ?
                                                   000000000 ? 2B749C907FA0 ?
                                                   7FFF04273900 ? 000000000 ?
ksesic2()+215        call     kgesiv()             006AE9A20 ? 00DAC5398 ?
                                                   000004081 ? 000000002 ?
                                                   7FFF042748A0 ? 000000000 ?
kqdpts()+351         call     ksesic2()            006AE9A20 ? 000000000 ?
                                                   00000057B ? 000000000 ?
                                                   000000014 ? 000000000 ?
kqrlfc()+314         call     kqdpts()             55DF9CE78 ? 000000000 ?
                                                   00000057B ? 000000000 ?
                                                   000000014 ? 000000000 ?
kqlbplc()+153        call     kqrlfc()             55DF9CE78 ? 7FFF04274BC0 ?
                                                   00000057B ? 000000000 ?
                                                   000000014 ? 000000000 ?
kqlblfc()+263        call     kqlbplc()            000000000 ? 7FFF04274BC0 ?
                                                   00000057B ? 000000000 ?
                                                   000000014 ? 000000000 ?
adbdrv()+58009       call     kqlblfc()            000000000 ? 7FFF0427B450 ?
                                                   00000057B ? 000000000 ?
                                                   000000014 ? 000000000 ?
opiexe()+13745       call     adbdrv()             000000000 ? 7FFF0427B450 ?
                                                   536FEDDF8 ? 000000000 ?
                                                   000000014 ? 000000000 ?
opiosq0()+3398       call     opiexe()             000000004 ? 000000000 ?
                                                   7FFF0427C60C ? 000000001 ?
                                                   000000014 ? 000000000 ?
kpooprx()+318        call     opiosq0()            000000003 ? 00000000E ?
                                                   7FFF0427C938 ? 0000000A4 ?
                                                   000000000 ? 600000013 ?
kpoal8()+783         call     kpooprx()            7FFF0427FB1C ? 7FFF0427DB48 ?
                                                   000000013 ? 000000001 ?
                                                   000000000 ? 600000013 ?
opiodr()+1184        call     kpoal8()             00000005E ? 000000017 ?


ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0cdc.c2a516cc):

ORA-00600: internal error code, arguments: [16513], [1403], [20], [], [], [], [], []
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [16513], [1403], [20], [], [], [], [], []
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704



该open database 失败时的ORA-00600: [16513]错误并不常见,根据其stack call看:kqrlfc=>kqdpts=>报错

kqrlfc =>KQR Kernel SQL Row cache management component Load Fixed Cache 代表加载基本row cache字典缓存
kqdpts => Kernel Query Dictionary Patch Time Stamps

可以看到该16513 属于 16500 dict/rowcache this layer provides support to load / cache Oracle’s dictionary in memory in the library cache; 即问题指向在加载字典缓存时oracle遇到了严重的问题。

该问题后续通过手动patch数据字典来绕过了。

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638   QQ号:47079569    邮箱:service@parnassusdata.com

 

沪ICP备14014813号-2

沪公网安备 31010802001379号