2004年11月19日

概要
本文讨论了 Microsoft Exchange Server 2003 中引入的一些安全设置更改。Exchange 2003 包括了许多与安全有关的更新和更改,目的是为了使它比以前的 Microsoft Exchange Server 版本更安全。
更多信息

组织级设置
• 禁用了 Microsoft Outlook Mobile Access 浏览功能
启用或禁用该 Microsoft 浏览功能的设置是在 Exchange 2003 目录林准备操作(当运行 setup /forestprep 命令时)过程中在整个 Exchange Server 组织中设置的。默认情况下,在安装 ForestPrep 部分期间,Outlook Mobile Access 浏览功能处于禁用状态。但是,如果以前启用了 Outlook Mobile Access 浏览功能,Exchange 2003 的 forestprep/reinstall 命令可使其保持启用状态。

这意味着,在您运行 setup /forestprep 从 Microsoft Exchange 2000 Server 升级时,不会启用 Outlook Mobile Access 浏览功能。但是,如果已经启用了该浏览功能,在您运行 setup /forestprep 从 Exchange 2003 的旧版本或 beta 版进行升级时,该功能会保持启用状态。

确定是否已启用 Outlook Mobile Access 浏览功能:1. 启动“Exchange 系统管理器”。
2. 在您的组织下,展开“全局设置”,右键单击“移动服务”,然后单击“属性”。
3. 在“Outlook Mobile Access”下,如果“启用 Outlook Mobile Access”复选框处于选中状态,说明已启用 Outlook Mobile Access 浏览功能。如果此复选框处于未选中状态,说明未启用 Outlook Mobile Access 浏览功能。
注意:默认情况下,在安装过程中不禁用“Exchange ActiveSync”和“始终使用最新通知”设置。

• 整个 Exchange 组织中最大邮件大小限制设置为 10 兆字节
在组织中安装第一台 Exchange 2003 计算机时,如果以前没有配置“发送邮件大小”和“接收邮件大小”选项的值,这两个选项都会被设置为最大 10,240 千字节(10 兆字节)。这意味着,在从 Microsoft Exchange 2000 Server 升级到 Exchange 2003 或在重新安装 Exchange 2003 时,如果尚未配置另一设置,全局邮件大小限制就会被设置为 10 兆字节。如果已经配置了邮件大小限制,则会保留该值。查看邮件大小限制:1. 启动“Exchange 系统管理器”。
2. 在您的组织下,展开“全局设置”,右键单击“邮件传递”,然后单击“属性”。
3. 单击“默认”选项卡。
有关在配置邮件大小限制时可能遇到的问题的其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中的相应文章:
298572 XADM:An E-Mail Message That Is Larger Than the Outgoing or the Incoming Message Size Limit Is Not Delivered
如果您将邮件大小限制配置得过大,则可能会遇到很大的电子邮件导致 Exchange 2003 暂时停止响应的问题。例如,如果发送一封 81 兆字节的电子邮件,则 Exchange 2003 可能会暂时停止响应。
• 删除了“任何人”和“匿名登录”安全组的创建顶级公用文件夹的权限
Exchange 2003 目录林准备操作(在运行 setup /forestprep 命令时)会从 Exchange 组织容器中删除“任何人”和“匿名登录”组的“创建顶级公用文件夹”的“允许”权限。其他访问控制项 (ACE) 没有变化。有关在组织中安装 Exchange 2000 Server 时可能出现的问题的其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中的相应文章:
822576 “Allow Create Top Level Public Folder” Access Control Entry for the Exchange Organization Container Unexpectedly Includes the Everyone and the Anonymous Logon Groups  

服务器级设置
• 在创建新的 Exchange 虚拟服务器时不自动创建 POP3、IMAP4 和 NNTP 群集资源

在旧版本的 Microsoft Exchange 中,当创建 Exchange 虚拟服务器时,会同时创建“邮局协议 3”(POP3)、“Internet 邮件访问协议 4”(IMAP4) 和“网络新闻传输协议”(NNTP) 群集资源。由于在默认 Exchange 2003 安装中不启用这些服务,因此这些服务不会自动创建。要创建这些资源,您必须手动启用它们,然后在群集节点上启动相应的服务。然后,您可以通过使用“群集管理器”实用工具来创建资源。

注意 升级现有的 Exchange 虚拟服务器不会更改这些群集资源。

• 在 Exchange 2003 计算机上拒绝“Domain Users”安全组成员的“允许在本地登录”权限

默认情况下,在安装 Exchange 2003 时,拒绝“Domain Users”组的成员对该计算机的“允许在本地登录”权限。默认情况下,“Domain Users”组的成员不能在本地登录到域控制器。但是,此限制的范围会扩大,从而包括安装了 Exchange 2003 的成员服务器。此更改适用于 Exchange 2003 的新安装、升级和重新安装。“Backup Operators”组、“Administrators”组和那些权限高于其他组的其他安全组的成员仍然可以在本地进行登录。此更改是通过在 Exchange 2003 安装过程中从“允许在本地登录”策略中删除本地(内置)“Users”安全组完成的。查看此策略:1. 单击“开始”,单击“运行”,在“打开”框中键入 gpedit.msc,然后单击“确定”。
2. 在“计算机配置”下,依次展开“Windows 设置”、“安全设置”、“本地策略”,然后单击“用户权限分配”。
3. 在右窗格中,双击“允许在本地登录”。
4. 查看在“允许在本地登录”框中显示的用户和组。
 
• 在安装 Exchange Server 2003 时会从 Program Files 文件夹复制访问控制项

在安装 Exchange 2003 作为独立服务器或在群集节点上安装 Exchange 2003 时,系统会从父级 Program Files 文件夹复制对 Exchange 安装文件夹(默认情况下,它们位于 C:\Program Files\Exchsrvr 文件夹中)的操作权限。如果将 Exchange 2003 安装到 Program Files 文件夹以外的位置,这些权限会被从 Program Files 文件夹复制到 Exchange 安装文件夹。因此,如果将“允许在本地登录”权限授予非管理员组的用户(例如“Domain Users”安全组的成员),这些用户就可以访问 Exchsrvr 安装文件夹中的敏感信息。例如,他们也许能够查看 Mailroot\vsi 1\BadMail、PickUp 或 Queue 文件夹中的敏感信息。

注意 在安装 Microsoft Mobile Information Server (MIS) 时也存在此问题。服务器上允许在本地登录并且已通过身份验证的用户可以查看 PickUp 文件夹中的信息。

• 全局事件对象具有空的自由访问控制列表

安全描述符是使用空的自由访问控制列表创建的;一个安全属性类被配置为指向所创建的安全描述符。然后,将使用这些安全属性创建事件。由于使用了空的自由访问控制列表,因此如果将“允许在本地登录”权限授予非管理员组的用户(例如“Domain Users”安全组的成员),则恶意用户有可能更改对象的自由访问控制列表并干涉对它的使用。
 
• 服务器上的 POP3、IMAP4 和 NNTP 服务被禁用

默认情况下,在新安装的 Exchange 2003 中,Exchange POP3 服务、IMAP4 服务和“网络新闻传输协议”(NNTP) 服务被设置为“禁用”。在升级到 Exchange 2003 或重新安装 Exchange 2003 时,将保留这些服务的原有状态。  

存储组级设置

• 每个公用文件夹存储的最大公用文件夹项目大小限制设置为 10 兆字节

在安装 Exchange 2003 时,“项目大小最大值 (KB)”选项设置为 10,240 千字节(10 兆字节)。如果您升级到 Exchange 2003 或重新安装 Exchange 2003,则仅当没有为此选项分配其他值时,才将其设置为 10,240。如果在升级到或重新安装 Exchange 2003 之前配置了此选项,则不更改以前的值。此设置还会影响通过使用“Exchange 系统管理器”新建的 MAPI 和应用程序公用文件夹存储区。“项目大小最大值 (KB)”存储在 Microsoft Active Directory 目录服务中每个公用文件夹存储对象的“messageSizeLimit”属性中。  

协议级设置
• POP3 和 IMAP4 Exchange 虚拟服务器的基本身份验证被启用


默认情况下,在新安装中会为 POP3 和 IMAP4 Exchange 虚拟服务器实例启用基本身份验证 (Basic_Auth)。但是,在升级到 Exchange 2003 时,会遇到以下问题:• 在 Exchange 后端服务器上,Exchange POP3 和 IMAP4 虚拟服务器实例中的可用身份验证方法不发生变化。

• 在 Exchange 前端服务器上,Exchange POP3 和 IMAP4 虚拟服务器实例中的身份验证方法配置如下:• 匿名身份验证 (Anon_Auth):禁用
• 基本身份验证 (Basic_Auth):启用
• 集成 Windows 身份验证 (NT_Auth):禁用

 
这种配置适用于默认的 Exchange 虚拟服务器实例以及使用“Exchange 系统管理器”实用工具创建的虚拟服务器实例。但是,升级到 Exchange 2003 之前创建的 Exchange 虚拟服务器实例或在重新安装 Exchange 2003 之前创建的虚拟服务器实例不会被修改。如前所述,Exchange 前端服务器是一个例外。

• Exchange NNTP 虚拟服务器的基本身份验证被启用

默认情况下,在新安装中为 Exchange NNTP 虚拟服务器实例启用基本身份验证 (Basic_Auth)。默认 Exchange NNTP 虚拟服务器的身份验证方法如下:• 匿名身份验证 (Anon_Auth):禁用
• 基本身份验证 (Basic_Auth):启用
• 集成 Windows 身份验证 (NT_Auth):启用
当升级到 Exchange 2003 或重新安装 Exchange 2003 时,将始终修改默认的 NNTP 虚拟服务器实例。在升级到或重新安装 Exchange 2003 的过程中不修改创建的其他 Exchange NNTP 虚拟服务器实例。此外,如果删除 Exchange 2003,则将禁用集成的 Windows 身份验证 (NT_Auth)。之所以如此是因为“网络新闻传输协议”(NNTP) 是一个 Windows 组件,而不是 Exchange 2003 的一部分。

2004年11月15日

我的数据库是 NOARCHIVE 方式的
一次在数据库关闭之后错误的删除了所有的log文件(没有备份),
这样数据库就打不开了。
请问我应当用什么方发恢复 log 文件?


方法:


1.STARTUP MOUNT;
2.RECOVER DATABASE UNTIL CANCEL;
3.ALTER DATABASE OPEN RESETLOGS;

* 软件环境:
             1、Windows NT4.0+ORACLE 8.0.4
             2、ORACLE安装路径为:C:\ORANT
             3、服务器A、服务器B,均装有NT 4.0中文版
  
     * 实现方法:
             1. 假设A地址192.1.1.1,B地址192.1.1.2
  
             2. A、B上配置好TCP/IP,互相Ping通。
  
             3. 配置init.ora文件,若global_name = true的话,database link 的名字必须同远程机的实例名相同,
  
               为简便起见,请将global_name 设为 false。
  
             4. 在服务器上配置tnsnames.ora,将Remote机器的地址(IP)信息加入本地的tnsnames.ora
  
               A服务器:
               TNSA_B =
                (DESCRIPTION =
                 (ADDRESS_LIST =
                   (ADDRESS =
                    (COMMUNITY = tcp.world)
                    (PROTOCOL = TCP)
                    (Host = 192.1.1.2)
                    (Port = 1521)
                   )
                 )
                 (CONNECT_DATA = (SID = ORCL)
                 )
                )
  
               B服务器:
               TNSB_A =
                (DESCRIPTION =
                 (ADDRESS_LIST =
                   (ADDRESS =
                    (COMMUNITY = tcp.world)
                    (PROTOCOL = TCP)
                    (Host = 192.1.1.1)
                    (Port = 1521)
                   )
                 )
                 (CONNECT_DATA = (SID = ORCL)
                 )
                )
  
             5. 在 SQL*Plus 或其它工具中创建数据库链接
  
               A服务器:create public database link A_TO_B connect to tmp identified by tmp using ‘TNSA_B’;
  
               B服务器:create public database link B_TO_A connect to tmp identified by tmp using ‘TNSB_A’;
  
               说明:
               tmp是一个临时用户,A服务器、B服务器上均有,它的作用是提供链接的目的地,
               假如:
               B服务器上有user1、user2、tmp三个用户,user1和user2把他们想要对外公开的表的权限授给tmp用户,
               那么,所有能通过database link连接到tmp用户上的人就可以直接访问user1、user2上的已授权表了。
  
             6. 建立database link以后,请用这种格式select * from table_name@database_link_name 的方式访问
  
               如:在A服务器上想访问B服务器上user1用户table1表的内容(A到B的连接为A_TO_B),则
  
               SQL> select * from table1@A_TO_B;
  
             7. 如果Oracle版本为7.3,则数据库联接写法如下:
  
               A服务器:create public database link A_TO_B connect to tmp identified by tmp using ‘t:192.1.1.2:orcl’;
  
               B服务器:create public database link B_TO_A connect to tmp identified by tmp using ‘t:192.1.1.1:orcl’;

2004年11月01日

损失所有control文件

SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> host
Microsoft Windows 2000 [Version 5.00.2195]
(C) 版权所有 1985-2000 Microsoft Corp.

C:\>del D:\oracle9\oradata\nbxtdb\*.ctl

C:\>exit

SQL> startup
ORACLE 例程已经启动。

Total System Global Area  378608760 bytes
Fixed Size                   453752 bytes
Variable Size             167772160 bytes
Database Buffers          209715200 bytes
Redo Buffers                 667648 bytes
ORA-00205: ?????????????????????

SQL> shutdown immediate
ORA-01507: ??????

ORACLE 例程已经关闭。
SQL> @E:\orahotbak\controltrace.sql

–controltrace.sql文件是使用alter database backup control file to trace;他产生的文件在
–D:\oracle9\admin\nbxtdb\udump 下,选取其中的创建sql生成controltrace.sql,然后用sys用户
–运行即可。

ORACLE 例程已经启动。

Total System Global Area  378608760 bytes
Fixed Size                   453752 bytes
Variable Size             167772160 bytes
Database Buffers          209715200 bytes
Redo Buffers                 667648 bytes

控制文件已创建

ORA-00283: ??????????
ORA-00264: ?????

 

系统已更改。

数据库已更改。

SQL> conn test/test
已连接。
SQL> select * from test_excel
  2  ;

事故编码             发生时间   类型
——————– ———- ——————–
23                   22-2月 -08 test1
25                   22-2月 -08 test2
26                   22-2月 -08 test3
2                    24-11月-03 车辆伤害
12                   07-2月 -03 高处坠落
13                   21-10月-03 高处坠落
1                    22-3月 -02 22
28                   28-3月 -09 test5
29                   22-1月 -10 test6

已选择9行。

SQL>

SQL> insert into test_excel values(‘28′,to_date(‘2009-03-28′,’yyyy-mm-dd’),’tes
5′);

已创建 1 行。

SQL> conn /as sysdba
已连接。
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> host
Microsoft Windows 2000 [Version 5.00.2195]
(C) 版权所有 1985-2000 Microsoft Corp.
–改例子为了简单,只模拟丢失了一个数据文件,改方法可以实现包括系统数据库文件在内的恢复

C:\>del D:\oracle9\oradata\nbxtdb\NBXTTP.ORA

C:\>exit

SQL> startup
ORACLE 例程已经启动。

Total System Global Area  378608760 bytes
Fixed Size                   453752 bytes
Variable Size             167772160 bytes
Database Buffers          209715200 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件 9 – 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 9: ‘D:\ORACLE9\ORADATA\NBXTDB\NBXTTP.ORA’

SQL> select * from v$recover_file;

     FILE# ONLINE  ONLINE_
———- ——- ——-
ERROR                                                                CHANGE#
—————————————————————– ———-
TIME
———-
         9 ONLINE  ONLINE
FILE NOT FOUND                                                             0

 

SQL> host
Microsoft Windows 2000 [Version 5.00.2195]
(C) 版权所有 1985-2000 Microsoft Corp.

C:\>copy E:\orahotbak\NBXTTP.ORA D:\oracle9\oradata\nbxtdb
已复制         1 个文件。

C:\>exit

SQL> recover database;
ORA-00279: 更改 356135 (在 05/27/2004 20:50:36 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:\ORACLE9\ORADATA\NBXTDB\ARCHIVE\ARC00100100.ARC
ORA-00280: 更改 356135 对于线程 1 是按序列 # 100 进行的

指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 更改 356192 (在 05/27/2004 20:50:40 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:\ORACLE9\ORADATA\NBXTDB\ARCHIVE\ARC00100101.ARC
ORA-00280: 更改 356192 对于线程 1 是按序列 # 101 进行的
ORA-00278: 此恢复不再需要日志文件
‘D:\ORACLE9\ORADATA\NBXTDB\ARCHIVE\ARC00100100.ARC’

ORA-00279: 更改 356702 (在 05/27/2004 20:58:10 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:\ORACLE9\ORADATA\NBXTDB\ARCHIVE\ARC00100102.ARC
ORA-00280: 更改 356702 对于线程 1 是按序列 # 102 进行的
ORA-00278: 此恢复不再需要日志文件
‘D:\ORACLE9\ORADATA\NBXTDB\ARCHIVE\ARC00100101.ARC’

已应用的日志。
完成介质恢复。
SQL> alter database open;

数据库已更改。

SQL> conn test/test
已连接。
SQL> select * from test_excel;

事故编码             发生时间   类型
——————– ———- ——————–
23                   22-2月 -08 test1
25                   22-2月 -08 test2
26                   22-2月 -08 test3
2                    24-11月-03 车辆伤害
12                   07-2月 -03 高处坠落
13                   21-10月-03 高处坠落
1                    22-3月 -02 22
28                   28-3月 -09 test5

已选择8行。

SQL>

归档方式下丢失非当前联机日志

C:\>del D:\oracle9\oradata\nbxtdb\REDO03.LOG

C:\>exit

SQL> startup
ORACLE 例程已经启动。

Total System Global Area  378608760 bytes
Fixed Size                   453752 bytes
Variable Size             167772160 bytes
Database Buffers          209715200 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
ORA-00313: 无法打开日志组 3 (线程 1) 的成员
ORA-00312: 联机日志 3 线程 1: ‘D:\ORACLE9\ORADATA\NBXTDB\REDO03.LOG’

SQL>  select group#,sequence#,archived,status from v$log;

    GROUP#  SEQUENCE# ARC STATUS
———- ———- — —————-
         1        106 NO  CURRENT
         2        104 YES INACTIVE
         3        105 YES INACTIVE
–发现3是非当前日志,并且已经归档

SQL> alter database clear logfile group 3;

–如果还没有归档则使用:alter database clear unarchived logfile group 3;

数据库已更改。

SQL> alter database open;

数据库已更改。

–如果损坏的是非当前联机日志文件,一般只需要clear就可以重建改日志文件,但是如果数据库处于归档状态
–但日志还没有归档,则需要强性clear。

–建议clear后,特别是强行clear后做一次数据库的全备份

–改方法适合于归档和非归档数据库

 

版权声明:CSDN是本Blog托管服务提供商。如本文牵涉版权问题,CSDN不承担相关责任,请版权拥有者直接与文章作者联系解决。

posted on 2004年06月28日 9:11 PM

改方法不能实现系统表空间的恢复

SQL> insert into test_excel values(‘26′,to_date(‘2008-02-22′,’yyyy-mm-dd’),’test
3′);

已创建 1 行。

SQL> alter system switch logfile;

系统已更改。

SQL> alter system switch logfile;

系统已更改。
SQL> conn /as sysdba
已连接。
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> host
Microsoft Windows 2000 [Version 5.00.2195]
(C) 版权所有 1985-2000 Microsoft Corp.

C:\>del D:\oracle9\oradata\nbxtdb\NBXTTP.ORA
成功删除NBXTTP.ORA

C:\>exit

SQL> startup
ORACLE 例程已经启动。

Total System Global Area  378608760 bytes
Fixed Size                   453752 bytes
Variable Size             167772160 bytes
Database Buffers          209715200 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件 9 – 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 9: ‘D:\ORACLE9\ORADATA\NBXTDB\NBXTTP.ORA’

SQL> select * from v$recover_file;

     FILE# ONLINE  ONLINE_
———- ——- ——-
ERROR                                                                CHANGE#
—————————————————————– ———-
TIME
———-
         9 ONLINE  ONLINE
FILE NOT FOUND                                                             0

 

SQL> alter database datafile 9 offline drop;

数据库已更改。

SQL> alter database open;

数据库已更改。

SQL> host
Microsoft Windows 2000 [Version 5.00.2195]
(C) 版权所有 1985-2000 Microsoft Corp.

C:\>copy E:\orahotbak\NBXTTP.ORA D:\oracle9\oradata\nbxtdb
已复制         1 个文件。

C:\>exit

SQL> recover datafile 9;
ORA-00279: 更改 356135 (在 05/27/2004 20:50:36 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:\ORACLE9\ORADATA\NBXTDB\ARCHIVE\ARC00100100.ARC
ORA-00280: 更改 356135 对于线程 1 是按序列 # 100 进行的

指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 更改 356192 (在 05/27/2004 20:50:40 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:\ORACLE9\ORADATA\NBXTDB\ARCHIVE\ARC00100101.ARC
ORA-00280: 更改 356192 对于线程 1 是按序列 # 101 进行的
ORA-00278: 此恢复不再需要日志文件
‘D:\ORACLE9\ORADATA\NBXTDB\ARCHIVE\ARC00100100.ARC’

ORA-00279: 更改 356702 (在 05/27/2004 20:58:10 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:\ORACLE9\ORADATA\NBXTDB\ARCHIVE\ARC00100102.ARC
ORA-00280: 更改 356702 对于线程 1 是按序列 # 102 进行的
ORA-00278: 此恢复不再需要日志文件
‘D:\ORACLE9\ORADATA\NBXTDB\ARCHIVE\ARC00100101.ARC’

已应用的日志。
完成介质恢复。
SQL> alter database datafile 9 online;

数据库已更改。

SQL> conn test/test;
已连接。
SQL> select * from test_excel;

事故编码             发生时间   类型
——————– ———- ——————–
23                   22-2月 -08 test1
25                   22-2月 -08 test2
26                   22-2月 -08 test3
2                    24-11月-03 车辆伤害
12                   07-2月 -03 高处坠落
13                   21-10月-03 高处坠落
1                    22-3月 -02 22

已选择7行。

SQL>

损坏一个控制文件

SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> host
Microsoft Windows 2000 [Version 5.00.2195]
(C) 版权所有 1985-2000 Microsoft Corp.

C:\>del D:\ORACLE9\ORADATA\NBXTDB\CONTROL01.CTL

C:\>exit

SQL> startup
ORACLE 例程已经启动。

Total System Global Area  378608760 bytes
Fixed Size                   453752 bytes
Variable Size             167772160 bytes
Database Buffers          209715200 bytes
Redo Buffers                 667648 bytes
ORA-00205: ?????????????????????

SQL> shutdown immediate
ORA-01507: ??????

ORACLE 例程已经关闭。
SQL> host
Microsoft Windows 2000 [Version 5.00.2195]
(C) 版权所有 1985-2000 Microsoft Corp.

C:\>copy D:\ORACLE9\ORADATA\NBXTDB\CONTROL02.CTL D:\ORACLE9\ORADATA\NBXTDB\CONTR
OL01.CTL
已复制         1 个文件。

C:\>startup
’startup’ 不是内部或外部命令,也不是可运行的程序
或批处理文件。

C:\>exit

SQL> startup
ORACLE 例程已经启动。

Total System Global Area  378608760 bytes
Fixed Size                   453752 bytes
Variable Size             167772160 bytes
Database Buffers          209715200 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
数据库已经打开。
SQL>

–1,因为数据库中所有的控制文件都是一样的,只需要简单copy一个就可以了
–2,建议镜相控制文件在不同的磁盘上
–3,建议多做控制文件备份,长期保留一份由alter database backup control file to trace产生的控制文件的文本备份。

执行一个远程更新的job,发现老报“等待 INSERT_GZ_CALLCENTRE_DATA 解锁”超时错误,
于是查看user_jobs:
select job from user_jobs;

       JOB
———-
        80
        81
        75

再查看dba_jobs_running 表:
SID        JOB   FAILURES LAST_DATE  LAST_SEC         THIS_DATE
———- ———- ———- ———- —————- ———-
THIS_SEC           INSTANCE
—————- ———-
         7         67

         8         68

        49         72

上面的67,68,72 都是已经被删掉的任务,但是居然还是在运行,从而初步估计是死锁的问题。
解决方法如下:
首先去v$session 视图查找sid为 7,8,49 的会话信息:
select sid,paddr,status ,username from v$session where sid=7;

7,A60C8C,active,greatwall

用户名和执行job的用户一致,确定是该用户,再查找v$process 视图,找出对应的后台进程:
select spid from v$process where addr=’A60C8C‘;

然后杀掉该进程:

kill spid;
在linux上有可能杀不掉,使用kill -9 spid即可;使用ps -ef|grep oracle,其中oracle是用户 查看进程是否还在(查看PID的值)

注意:还有一种结束会话的方法:alter system kill session ‘sid,serial#’,但是,
这些session的状态又变成了killed,然后就由Pmon进程来慢慢进行清除了,此时并没有解锁,所以当我
用这种方法的时候发现从v$session中查到的会话状态变成killed,
然而想试着删除INSERT_GZ_CALLCENTRE_DATA的时候依然报同样的错。

如果oracle装在windows下,可以用orakill 来杀。

另一中思路:
查询v$locked_object;然后用得到的object_id去dba_objects查找object_name,看是不是job,如果是,
证明job死锁了,利用v$locked_object中的session_id去杀死进程。

–用来查询后台
SELECT RAWTOHEX(paddr) paddr_hex, name FROM v$bgprocess
WHERE RAWTOHEX(paddr) <> HEXTORAW(0)
AND name LIKE ‘SNP%’;

情况说明:
系统:SUN Solaris8
数据库版本:9203
问题描述:工程人员报告,数据库在重新启动时无法正常启动.检查发现UNDO表空间丢失.
问题诊断及解决过程如下:

1. 登陆系统检查alert.log文件

检查alert.log文件是通常是我们诊断数据库问题的第一步

SunOS 5.8

login: root
Password:
Last login: Thu Apr 1 11:39:16 from 10.123.7.162
Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001
You have new mail.
# su – oracle
bash-2.03$ cd $ORACLE_BASE/admin/*/bdump
bash-2.03$ vi *.log

“alert_gzhs.log” 7438 lines, 283262 characters
Sat Feb 7 20:30:06 2004
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 3
Using log_archive_dest parameter default value
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.3.0.
System parameters with non-default values:
processes = 150
timed_statistics = TRUE
shared_pool_size = 1157627904
large_pool_size = 16777216
java_pool_size = 637534208
control_files = /u01/oradata/gzhs/control01.ctl,
/u02/oradata/gzhs/control02.ctl,
/u03/oradata/gzhs/control03.ctl
db_block_size = 8192
db_cache_size = 2516582400
compatible = 9.2.0.0.0
log_archive_start = TRUE
log_archive_dest_1 = LOCATION=/u06/oradata/gzhs/arch
log_archive_format = %t_%s.dbf
db_file_multiblock_read_count= 16
fast_start_mttr_target = 300
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 10800
remote_login_passwordfile= EXCLUSIVE
db_domain =
instance_name = gzhs
dispatchers = (PROTOCOL=TCP) (SERVICE=gzhsXDB)
job_queue_processes = 10
hash_join_enabled = TRUE
background_dump_dest = /oracle/admin/gzhs/bdump
user_dump_dest = /oracle/admin/gzhs/udump
core_dump_dest = /oracle/admin/gzhs/cdump
sort_area_size = 524288
db_name = gzhs
open_cursors = 300
star_transformation_enabled= FALSE
query_rewrite_enabled = FALSE
pga_aggregate_target = 838860800
aq_tm_processes = 1
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
“alert_gzhs.log” 7438 lines, 283262 characters
USER: terminating instance due to error 30012
Instance terminated by USER, pid = 26433
ORA-1092 signalled during: ALTER DATABASE OPEN…
Thu Apr 1 11:11:08 2004
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 3
Using log_archive_dest parameter default value
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.3.0.
System parameters with non-default values:
processes = 150
timed_statistics = TRUE
shared_pool_size = 1157627904
large_pool_size = 16777216
java_pool_size = 637534208
control_files = /u01/oradata/gzhs/control01.ctl, /u02/oradata/gzhs/control02.ctl, /u03/oradata/gzhs/control03.ctl
db_block_size = 8192
db_cache_size = 2516582400
compatible = 9.2.0.0.0
log_archive_start = TRUE
log_archive_dest_1 = LOCATION=/u06/oradata/gzhs/arch
log_archive_format = %t_%s.dbf
db_file_multiblock_read_count= 16
fast_start_mttr_target = 300
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 10800
remote_login_passwordfile= EXCLUSIVE
db_domain =
instance_name = gzhs
dispatchers = (PROTOCOL=TCP) (SERVICE=gzhsXDB)
job_queue_processes = 10
hash_join_enabled = TRUE
background_dump_dest = /oracle/admin/gzhs/bdump
user_dump_dest = /oracle/admin/gzhs/udump
core_dump_dest = /oracle/admin/gzhs/cdump
sort_area_size = 524288
db_name = gzhs
open_cursors = 300
star_transformation_enabled= FALSE
query_rewrite_enabled = FALSE
pga_aggregate_target = 838860800
aq_tm_processes = 1
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
CJQ0 started with pid=8
Thu Apr 1 11:11:13 2004
starting up 1 shared server(s) …
QMN0 started with pid=9
Thu Apr 1 11:11:13 2004
starting up 1 dispatcher(s) for network address ‘(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))’…
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=12
ARC0: Archival started
ARC1 started with pid=13
Thu Apr 1 11:11:13 2004
ARCH: STARTING ARCH PROCESSES COMPLETE
Thu Apr 1 11:11:13 2004
ARC0: Thread not mounted
Thu Apr 1 11:11:13 2004
ARC1: Archival started
ARC1: Thread not mounted
Thu Apr 1 11:11:14 2004
ALTER DATABASE MOUNT
Thu Apr 1 11:11:18 2004
Successful mount of redo thread 1, with mount id 1088380178.
Thu Apr 1 11:11:18 2004
Database mounted in Exclusive Mode.
Completed: ALTER DATABASE MOUNT
Thu Apr 1 11:11:27 2004
alter database open
Thu Apr 1 11:11:27 2004
Beginning crash recovery of 1 threads
Thu Apr 1 11:11:27 2004
Started first pass scan
Thu Apr 1 11:11:28 2004
Completed first pass scan
1 redo blocks read, 0 data blocks need recovery
Thu Apr 1 11:11:28 2004
Started recovery at
Thread 1: logseq 177, block 2, scn 0.33104793
Recovery of Online Redo Log: Thread 1 Group 3 Seq 177 Reading mem 0
Mem# 0 errs 0: /u01/oradata/gzhs/redo03.log
Thu Apr 1 11:11:28 2004
Completed redo application
Thu Apr 1 11:11:28 2004
Ended recovery at
Thread 1: logseq 177, block 3, scn 0.33124794
0 data blocks read, 0 data blocks written, 1 redo blocks read
Crash recovery completed successfully
Thu Apr 1 11:11:28 2004
LGWR: Primary database is in CLUSTER CONSISTENT mode
Thread 1 advanced to log sequence 178
Thread 1 opened at log sequence 178
Current log# 1 seq# 178 mem# 0: /u01/oradata/gzhs/redo01.log
Successful open of redo thread 1.
Thu Apr 1 11:11:28 2004
ARC0: Evaluating archive log 3 thread 1 sequence 177
Thu Apr 1 11:11:28 2004
ARC0: Beginning to archive log 3 thread 1 sequence 177
Creating archive destination LOG_ARCHIVE_DEST_1: ‘/u06/oradata/gzhs/arch/1_177.dbf’
Thu Apr 1 11:11:28 2004
SMON: enabling cache recovery
ARC0: Completed archiving log 3 thread 1 sequence 177
Thu Apr 1 11:11:28 2004
Errors in file /oracle/admin/gzhs/udump/gzhs_ora_27781.trc:
ORA-30012: \263\267\317\373\261\355\277\325\274\344 ‘UNDOTBS1′ \262\273\264\346\324\332\273\362\300\340\320\315\262\273\325\375\310\
267
Thu Apr 1 11:11:28 2004
Error 30012 happened during db open, shutting down database
USER: terminating instance due to error 30012
Instance terminated by USER, pid = 27781
ORA-1092 signalled during: alter database open…

:q

在警报日志末尾显示了数据库在Open状态因为错误而异常终止.

2. 尝试重新启动数据库

bash-2.03$ sqlplus “/ as sysdba”

SQL*Plus: Release 9.2.0.3.0 – Production on 星期四 4月 1 11:43:52 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

已连接到空闲例程。

SQL> startup
ORACLE 例程已经启动。

Total System Global Area 4364148184 bytes
Fixed Size 736728 bytes
Variable Size 1845493760 bytes
Database Buffers 2516582400 bytes
Redo Buffers 1335296 bytes
数据库装载完毕。
ORA-01092: ORACLE 例程终止。强行断开连接

工程人员报告的问题重现.

3. 检查数据文件

bash-2.03$ cd /u01/ oradata/gzhs
bash-2.03$ ls -l
total 55702458
-rw-r—– 1 oracle dba 1073750016 Apr 1 11:44 UNDOTBS2.dbf
-rw-r—– 1 oracle dba 1073750016 Apr 1 11:44 WAP12_BILLINGDETAIL.dbf
-rw-r—– 1 oracle dba 1073750016 Apr 1 11:44 WAP12_MAIN.dbf
-rw-r—– 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN10.dbf
-rw-r—– 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN11.dbf
-rw-r—– 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN2.dbf
-rw-r—– 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN3.dbf
-rw-r—– 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN4.dbf
-rw-r—– 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN5.dbf
-rw-r—– 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN6.dbf
-rw-r—– 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN7.dbf
-rw-r—– 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN8.dbf
-rw-r—– 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN9.dbf
-rw-r—– 1 oracle dba 1073750016 Apr 1 11:44 WAP12_MVIEW.dbf
-rw-r—– 1 oracle dba 1073750016 Mar 24 17:15 WAP12_TEMP1.dbf
…………………….

发现存在文件UNDOTBS2.dbf

4. mount数据库,检查系统参数

bash-2.03$ sqlplus “/ as sysdba”

SQL*Plus: Release 9.2.0.3.0 – Production on 星期四 4月 1 11:46:20 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

已连接到空闲例程。

SQL>
SQL>
SQL> startup mount;
ORACLE 例程已经启动。

Total System Global Area 4364148184 bytes
Fixed Size 736728 bytes
Variable Size 1845493760 bytes
Database Buffers 2516582400 bytes
Redo Buffers 1335296 bytes
数据库装载完毕。
SQL> select name from v$datafile;

NAME
——————————————————————————–
/u01/oradata/gzhs/system01.dbf
/u01/oradata/gzhs/cwmlite01.dbf
/u01/oradata/gzhs/drsys01.dbf
/u01/oradata/gzhs/example01.dbf
/u01/oradata/gzhs/indx01.dbf
/u01/oradata/gzhs/odm01.dbf
/u01/oradata/gzhs/tools01.dbf
/u01/oradata/gzhs/users01.dbf
/u01/oradata/gzhs/xdb01.dbf
…………………….
/u01/oradata/gzhs/UNDOTBS2.dbf

已选择23行。

SQL>
SQL> show parameter undo

NAME TYPE VALUE
———————————— ———– ——————————
undo_management string AUTO
undo_retention integer 10800
undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS1
SQL> show parameter spfile

NAME TYPE VALUE
———————————— ———– ——————————
spfile string

发现系统没有使用spfile,而初始化参数设置的undo表空间为UNDOTBS1

5. 检查参数文件

bash-2.03$ cd $ORACLE_HOME/dbs
bash-2.03$ ls
init.ora initgzhs.ora initgzhs.ora.old orapwgzhs
initdw.ora initgzhs.ora.hurray lkGZHS snapcf_gzhs.f
bash-2.03$ vi initgzhs.ora
“initgzhs.ora” [Incomplete last line] 105 lines, 3087 characters
##############################################################################
# Copyright (c) 1991, 2001, 2002 by Oracle Corporation
##############################################################################

###########################################
# Archive
###########################################
log_archive_dest_1=’LOCATION=/u06/oradata/gzhs/arch’
log_archive_format=%t_%s.dbf
log_archive_start=true

###########################################
# Cache and I/O
###########################################
db_block_size=8192
db_cache_size=2516582400
db_file_multiblock_read_count=16

###########################################
# Cursors and Library Cache
###########################################
open_cursors=300

………………….

###########################################
# System Managed Undo and Rollback Segments
###########################################
undo_management=AUTO
undo_retention=10800
undo_tablespace=UNDOTBS1

:q!

这个设置是极其可疑的.
怀疑参数文件和实际数据库设置不符.

6. 再次检查alert文件
查找对于UNDO表空间的操作

第一部分,创建数据库时的信息:

Sat Feb 7 20:30:12 2004
CREATE DATABASE gzhs
MAXINSTANCES 1
MAXLOGHISTORY 1
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
DATAFILE ‘/u01/oradata/gzhs/system01.dbf’ SIZE 500M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE ‘/u01/oradata/gzhs/temp01.dbf’ SIZE 1000M REUSE AUTOEXTEND ON NEXT 250M MAXSIZE UNLIMITED
UNDO TABLESPACE “UNDOTBS1″ DATAFILE ‘/u01/oradata/gzhs/undotbs01.dbf’ SIZE 1000M REUSE AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED
CHARACTER SET ZHS16GBK
NATIONAL CHARACTER SET AL16UTF16
LOGFILE GROUP 1 (‘/u01/oradata/gzhs/redo01.log’) SIZE 256M,
GROUP 2 (‘/u01/oradata/gzhs/redo02.log’) SIZE 256M,
GROUP 3 (‘/u01/oradata/gzhs/redo03.log’) SIZE 256M

注意,这也是OCP教材上提到的两种创建UNDO表空间的方式之一

第二部分,发现创建UNDOTBS2的记录信息:

Wed Mar 24 20:20:58 2004
/* OracleOEM */ CREATE UNDO TABLESPACE “UNDOTBS2″ DATAFILE ‘/u01/oradata/gzhs/UNDOTBS2.dbf’ SIZE 1024M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED
Wed Mar 24 20:22:37 2004
Created Undo Segment _SYSSMU11$
Created Undo Segment _SYSSMU12$
Created Undo Segment _SYSSMU13$
Created Undo Segment _SYSSMU14$
Created Undo Segment _SYSSMU15$
Created Undo Segment _SYSSMU16$
Created Undo Segment _SYSSMU17$
Created Undo Segment _SYSSMU18$
Created Undo Segment _SYSSMU19$
Created Undo Segment _SYSSMU20$
Completed: /* OracleOEM */ CREATE UNDO TABLESPACE “UNDOTBS2″
Wed Mar 24 20:24:25 2004
Undo Segment 11 Onlined
Undo Segment 12 Onlined
Undo Segment 13 Onlined
Undo Segment 14 Onlined
Undo Segment 15 Onlined
Undo Segment 16 Onlined
Undo Segment 17 Onlined
Undo Segment 18 Onlined
Undo Segment 19 Onlined
Undo Segment 20 Onlined
Successfully onlined Undo Tablespace 15.
Undo Segment 1 Offlined
Undo Segment 2 Offlined
Undo Segment 3 Offlined
Undo Segment 4 Offlined
Undo Segment 5 Offlined
Undo Segment 6 Offlined
Undo Segment 7 Offlined
Undo Segment 8 Offlined
Undo Segment 9 Offlined
Undo Segment 10 Offlined
Undo Tablespace 1 successfully switched out.

第三部分,新的UNDO表空间被应用

Wed Mar 24 20:24:25 2004
ALTER SYSTEM SET undo_tablespace=’UNDOTBS2′ SCOPE=MEMORY;

我们发现问题就在这里,创建了新的UNDO表空间以后,因为使用的是pfile文件,修改的只对当前实例生效,操作人员忘记了修改pfile文件.

如果使用spfile,缺省的修改范围是both,会同时修改spfile文件,就可以避免以上问题的出现.

第四部分,删除了UNDOTBS1的信息

Wed Mar 24 20:25:01 2004
/* OracleOEM */ DROP TABLESPACE “UNDOTBS1″ INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS
Wed Mar 24 20:25:03 2004
Deleted file /u01/oradata/gzhs/undotbs01.dbf
Completed: /* OracleOEM */ DROP TABLESPACE “UNDOTBS1″ INCLUDI

这样再次重新启动数据库的时候,问题出现了,pfile中定义的UNDOTBS1找不到了,而且操作实在很久以前,没人能回忆起来,甚至无法得知是什么人的操作。

7. 更改pfile,启动数据库

修改undo表空间

###########################################
# System Managed Undo and Rollback Segments
###########################################
undo_management=AUTO
undo_retention=10800
undo_tablespace=UNDOTBS2

….

bash-2.03$ sqlplus “/ as sysdba”

SQL*Plus: Release 9.2.0.3.0 – Production on 星期四 4月 1 11:55:11 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

连接到:
Oracle9i Enterprise Edition Release 9.2.0.3.0 – 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 – Production

SQL> select * from v$version;

BANNER
—————————————————————-
Oracle9i Enterprise Edition Release 9.2.0.3.0 – 64bit Production
PL/SQL Release 9.2.0.3.0 – Production
CORE 9.2.0.3.0 Production
TNS for Solaris: Version 9.2.0.3.0 – Production
NLSRTL Version 9.2.0.3.0 – Production

SQL> exit
从Oracle9i Enterprise Edition Release 9.2.0.3.0 – 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 – Production中断开
bash-2.03$

在这里我们可以看到,使用spfile可以免去手工修改pfile文件的麻烦,减少了犯错的可能。

既然Oracle9i给我们提供了这个新特性,就值得我们学习使用它.