the Most Simple Method to Get Tracefile Name in 11g

Oracle数据库产生的跟踪文件命名规则是sid_ora_pid.trc,因此可以通过查询数据字典的方式拼出跟踪文件的名称。

Eygle提供过具体的脚本来演示如何获得跟踪文件名称

他的另一篇文章中有blue_prince提供的简化版本 – 获得跟踪文件名称的gettrcname.sql

而在最新的Oracle 11g中,这个SQL我们可以进一步简化,因为在v$process视图中oracle新增加了TRACEFILE字段。

SQL> SELECT p.TRACEFILE
  2    FROM v$session s, v$process p, v$mystat m
  3   WHERE s.paddr = p.addr
  4     AND s.SID = m.SID
  5     AND m.statistic# = 0;
 
TRACEFILE
--------------------------------------------------------------------------------
d:\oracle\diag\rdbms\orcl11g\orcl11g\trace\orcl11g_ora_5760.trc

How to Prevent DBA User From Logining Database Without Password

我们知道如果某个操作系统用户属于dba组,那么登录了这个用户之后,不再需要任何密码就能以SYS用户登录到数据库中,在产品环境中,这无疑是一个严重的安全漏洞。

kamus@desktop:~$ whoami
kamus
kamus@desktop:~$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.6.0 - Production on Sun Apr 5 17:56:58 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> show user
USER is "SYS"
SQL> exit
Disconnected
kamus@desktop:~$ sqlplus nouser/nopassword as sysdba

SQL*Plus: Release 11.1.0.6.0 - Production on Sun Apr 5 17:37:42 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> show user
USER is "SYS"
SQL>  

正如上面的演示,我们轻松以SYS身份登录进了数据库,无须给任何用户名密码,甚至是随便给一个毫不存在的用户和密码也可以。

如何防止这样的问题?

首先,我们可以利用oracle自身提供的sqlnet.ora文件中的参数sqlnet.authentication_services。在$ORACLE_HOME/network/admin/sqlnet.ora文件中添加如下行:
sqlnet.authentication_services=(NONE)

再次尝试不提供用户密码登录sqlplus,将遇到ORA-01031错误。

kamus@desktop:~$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.6.0 - Production on Sun Apr 5 18:05:07 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

ERROR:
ORA-01031: insufficient privileges


Enter user-name: ^C
kamus@desktop:~$ sqlplus sys/oracle as sysdba

SQL*Plus: Release 11.1.0.6.0 - Production on Sun Apr 5 18:06:31 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> 

更进一步,我们还可以让dba组的其他用户必须通过监听程序来连接数据库,这样内置于监听中的审计和跟踪功能就能得到更好的使用。

先来看一下如果不通过监听连接数据库的情况。继续上面的例子,在我们通过用户名密码成功登录数据库实例以后,查看一下操作系统级别的进程。

kamus@desktop:~$ ps -ef|grep sqlplus
kamus     6556  5409  0 18:06 pts/0    00:00:00 sqlplus            as sysdba
kamus     6561  5601  0 18:11 pts/2    00:00:00 grep sqlplus
kamus@desktop:~$ ps -ef|grep 6556 | grep -v grep
kamus     6556  5409  0 18:06 pts/0    00:00:00 sqlplus            as sysdba
oracle    6557  6556  0 18:06 ?        00:00:00 oracleorcl11g (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

pid为6556的进程是user process,对应其的server process的pid是6557,这就是oracle使用的双层架构(Two-Task Architecture),任何用户进程(user process)不会跟数据库内存或者数据文件直接交互,而是通过一个对应的服务端进程(server process)来完成工作的。

我们可以注意到,6556进程的属主是kamus,因为是这个用户执行的sqlplus命令,但是6557进程的属主却是oracle,这是为什么呢?这归功于setuid。查看一下oracle可执行文件的权限。

kamus@desktop:~$ cd $ORACLE_HOME/bin
kamus@desktop:/u01/app/oracle/product/11.1.0/bin$ ls -l oracle
-rwsr-s--x 1 oracle oinstall 144792107 2009-01-05 14:01 oracle

owner的权限是rws,最后的s位表明在该执行文件上启用了setuid,具体含义就是不管是那个用户执行了该文件,该文件总是以属主的身份运行。那么如果我们取消掉s位,会出现什么情况呢?

kamus@desktop:/u01/app/oracle/product/11.1.0/network/admin$ cd
kamus@desktop:~$ su - oracle
Password: 
[orcl11g]@desktop[/home/oracle]$cd $ORACLE_HOME/bin
[orcl11g]@desktop[/u01/app/oracle/product/11.1.0/bin]$chmod u-s oracle
[orcl11g]@desktop[/u01/app/oracle/product/11.1.0/bin]$ls -l oracle
-rwxr-s--x 1 oracle oinstall 144792107 2009-01-05 14:01 oracle

再次尝试在kamus用户下登录sqlplus。碰到了ORA-09925错误。

kamus@desktop:~$ sqlplus sys/oracle as sysdba

SQL*Plus: Release 11.1.0.6.0 - Production on Sun Apr 5 18:26:16 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

ERROR:
ORA-09925: Unable to create audit trail file


Enter user-name: 

再检查一下后台进程。

kamus@desktop:~$ ps -ef|grep sqlplus|grep -v grep
kamus     6699  5601  0 18:26 pts/2    00:00:00 sqlplus            as sysdba
kamus@desktop:~$ ps -ef|grep 6699|grep -v grep
kamus     6699  5601  0 18:26 pts/2    00:00:00 sqlplus            as sysdba
kamus     6700  6699  0 18:26 ?        00:00:00 oracleorcl11g (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

原因很清楚,当我们去掉了oracle可执行文件的s位以后,server process的属主成为了kamus,而不是之前的oracle。登录sqlplus需要记录一定的audit信息,这是由server process来完成的,但是因为现在属主是kamus,并没有权限在oracle软件的安装目录中写入任何信息,因此报ORA-09925错误。

更彻底一些,我们连server process都不允许在本地启动,去掉oracle可执行文件的其他用户执行权限,只保留属主的读写执行权限。

[orcl11g]@desktop[/u01/app/oracle/product/11.1.0/bin]$chmod 0700 oracle
[orcl11g]@desktop[/u01/app/oracle/product/11.1.0/bin]$ls -l oracle
-rwx------ 1 oracle oinstall 144792107 2009-01-05 14:01 oracle

再次尝试登录sqlplus,这次碰到了ORA-12546错误。

kamus@desktop:~$ sqlplus sys/oracle as sysdba

SQL*Plus: Release 11.1.0.6.0 - Production on Sun Apr 5 18:44:14 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

ERROR:
ORA-12546: TNS:permission denied


Enter user-name: 

检查后台进程,可以看到根本就没有启动成功的server process。

kamus@desktop:~$ ps -ef|grep sqlplus|grep -v grep
kamus     6916  5601  0 18:44 pts/2    00:00:00 sqlplus            as sysdba
kamus     6917  6916  0 18:44 ?        00:00:00 [sqlplus] 

在这种设置下,必须要通过监听才可以登录数据库。

首先,使用oracle用户登陆,启动数据库。取消掉oracle可执行文件的s位后,必须要登陆到该文件的属主用户下,才可以启动数据库。

[orcl11g]@desktop[/home/oracle]$sqlplus sys/oracle as sysdba

SQL*Plus: Release 11.1.0.6.0 - Production on Sun Apr 5 18:56:23 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area  238530560 bytes
Fixed Size                  1299116 bytes
Variable Size             100666708 bytes
Database Buffers          134217728 bytes
Redo Buffers                2347008 bytes
Database mounted.
Database opened.
SQL> 

然后再登陆kamus用户,尝试登陆sqlplus。orcl11g是在tnsnames.ora文件中已经设置过的连接字串。

[orcl11g]@desktop[/home/kamus]$sqlplus sys/oracle@orcl11g as sysdba

SQL*Plus: Release 11.1.0.6.0 - Production on Sun Apr 5 18:57:16 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning and Real Application Testing options

SQL> 

通过监听,可以正常连接数据库了。再检查一下后台进程的情况。

[orcl11g]@desktop[/home/kamus]$ps -ef|grep sqlplus|grep -v grep
oracle    7077  6966  0 18:56 pts/3    00:00:00 sqlplus            as sysdba
kamus     7156  7008  0 18:57 pts/5    00:00:00 sqlplus                    as sysdba
[orcl11g]@desktop[/home/kamus]$ps -ef|grep LOCAL|grep -v grep
oracle    7118  7077  1 18:56 ?        00:00:02 oracleorcl11g (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle    7172     1  0 18:57 ?        00:00:00 oracleorcl11g (LOCAL=NO) 

7077进程是我们使用oracle用户打开的sqlplus连接,对应的server process是7118,7156进程则是使用kamus用户打开的sqlplus连接,可以看到并没有父进程是7156的server process,只有一个7172的进程,它的父进程号是1。

[orcl11g]@desktop[/home/kamus]$ps -fp 1
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 17:10 ?        00:00:01 /sbin/init 

1是初始化进程,父进程为1代表这个进程是被fork出来的,这就是通过监听连接数据库的机制,user process联系监听,监听再fork一个server process用以应对客户端的请求。

至此,我们已经完成了对于数据库连接的基本安全性设置。

结论:通过下面的两种方法来完成数据库连接的安全保障。
1. 在sqlnet.ora文件中添加sqlnet.authentication_services=(NONE),用以保证必须要给出SYS用户密码才能登陆。
2. 设置oracle可执行文件的运行权限为0700,用以保证非oracle软件的属主必须要通过监听才可以连接数据库。

安全,并不仅仅是局限于数据库本身的,在本文的安全性设置中,它牵涉到数据库运行的机制以及操作系统的部分知识,当你的知识越全面,你就能想到越多的方法来完善整个系统的安全。当然,安全性的建设也远远不局限于技术层面,规章制度、人员素质、完善的审计流程都具有决定性的影响。

User Default Password Check in Oracle 11g

在数据库安全性检查中有一项首先要完成的工作,就是检查数据库中的用户密码是否还仍然保留着默认值,比如sys的密码是否还是change_on_install,system的密码是否还是manager,scott的密码是否还是tiger。

在Oracle 11g之前,我们需要手工来完成这样的工作,大概步骤是:
1. 创建一张自定义的表,保存下常用的系统用户以及默认密码的HASH值。
2. 将系统中的用户密码HASH值与该表中的HASH值比较,如果相同,则表明还在使用默认值。

注意:在数据字典中存储的密码是被HASH算法加密过的,加密后的值不但跟密码本身有关还跟用户名有关,也就是,如果是不相同的用户名那么即使是完全相同的密码,加密后的HASH值也是不一样的。这样保证了每一个用户的每一个密码都有自己独一无二的HASH值。

在Oracle 11g之前,加密后的密码可以从DBA_USERS数据字典的PASSWORD字段中获得,因此可以通过这个字段中存储的值来做是否是默认值的检查。但是在11g中,PASSWORD字段却不再显示密码的内容了。

先看一下文档中对这个字段的描述:

Indicates whether the user is authenticated by OID (GLOBAL) or externally authenticated (EXTERNAL); NULL otherwise

SQL> select username,decode(password,null,'NULL',password) password from dba_users;
 
USERNAME                       PASSWORD
------------------------------ ------------------------------
MGMT_VIEW                      NULL
SYS                            NULL
SYSTEM                         NULL
DBSNMP                         NULL
SNPM                           NULL
SYSMAN                         NULL
SNPW                           NULL
SCOTT                          NULL
KAMUS                          NULL
OUTLN                          NULL
WMSYS                          NULL
DIP                            NULL
ORACLE_OCM                     NULL
TSMSYS                         NULL
 
14 rows selected

可以看到PASSWORD字段已经不再显示密码内容,全部都为空。

那么,如果再去检查这些用户是否还在使用默认的密码呢?

方法一:从SYS.USER$基表中检查,在基表的password字段中仍然可以查到HASH后的值。

SQL>  select name,password from user$ where name='SCOTT';

NAME                           PASSWORD
------------------------------ ------------------------------
SCOTT                          F894844C34402B67

方法二:这是推荐的方法,最简单的方法,11g中可以使用的方法,11g提供了新的DBA_USERS_WITH_DEFPWD视图,该视图中包含了所有还在使用默认密码的用户名。

SQL> alter user scott identified by tiger;

User altered.

SQL> select * from DBA_USERS_WITH_DEFPWD where username='SCOTT';

USERNAME
------------------------------
SCOTT

SQL> alter user scott identified by tiger1;

User altered.

SQL> select * from DBA_USERS_WITH_DEFPWD where username='SCOTT';

no rows selected

Oracle对于安全性的支持力求做到业界领先,Oracle始终在每个细节上进步着。

Oracle Maximum Security Architecture

Oracle 最大安全性架构

很多人应该知道在基于Oracle数据库的系统实施过程中,有一种高可用性的解决方案,称为MAA(Maximum Availability Architecture),通过RAC和Dataguard等一系列技术和选件搭建一个可以获得最大高可用性的IT环境。

MAA保证了IT系统能够被持续使用,而与此同时,另外一个需求就诞生了,系统不但需要能够持续使用,而且还需要能够安全使用。安全,同样也是IT系统能够符合行业标准的前提条件。面对安全需求,Oracle提出了MSA架构,也就是Maximum Security Architecture,最大安全性架构。

IT系统在哪些方面具有安全性需求呢?
1. 用户管理
应用系统需要有正常的用户登陆以及用户验证,具有权限的用户在自身管理方面是需要注意安全的,以防止被其它人员非法获取登陆或者查看数据的权限。

2. 存取控制
在应用系统中不同的用户应该具有不同的权限,不同权限的用户可以登陆的范围或者查看数据的多少也是不同的。这是上面一步的延展,不同的用户通过安全的机制登陆进系统了,同样需要有另外一种安全机制来控制不同的用户存取不同的数据。

3. 数据加密以及数据遮盖
进一步延展,不同的用户安全登陆系统,并且已经各自安全的查看自己的数据了,那么数据本身是否安全呢?这就需要数据加密或者数据遮盖技术来完成。

4. 监控
这个体系并不仅仅是监控报表,因为那只是事后的工作,也许一个违规的操作出现几天以后,安全报表中才出现记录,哪怕仅仅是几个小时,实际上违规的操作已然发生,产生的危害也许已经是无法挽回的了。因此对于整个应用系统的安全流程,必须要有一个完善的监控体系来实时地给予监控,在违规操作发生的当时就立即予以报警。

那么Oracle提出的MSA架构是如何在各个方面提供相应的技术以及产品呢?同样以上述的四个方面分别阐述。

1. 用户控制
1.1 单一登录
管理多个账户以完成相关的工作任务将导致安全性的薄弱环节和高额的所有权成本。一般地,为完成每天的日常工作,一个员工要管理十四个密码或账户。为了应付“密码过多”的问题,员工可能会把密码抄写下来,或选择一个容易猜中的密码。人们经常忘记密码,并频繁地向帮助部门查询。系统管理员甚至面临者一个更大的问题。系统管理员需要花费大量的时间去管理分布于各种数据库,web服务器和网络上的这些账户。如果一个雇员离开了公司,而系统管理员没有注意删除所有的账户,一些老的账号可能就仍然处于激活状态,这无疑埋下了很大的安全隐患。


单一登录原理图

这个问题的解决方案就是单一登录。单一登录可以使用户通过一个单一的登录过程就能访问所用被授权的应用。如果只管理一个密码或证明书,用户一般就不会把它记录下来,或选择一个不容易被猜中的密码。每个企业都应该有使雇员强制性选择安全密码的安全性策略。认证证书可以集中存储于一个LDAP目录,因此系统管理员可以在一个单独的地方管理这些账户。账户的集中化可以使系统管理员能更迅速地完成追加,删除和修正账户的工作。Oracle通过单点登陆服务套件(Enterprise Single Sign-On suite)集成Oracle互联网目录LDAP提供了单一认证。Oracle也可以与其他第三方单一登录服务器的集成,如Kerberos 和 Netegrity。

1.2 超强认证
通过互联网你可能看不到正在与谁做生意,所以在数字世界中存在着一种可以让系统识别身份的机制。用户名和密码的组合是一个系统认证和识别用户的最普遍或最基本的方式。一些企业认为,这种基础的,单向的认证方式并不十分安全,特别是当用户需要管理几个密码时更是如此。另一种方式,或者是认证的更安全的方式是所谓的超强认证。我们可以给出几个超强认证的例子,如X.509数字证书,证明卡和生物认证设备。Oracle 通过身份管理(COREid)结合第三方全面支持基本认证和多种超强认证。比如支持以下具有工业标准的高级认证方式:
Kerberos
RADIUS (Remote Authentication Dial-In User Service)
Secure Sockets Layer
PKI

2. 存取控制
2.1 精细的访问控制
互联网和在线服务目前已要求服务器能够实现精细的访问控制。如果您考虑数据库服务器将管理互联网上多团体用户的数据,数据库必须保证用户只能访问与它相关的数据,而不涉及其他的数据。例如,在线银行业务服务需要保证客户所访问的账户信息只能是他们自己的,而不能看到其他客户的信息。
能够控制对敏感信息的访问对需要满足隐私性需求的应用也由帮助。例如,医疗应用软件必须保证医生只能看到他们自己病人的记录。
因为数据库在传统上是在表的级别上分配权限,而不会控制在单独的记录或更低的级别,附加的应用代码可能被要求取得更精细的访问控制。传统方法的问题是如果用户利用应用之外的方式,如特别的查询工具等访问数据库,就可以绕过安全性设置。而且,维护复杂的访问控制代码会导致高额的开发和管理成本。


Oracle10g数据库的标签安全保护最敏感数据

Oracle10g数据库的标签安全性组件(Label Security)是一个精细访问控制或行级别安全性的无限的解决方案。建立在Oracle虚拟个人数据库的工具包基础上的Oracle标签安全性向数据行中追加了一个特别的标记(标签),可以达到行级别的安全性。例如,在线服务可以使用一个订阅标签,它可以将存储于相同数据库服务器中的各企业的数据更安全有效的分离开。
简单的Label Security设置方法参看我的这篇文章 – 利用OLS实现行级安全性 Step By Step

2.2内部控制
企业IT系统的内部安全管理的需求来源于传统的管理用户的模糊定义,尤其是某些特权用户的定义(比如DBA等),原先只是希望他们管理数据库表结构或本部门的数据,但由于其传统的定义使这类用户可以访问所有的应用数据,甚至敏感数据(如企业HR部门的员工工资和个人信息,Finance部门的重要业务数据等);同时,随着企业系统的发展,信息整合带来不可避免的数据库合并,大量的子系统的特权用户的访问权限被简单地扩展到了所有系统。

Oracle Database Vault正是为解决上面这些敏感的安全问题而诞生的, Oracle Databse 10g R2 企业版的新增安全选件,Database Vault安全选件可以控制什么人,在什么时间,在什么地点或是什么样的应用程序来访问,保护我们的业务避免来自于内部的用户恶意的攻击。对职责进行严格分离,甚至在我们的系统管理员中,Oracle Database Vault选件额外增加强大的可预见性的控制功能帮助企业或公司满足今天严格法规和敏感的需求。Vault是目前业内最早的相关安全的产品,引入了几个新的强大的安全特性(Realms领域、Factor代理、Rule规则等)来限制对数据库的访问,即便是一些超级用户或特权也是如此。这些特点可应用于一个灵活的,易于定制的样式去增强我们的授权需要,而不需对客户已存在的应用做任何修改。

3. 数据加密以及数据遮盖
3.1 加密系统
通过互联网从事商务活动需要通过网络传输信息。任何人,不论是黑客,解密高手还是不诚实的雇员,都可以下载一个信息包的嗅探器,当信用卡等这类敏感信息在网络中传输时,利用嗅探器可以捕获它们。不怀好意的用户也可以利用一些途径获得对存储于服务器中的数据的非法访问。为了防止对数据的非法访问,可以采用加密系统,利用信息的不规则性保护数据。它涉及数学的计算方法和密钥。公共密钥的基础结构是最普遍采用的方法。它为加密,数据整合,数字认证和数字签名提供了技术。


Oracle10g数据库的高级安全性组件保证网络传输数据安全

当数据在网络中的所有层,包括用户层,中间层和数据库层传输时,Oracle提供了网络中端到端的加密。Oracle应用服务器提供了网络中用户层和中间层的加密。Oracle数据库的高级安全性组件(Advanced Security)提供了网络中中间层和数据库层的加密。为了强化性能,Oracle通过Oracle与RSA的BSAFE库的集成,支持BHAPI的接口。Oracle也对存储于数据库内部的数据提供加密。对于非常敏感信息如信用卡号的加密,如果有对数据非法访问的企图或摆脱数据库控制的企图,如通过操作系统,可在数据库中追加一个额外的保护层。

3.2 备份安全
为了信息的延续性,信息保存的时间要求越来越长,因此备份数据的安全也受到了很大的挑战,一方面,企业使用大量的备份介质来备份数据;一方面,企业不断地从备份数据中恢复以便使用;同时,企业会对大量的备份筛选,淘汰过时的备份,这些复杂的数据备份管理过程中,信息的安全问题也日益突出。

如果企业选择将备份数据保存在磁盘中,那么TDE(Transparent Data Encryption)是应该首选考虑的,TDE可以在包含敏感数据的列,表,表空间上进行加密,加密之后的数据备份到磁盘上,备份文件中的信息也同样是加密的,这样即使备份文件意外丢失,也几乎没有可能通过恢复或者直接扫描裸文件的方法从备份文件中获得敏感数据。

在云计算十分受到追捧的今天,将自己的备份数据存储在第三方提供的云计算存储(比如Amazon S3)中,如何才能放心,如何才能保证其中的敏感数据不被剽窃,TDE无疑是理想的选择。

如果企业选择直接将数据备份到磁带中,那么Oracle Secure Backup提供方便、安全可靠的磁带备份解决方案。

为了更好地管理备份数据的安全,Oracle通过10g 之后版本中诞生的最新选件Secure Backup来很好地管理与控制备份介质尤其是磁带备份的安全问题。Secure Backup为数据库备份提供了中央磁带备份管理平台,简化了Oracle数据库与文件系统的备份管理。数据就是企业的生命力,必须被妥善保管并保护,保持在服务器激活的状态过程中不被恶意访问。数据中心的安全策略是保护物理接入服务器、数据、公司网络的关键。当数据保存至磁带,Oracle Secure Backup 将与安全策略平行工作,它提供了安全的Inter-Domain数据交换与控制消息机制,限制授权用户对备份数据的管理并通过RMAN将数据加密写入至备份磁带。

借助于成熟的Secure Socket Layer (SSL) 技术,集成Oracle Advanced Security 选件,Oracle Secure Backup可以实现双向服务器授权、加密备份恢复控制消息、网络传输过程数据加密,从而保证数据备份传输过程中的安全。

数据库备份可以通过RMAN进行加密,然后由Oracle Secure Backup完成对磁带的加密格式写入。这种集成式的加密方案保证了数据在离开数据库之后的安全。RMAN加密备份的解密是在恢复操作或重载时自动完成的,任何需要的时候密钥都是可用的,用户可以任意选用密码或Oracle Encryption Wallet。

Oracle Secure Backup提供了基于密码和关联用户权限的用户层访问控制以避免备份数据被未授权用户所访问。每个配置用户必须被注册拥有指定的系列权限,可以在域内设置执行任何数据保护操作。通过组合内部预置的18种特殊的备份及恢复权力,备份者可以高度精确的控制用户对域内的访问行为。通过选择预定义的5类对用户接入域时对各角度“读”或“写”的安全控制类,同时用户也可以定义自己的安全控制类来满足用户环境内的安全需求。一个客户只能被赋予一种安全类但是一个安全类可以拥有多个用户。

4. 监控
4.1 精细审核
审核是普遍使用的最有效的安全性机制,它可以保证系统的合法用户能完成他们应该从事的工作,同时又可以限制他们对权限的滥用。通过审核,企业可以跟踪用户的活动,从而发现安全性的漏洞。而且,用户如果知道他们正受到跟踪,他们也不愿意滥用他们的权限。因为传统的审核将产生极大量的数据,因此也很难发现有用的信息,Oracle10g强化了精细审核(FGA)。利用精细的扩展审核,安全性漏洞将会非常容易被发现。例如,如果建立了一个审核策略用于重复性筛选信用卡号,就会自动生成一个警告,警告系统管理员可能的入侵。系统管理员可根据这些警告做出响应,如终止非法数据库的对话。

4.2 Audit Vault
如果说Oracle Database Vault是完善了对于数据库SYSDBA的权限控制,那么Oracle Audit Vault则是对于企业内部违规者的进一步预防和监控。

目前最新版本的OAV 10.2.3.1不但支持Oracle的数据库产品(Oracle Database 9i到10gR2的所有数据库版本),同时也提供了对于Microsoft SQL Server 2000/2005. IBM DB2 UDB 8.2/9.5, 以及 Sybase ASE 12.5/15.0等主流关系型数据库的支持,自动获捕获,存储,分析审计数据,用户已经能够通过单一的审计解决方案来完成对企业内各种数据库活动的审计工作。

对于Oracle数据库而言,OAV的元数据可以是数据库redo日志,数据库Audit日志以及操作系统Audit日志(其它类型的数据库会有所不同),这些元数据被Audit Agent通过预先制定的捕获规则抓取到Audit Server中,而Audit Server端则提供了多样的报表查询,并且根据预先定义的企业策略提供违规操作告警功能。

Oracle Audit Vault帮助机构实施“信任但是验证”原则。Oracle Audit Vault帮助企业简化合规报告,及早检测到威胁,同时以透明的方式收集并将审计数据整合到企业级的审计整合管理解决方案中;整合并保护从Oracle数据库采集的审计数据;通过简化IT安全官员和内部审计员的工作,大幅度降低企业合规性的成本;使用户拥有最大灵活性的同时,有效监控他们的活动以确保这些行为符合企业的制度。

结论
MSA架构体现了Oracle的深度防御理念(Defense-in-Depth),在网络层,存储层,人员层都提供了完善的防护,同时在监控方面又体现了Proactive的2.0理念,实时并且全方位的给予安全监控。

世上没有安全性的魔术子弹,但Oracle始终站在产品安全性以及客户的系统安全性背后。

Oracle提出:

因为我们自己的企业也是运行在Oracle之上,我们也是提供坚不可摧软件的既得利益者。坚不可摧建立在我们具有20年为世界上最具安全性意识的客户建立系统的实力和经验的基础上,这些客户中包括情报部门和国防部,也建立在由十九个独立的安全性评估所提供的保障基础上。(我们最强劲的竞争对手只分别具有零个或一个评估。他们为什么不在安全产品的生命周期和可证明的安全软件上进行投资呢?)

坚不可摧的软件是一个长期的承诺,它已经在实施过程中,它将被扩展到对每个Oracle产品的相同的开发方法和保障评定中。今天,所有强烈关注安全性的客户都会考虑把他们的数据库运行在Oracle上。

获取更多MSA架构信息,请参看官方网站

Oracle Clusterware consolidated logging

使用过Oracle Clusterware 10gR1的朋友应该还记得各个后台进程的log都被散乱地放在各自的目录中,可惜的是,也许你刚刚熟悉了每个log的位置,然后当你将10gR1升级到10gR2,你就发现所有的log你都找不到了,它们不再在原来的位置,Oracle重新整理放在了统一的目录下。

这里记录一下10gR2和11gR1中Oracle Clusterware的log位置。以下$ORACLE_HOME指Oracle RDBMS软件的安装目录,$ORA_CRS_HOME指Oracle Clusterware软件的安装目录。

CRS logs $ORA_CRS_HOME/log/[hostname]/crsd/
CSS logs $ORA_CRS_HOME/log/[hostname]/cssd/
EVM logs $ORA_CRS_HOME/log/[hostname]/evmd
$ORA_CRS_HOME/evm/log/
Resource logs $ORA_CRS_HOME/log/[hostname]/racg
$ORACLE_HOME/log/[hostname]/racg
SRVM logs $ORA_CRS_HOME/log/[hostname]/client
$ORACLE_HOME/log/[hostname]/client
Cluster Network Communication logs $ORA_CRS_HOME/log
OPMN logs $ORA_CRS_HOME/opmn/logs
alert logs $ORA_CRS_HOME/log/[hostname]/alert[hostname].log
OPROCD logs /var/opt/oracle/[hostname]
CLSOMON files $CRS_HOME/log/[hostname]/cssd/oclsomon

当Oracle Clusterware发生问题的时候,需要寻求Oracle Support的帮助,那么这些位置的log都是可能会需要的。

我们也可以使用在10gR2之后Oracle提供的perl脚本来获取诊断信息。
在10gR2版本中,执行:

$ORA_CRS_HOME/bin/diagcollection.pl -collect

在11gR1版本中,执行:

$ORA_CRS_HOME/bin/diagcollection.pl -crshome=$ORA_CRS_HOME -collect

该脚本执行结束以后,将会产生几个tar.gz文件,包括crsData_[hostname].tar.gz,ocrData_[hostname].tar.gz,oraData_[hostname].tar.gz和basData_[hostname].tar.gz 。

另外如果Oracle Support需要你提供Oracle Clusterware的安装情况,那么可以使用cluvfy实用程序来获得输出。

su - oracle 
cluvfy stage -post crsinst -n all -verbose

Using Diagwait during Oracle Clusterware Node evictions

什么情况下Oracle Clusterware会重启(Evict,驱逐)节点机器?

1. 节点机器在interconnect network上无法ping通,没有了network heartbeat,比如网络问题。
2. 节点机器无法存取Voting Disk,没有了disk heartbeat,比如磁盘问题。
3. 由于节点机器过于繁忙,导致没有空闲资源来完成上述的两种动作之一,比如CPU问题,内存问题。

具体的Timeout算法参看Metalink Note:294430.1

通常,在某个节点被驱逐之后,cssd.log或者crsd.log或者操作系统自身的log中会有具体的信息记载,通过这些log可以知道到底是什么原因导致了节点被驱逐。但是,可能在某些情况下,由于操作系统在被强行reboot之前过于繁忙,根本没有任何空余的CPU时间片来将内存中的log内容写入到磁盘log文件中,这时候,我们在log中看到的就是忽然的一段时间空白之后就是Cluster重新启动的信息了。

在10.2.0.3之后,我们可以设置diagwait,来延迟eviction,让系统在重启之前等待几秒,尽量让log可以写入到磁盘上。该功能目前已经backport到10.1.0.5中,因此在 10.1.0.5 (or higher), 10.2.0.3 (or higher) 和11.1.0.6 (or higher)这些版本中都可以设置diagwait。

注:set diagwait不仅仅会延迟eviction,同时会将oprocd进程的检查margin从默认的500ms(10205中是1500ms)提升到10000ms(也就是10秒),opocd如果发现两次检查的时间间隔超过margin值,就会强制重启服务器,所以实际上set diagwait同样提高了RAC环境的稳定性。

在不支持的版本中设置diagwait将会得到”unrecognized parameter diagwait specified” 错误提示。

设置diagwait的方法,使用root用户执行以下命令:
1. 停止Clusterware

#crsctl stop crs 
#/bin/oprocd stop

2. 确认Clusterware stack已经完全关闭

#ps -ef |egrep "crsd.bin|ocssd.bin|evmd.bin|oprocd"

3. 在集群的任意节点上设置diagwait等待时间13秒

#crsctl set css diagwait 13 -force

4. 检查diagwait设置是否成功

#crsctl get css diagwait

如果设置成功,则返回13,否则返回”Configuration parameter diagwait is not defined”。

5. 重新启动Oracle Clusterware

#crsctl start crs

在解决完导致节点被驱逐的问题之后,可以将diagwait参数取消。

取消的方法仍然按照上面的命令步骤,只是将第3步中的命令改为:

#crsctl unset css diagwait

在Oracle 10gR2 + AIX5L的系统中,可能由于各种原因(比如操作系统的bug或者数据库的bug),导致OPROCD进程驱逐节点,检查以及解决的方法可以参看Metalink Note:419312.1

Automatic tuning of db_file_multiblock_read_count

db_file_multiblock_read_count曾经是一个经过热烈讨论的初始化参数。该参数只有在对表或者索引进行Full Scan的时候才起作用。

在Oracle10gR2以前的版本中,DBA必须根据db_block_size参数,以及应用系统的特性,来调整db_file_multiblock_read_count参数。该参数值将影响CBO在该产生何种SQL执行计划上的判断。

我们知道如下的公式,其中max I/O chunk size跟操作系统有关,但是Oracle文档中也指出大多数操作系统上该值为1M。

db_file_multiblock_read_count = max I/O chunk size / db_block_size

在Oracle10gR2之后的版本(10gR2和11g)中,Oracle数据库已经可以根据系统的IO能力以及Buffer Cache的大小来动态调整该参数值,Oracle建议不要显式设置该参数值。但是根据Oracle官方文档对于此参数的解释:

Note that if the number of sessions is extremely large the multiblock read count value is decreased to avoid the buffer cache getting flooded with too many table scan buffers.
Even though the default value may be a large value, the optimizer will not favor large plans if you do not set this parameter. It would do so only if you explicitly set this parameter to a large value.

因此建议对于已知确实将进行大量全表扫描的OLAP系统,还是应该直接设置为较大的值。

Automatic Statistics Gathering

在Oracle10g中引入的优化器统计信息(Optimizer Statistics)自动收集,是一个看上去很不错的功能,但是在实际应用中却往往没有起到相应的效果,甚至在某些系统中我们会建议禁用这个功能。

阐述一些该功能的相关知识点。

1. Automatic Statistics Gathering是由Scheduler调度GATHER_STATS_JOB作业来完成的,在GATHER_STATS_JOB作业中则调用DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC存储过程。

2. 该作业在创建数据库的自动创建,并且设置为每天晚上10点到第二天早上6点和周六周日的全天为运行窗口期。在运行窗口期内,该作业都会运行,根据stop_on_window_close属性来决定,如在窗口期结束以后,该作业如果还没有运行完毕,是继续运行还是结束运行。

3. GATHER_DATABASE_STATS_JOB_PROC是内部的存储过程,基本上跟DBMS_STATS.GATHER_DATABASE_STATS的功能一样,但是有内部的优先顺序考虑,更新越多的表将会越优先收集统计信息。

4. 收集统计信息的表对象是,之前从来没有收集过的或者是更新的(包括insert,update,delete,truncate)记录数超过当前总记录数10%的表。记录数的更改量由Oracle数据库自动监控,在初始化参数statistics_level设置为TYPICAL或者ALL时,自动监控即会生效。

5. 在USER_TAB_MODIFICATIONS表中记录了所有被监控的表的数据量更改信息。该信息的更新将会稍微滞后于真实的修改,可以通过DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO存储过程来立刻将更改的信息更新到USER_TAB_MODIFICATIONS表中。对于更新之后再rollback的记录,仍然算为已经受影响的记录,Oracle不会在rollback之后再去更新USER_TAB_MODIFICATIONS表。

SQL> select * from user_tab_modifications where table_name=’EMP’;

no rows selected

SQL> select count(*) from emp;

COUNT(*)
———-
14

SQL> update emp set sal=sal+100;

14 rows updated.

SQL> select * from user_tab_modifications where table_name=’EMP’;

no rows selected

SQL> exec DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO();

PL/SQL procedure successfully completed.

SQL> select inserts,updates,deletes from user_tab_modifications where table_name
=’EMP’;

INSERTS UPDATES DELETES
———- ———- ———-
0 14 0

SQL> rollback;

Rollback complete.

SQL> exec DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO();

PL/SQL procedure successfully completed.

SQL> select inserts,updates,deletes from user_tab_modifications where table_name
=’EMP’;

INSERTS UPDATES DELETES
———- ———- ———-
0 14 0

SQL>

6. 在Oracle10g版本(包括最新的10.2.0.4)中没有已知的修改10%这个阀值的方法。但是在Oracle11g中则提供了SET_TABLE_PREFS等函数。

以下命令将指定表的STALE默认值从10%改为5%,该值可以从新的dba_tab_stat_prefs数据字典中查询获得。

–仅限于Oracle11g版本
BEGIN
DBMS_STATS.SET_TABLE_PREFS ( ownname =>’KAMUS’, tabname =>’T1′, pname =>’STALE_PERCENT’, pvalue =>’5′);
END;
/

SQL> select * from dba_tab_stat_prefs;

OWNER TABLE_NAME PREFERENCE_NAME PREFE
———- ———- ——————– —–
KAMUS T1 STALE_PERCENT 5

7. 在Oracle10g中运行以下命令,可以禁用统计信息自动收集功能。
BEGIN
DBMS_SCHEDULER.DISABLE(‘GATHER_STATS_JOB’);
END;
/

Learning ODI – Start Scheduler Agent

对于设置ODI的定时执行场景,需要启动Scheduler Agent,在一个新的ODI安装完毕之后,默认的odiparams.bat文件中设置的是连接DEMO环境的数据库连接配置,如果我们在自己的数据库里创建了Master Repository和Work Repository,那么需要修改连接参数。

在我的测试环境中,我使用的是自己机器上Oracle 11g数据库,实例名是orcl11g,则需要做如下修改:

set ODI_SECU_DRIVER=oracle.jdbc.driver.OracleDriver
set ODI_SECU_URL=jdbc:oracle:thin:@localhost:1521:orcl11g
set ODI_SECU_USER=snpm
set ODI_SECU_ENCODED_PASS=b9yX4CpBkdmaP8Y3mYbaoye2p
set ODI_SECU_WORK_REP=WORKREP1
set ODI_USER=SUPERVISOR
set ODI_ENCODED_PASS=hZypfAZQf.Yo8VWVI6HZzc 

其中:
ODI_SECU_USER需要设置为创建Master Repository时候的用户名,在这里是snpm。
ODI_SECU_ENCODED_PASS需要用agent实用程序加密一下,用法是agent encode %PASSWORD%。
ODI_SECU_WORK_REP设置为创建Work Repository时候起的名字。
ODI_USER默认是SUPERVISOR,这是连接ODI的用户名。
ODI_ENCODED_PASS默认是SUNOPSIS,也需要用agent encode加密之后的值。

设置完毕,启动Scheduler Agent,会遇到下面的错误:

java.lang.Exception: Agent is not declared in Topology Manager

我们还需要在Topology Manager -> Physical Architecture -> Agents里面创建一个Agent,填写Agent的名字,监听的机器,端口。如果需要设置Schedule,还需要在Topology Manager -> Logical Architecture -> Agents里面再创建一个Agent,将刚才创建的Physical Agent和此Logical Agent绑定在一起。

然后,在Designer -> Projects -> Scenarios -> Scheduling中创建一个执行计划,之后再次启动Scheduler Agent就OK了。

C:\OraODI\oracledi\bin>agentscheduler "-port=20910" "-NAME=myFirstAgent"
A JDK is required to execute Web Services with OracleDI. You are currently using a JRE.
OracleDI: Starting Scheduler Agent ...
Starting Oracle Data Integrator Agent...
Version : 10.1.3.4.0 - 30/10/2007
Agent in scheduling mode
Number of items for scheduled executions:0
08/17/2008 02:58:09 PM(main): Server Launched
Aug 17, 2008 3:06:27 PM com.sunopsis.j.s a
INFO: Start Thread[1001@2008/08/17_03:06:27:000,5,main] @ Aug 17, 2008 3:06:27 PM

最后一行显示了在Schedule中定义的计划被执行成功。

在Windows操作系统中可以把Agent程序设置为Service,通过以下命令设置,其中倒数两个参数分别为Physical Agent Name和Agent Port:

agentservice.bat -i -s myFirstAgent 20910

运行成功之后,将会产生OracleDI Agent Scheduler myFirstAgent这样命名的Windows服务。

通过以下命令可以删除创建的服务:

agentservice.bat -r -s myFirstAgent