当前位置：文档之家 › 20_11g新特性_自动存储管理

20_11g新特性_自动存储管理

  • 格式：docx
  • 大小：567.96 KB
  • 文档页数：37

Oracle Database 11g：

面向 DBA 和开发人员的重要特性

自动存储管理

用于管理 ASM 实例的新的 SYSASM 角色、用于降低共享池使用的可变的区大小，以及实例能够读取磁盘组的特定磁盘，这些都是 Oracle Database 11g ASM 中引入的一些重要新特性。

SYSASM 角色

自动存储管理 (ASM) 是在 Oracle Database 10g 中引入的，它在某种程度上打破了 DBA 和系统管理员之间在存储分配功能上的界限。ASM 实例由 DBA 管理，正如常规的 DBA 工作需要以 SYSDBA 角色进行连接一样。但是随着时间的推移，角色变得更加清楚，我们看到发生了基本的分工。因此，一些 ASM 操作返还给系统管理员。在某些情况下，会出现单独的一类“ASM 管理员”，他们只进行 ASM

管理，并不涉及数据库管理。

然而，这个新角色的出现引发了一个冲突：需要用 SYSDBA 角色来管理 ASM 实例，但运行在同一台服务器上的生产数据库的许多 DBA 感觉很难共享该角色。

Oracle Database 11g 消除了这个冲突。有一个新角色 SYSASM，只用于管理 ASM

实例。这类似于针对 ASM 实例的 SYSDBA 角色。下面将演示如何连接到 ASM 实例：

$ sqlplus / as sysasm

SQL*Plus: Release 11.1.0.6.0 - Production on Fri Sep 28 20:37:39 2007

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, Oracle Label Security, OLAP, Data Mining

and Real Application Testing options

SQL>

注意连接子句“as sysasm”。在 Oracle Database 11g 第 1 版中，该 SYSASM

角色被授予具有 SYSDBA 权限的操作系统组（大多数情况下为“dba”）。换言之，Unix 中属于 dba 组的用户也可以作为 SYSASM 进行连接。（今后的版本会更改这种安排；sysdba 和 sysasm 角色将分成不同的 OS 组。）

以 sys 用户身份连接到 ASM 实例后，您可以更新在口令文件中更新的 SYS 口令：

SQL> alter user sys identified by oracle

2 /

User altered.

尽管这个 ASM 实例不带数据库，您仍然可以创建用户：

SQL> create user asmoper identified by dumboper

2 /

User created.

现在，您可以将 SYSASM 角色授予该用户：

SQL> grant sysasm to asmoper;

Grant succeeded.

进行授权之后，asmoper 用户（而非 SYS 用户）可以执行所有 ASM 管理功能。该用户可以通过子句 as sysasm 进行连接，该子句类似于常规数据库中的“as

sysdba”子句。

$ sqlplus asmoper/dumboper as sysasm

这个特性实现了迫切需要的 ASM 和 DBA 职责分离。

可变的区大小

ASM 存储中结构最小的元素是分配单元 (AU)，与 Oracle 数据库块的概念类似。创建表和索引之类的数据库段时，分配的最小单元不是一个块，而是一个包含多个块的区。您可以更改段的区大小。 ASM 中有一个非常类似的概念：在 ASM 磁盘组上创建文件时，最小的可寻址单元是区，而不是 AU。在 Oracle Database 10g 中，AU 和区是可互换的；一个区只包含一个 AU。

10g 兼容的磁盘组需要共享池为每个区提供内存。对于大型数据库，这又需要大量内存。因此，如果 AU 大小为 1MB（默认值），1TB 的数据库需要在共享池中管理超过一百万个区。

在 Oracle Database 11g 中，区大小不再等于 AU 大小。创建文件时，区大小从 1MB 开始。文件达到某个阈值时，区大小增加至 4MB，然后是 16MB，最后当达到某个阈值后，区大小为 64MB。您不必担心大小；ASM 实例会自动分配合适的区大小。由于较少数量的区即可容纳大量数据，因此可以大大减少共享池中的区总数，从而将性能提高数倍。

当文件急剧扩大和缩小时，可变的区大小可能会产生一些碎片。如果需要进行碎片整理，ASM 将自动解决该问题。

可变的 AU 大小

正如我在前面提到的，AU 的默认大小为 1MB。对许多数据库而言，这可能足够大了，但请考虑一个大小超过 10TB 的大型数据库。对象可能超过 1MB，因此您可能希望扩大 AU 大小以减少 AU 数量。在 Oracle Database 10g 中，您可以设置一个底线参数来更改 AU 大小。然而，这会影响之后创建的所有磁盘组，而且还需要一个 ASM 实例回收来设置该参数。

在 Oracle Database 11g 中，只需在创建 DG 期间设置一个磁盘组属性 au_size

即可轻松完成此任务，如下所示：

create diskgroup dg6

external redundancy

disk

'/dev/raw/raw13'

attribute 'au_size' = '2M'

AU_SIZE 应为 1M、2M、4M、8M、16M、32M 或 64M（M 代表 MB）。您还可以将该值设成一个绝对值（单位为字节）：

attribute 'au_size' = ' 2097152'

创建磁盘组之后，您可以通过以下查询来查看 AU 大小：

select name, allocation_unit_size

from v$asm_diskgroup

/

NAME ALLOCATION_UNIT_SIZE

------- --------------------

DG1 1048576

DG3 1048576

DG6 2097152

DG5 1048576

DG4 1048576

DG2 1048576

注意各个磁盘组名称的 AU 大小。现在，您可以创建具有合适 AU 大小的磁盘组，以满足每个应用程序的需要。

磁盘组属性

ASM 是一个适用于从 10g 到当前版本的 Oracle 数据库的存储平台。因此，11g

上的 ASM 实例可以保存 10g 第 1 版、10g 第 2 版以及 11g 第 1 版（以及更高版本）的数据库。只要 ASM 版本与 RDBMS 的版本相同或者更高，就可以在该

ASM 实例上创建数据库。如果 ASM 和 RDBMS 实例的版本不同，它们将如何通信呢？很简单：ASM 将消息转换成适合 RDBMS 的版本。

默认情况下，ASM 实例可以支持 10g 数据库。但如果您希望在该 ASM 实例上仅放置 11g RDBMS，该怎么办？无需进行消息转换来支持版本差异。但如果可以告诉 ASM 实例唯一支持的数据库是 11g 第 1 版，该怎么办？这将消除，至少可以减少消息转换。在 Oracle Database 11g 中，可以使用 ASM 兼容性和 RDBMS

兼容性磁盘组属性实现。

首先，我们将检查磁盘组的当前属性：

SQL> select compatibility, database_compatibility

2 from v$asm_diskgroup

3 where name = 'DG1'

4 /

COMPATIBILITY DATABASE_COMPATIBILITY

---------------------- ----------------------

10.1.0.0.0 10.1.0.0.0

如您所见，ASM 兼容性（由 COMPATIBILITY 显示）设置为 10.1.0.0.0，这意味着该磁盘组最高可支持 10.1 ASM 结构。因此，该磁盘组可以具有任意 RDBMS 结构。另一列 DATABASE_COMPATIBILITY 显示 RDBMS 兼容性设置为 10.1。这意味着，ASM 磁盘组 DG1 可用于 10.1 版的任何 RDBMS。

由于您只希望创建 11g ASM 和 RDBMS 结构，因此无需拥有 10g 元素。要将该磁盘组的 ASM 兼容性属性设置为 11.1，您可以执行以下语句（在 ASM 实例中）：

SQL> alter diskgroup dg1 set attribute 'compatible.asm'='11.1';

现在，如果您检查磁盘组的属性：

COMPATIBILITY DATABASE_COMPATIBILITY

---------------------- ----------------------

11.1.0.0.0 10.1.0.0.0

ASM 兼容性设置为 11.1；但 RDBMS 兼容性仍然设置为 10.1。要将它也更改为

11.1，请使用：

SQL> alter diskgroup dg1 set attribute 'compatible.rdbms'='11.1';

需要特别注意的是：兼容性是针对磁盘组设置的，而不是针对整个 ASM 实例。使用该特性，您只需使用一个 ASM 实例即可满足所有数据库版本类型的需要。根据所使用的版本，您可以相应地设置属性，从而减少版本间通信。

首选的镜像读取

在 Oracle RAC 数据库中，多个节点可能指向同一个 ASM 实例。如果您在一个

ASM 磁盘组中使用正常镜像，访问磁盘的行为可能并不像您预想的那样。

假设您有一个名为 DG2 的磁盘组，它包含两个 failgroup（DG2_0000 和

DG2_0001），每个具有一个单独的磁盘，如下图所示：

合集下载

Oracle 11g新特性之模式管理

Oracle 11g新特性之模式管理

DDL Wait 选项

Jill（Acme Retailers 的 DBA）尝试更改名为 SALES 的表，为其添加一列 TAX_CODE。这是很常见的任务；她执行了以下 SQL 语句：

SQL> alter table sales add (tax_code varchar2(10));

但是，她收到了以下消息，而非“Table altered”之类的内容：

alter table sales add (tax_code varchar2(10))*ERROR at

line 1:ORA-00054: resource busy and acquire withNOWAIT

specified or timeout expired

错误消息描述的是：该表目前可能正由一个事务使用，因此要获得该表的独占锁定不太可能。当然，表的行不会永远锁定。当会话执行提交动作后，会释放对这些行的锁定，但在此之前，由于解除锁定期间很长，其他会话可能会更新表的其他行 — 这样，获得表的独占锁定的时机又消失了。在典型的商务环境中，以独占方式锁定表的窗口会定期打开，但 DBA 可能无法恰好在那时执行 alter 命令。

当然，Jill 也可以反复键入相同的命令，直到获得独占锁定或者失败（两者取其先）。

在 Oracle 数据库 11g 中，Jill

有更好的选择：DDL Wait 选项。她可以执行以下命令：

SQL> alter session set ddl_lock_timeout = 10; Session

altered.

现在，如果会话中的 DDL 语句没有获得独占锁定，也不会显示错误消息。相反，它将等待 10 秒钟。在这 10

秒钟内，它将不断重试 DDL 操作，直到成功或超时（两者取其先）。如果执行以下命令：

SQL> alter table sales add (tax_code varchar2(10));

21_11g新特性_压缩

21_11g新特性_压缩

Oracle Database 11g：

面向 DBA 和开发人员的重要特性

压缩

数据压缩支持在 Oracle Database 中并非什么新功能，但 11g 通过 Advanced

Compression 和混合列压缩将此概念提升到新的高度。

Advanced Compression

压缩对于 Oracle 并非新功能；自从 Oracle9i Database 以来，一直围绕着

COMPRESS BASIC 形式。

压缩始终是非常占用 CPU 的过程，并且需要花费一定时间。通常，如果压缩数据，则数据必须解压缩后才能使用。虽然此要求在数据仓库环境（SQL 通常在大量的行上运行，漫长的响应时间通常是可以容忍的）中是可以接受的，但在 OLTP

环境中可能无法接受。

现在，在 Oracle Database 11g 中（但仅限您获得了 Advanced Compression 选件许可的情况下)，您可以进行如下操作：

create table my_compressed_table ( col1 number(20), col2

varchar2(300), ... ) compress for all operations

“compress for all operations”子句在所有 DML 活动（如 INSERT、UPDATE 等）上执行压缩。压缩在所有 DML 活动上发生，而不像前几个版本那样，只在直接路径插入上发生。

这 会降低 DML 的速度吗？不一定。这正是该新特性的最大优点。向表中插入行时不会发生压缩。相反，在插入行时，这些行将被解压缩，然后以常规方式插入。当以解压缩方式插 入（或更新）一定数量的行时，将执行压缩算法并压缩块中所有解压缩的行。换句话说，将压缩块，而不是行。在 RDBMS 代码内部定义压缩发生的阈值。

压缩机制

请看一个 ACCOUNTS 表，它包含以下记录：

关注Oracle 11g新特性

关注Oracle 11g新特性

…　。　一¨ｌ　：　－　－｜　Ｉ　～　

开发出多核芯片。数据库也一样，可　

以以基本的数据库建造数据库中的数据　

库。”Ｎｉｃｋ　Ｅｖｅｒｅｄ说。在数据库的研发　

方面，甲骨文开始把语义数据模型应用　

到Ｏｒａｃｌｅ数据库当中，同时也在构建实　

践驱动的数据库。甲骨文在数据库方面　

新的尝试能否给用户带来更大的价值，　

还有待实践来证明。　

中间件：扩大范畴，支持虚拟化　

“我们不是消极、被动地接受中间　件的定义，而是积极主动地参与。”甲　

骨文公司亚太区Ｏｒａｃｌｅ融合中间件销售　

副总裁Ｒｏｌａｎｄ　Ｓｌｅｅ表示。“把数据库和　

应用链接起来的软件都叫做中间件。”　

比如身份管理软件，Ｒｏｌａｎｄ　Ｓｌｅｅ认为其　

属于中间件的范畴，因为许多客户希望　能够把身份管理融合到解决方案当中。　

通过融合的方式，企业能够降低开发和　应用成本，这也是甲骨文提出扩大中间　

件定义的原因之一。“身份管理”是甲　

骨文一再强调的独特功能，在甲骨文身　

份管理软件中设置有虚拟目录，以简单　

的界面来显示复杂的应用。提及虚拟化　

应用，Ｒｏｌａｎｄ　Ｓｌｅｅ表示，有两种不同的　

服务器虚拟形式，一种是把一个大的主　

机拆分成许多小的计算机，另外一种虚　

拟化是把许多不同的服务器整合到一台　

计算机中，这也是网格计算的原理。甲　

骨文的中间件完全支持虚拟化应用。在　

中间件领域，甲骨文也提到了将来的发　

展方向，即提供全面的解决方案，支持　

开放架构和异构的环境，这与网格计算　

所解决的问题不谋而合。　

应用软件：托管与现场实施的　

“混合体”　相比于数据库和中间件产品，在　应用软件领域，甲骨文起步相对较晚。　

在完成了三十几次的收购之后，甲骨　

文建立起自己的应用软件产品线。在　

亚太地区，定制软件的需求量在不断　

增加，甲骨文如何能帮助客户更容易　

地应用定制软件？甲骨文公司应用产　

品战略高级副总裁Ｊｅｓｐｅｒ　Ａｎｄｅｒｓｅｎ表　

示，目前甲骨文正在开发一种通用程　

序，以实现让甲骨文的软件能够在各　

11g新特性-安全

11g新特性-安全

一．密码安全

为了遵守各种安全性和隐私规定，必须使用更安全的口令。如果口令非常短或仅包含有限的字符，则对于强力攻击就很脆弱，而包含较多不同字符的较长口令就很难被猜出或获得。

在Oracle Database 11g中，口令的处理方式与早期版本中的处理方式有所不同：

(1) 口令区分大小写。口令中使用的大写字符和小写字符现在是不同的字符。

(2) 口令可以包含未用引号括起来的多字节字符。如果口令包含除$、_ 或# 外的任何特殊字符，则必须用引号括起来。

(3) 口令始终通过散列算法传递，然后作为用户身份证明进行存储。用户提供口令时，系统会对其进行散列运算，然后将其与存储的身份证明进行比较。在Oracle Database

(4) 11g 中，散列算法是早期版本数据库中使用的公共算法SHA-1。SHA-1 是一种使用160 位密钥的较强算法。

(5) 口令始终使用salt。如果输入内容相同，散列函数将始终生成相同的输出。Salt是添加到输入中的唯一（随机）值，用于确保输出身份证明是唯一的。

OracleDatabase 11g 中的口令：

(1) 区分大小写

(2) 包含更多的字符

(3) 使用更安全的散列算法

(4) 在散列算法中使用salt

用户名仍是Oracle 标识符（最多30个字符，不区分大小写）。

之前整理的Blog：

Oracle10g/11g 密码策略 用户口令 大小写敏感 说明

/tianlesoftware/article/details/7383110

二．自动安全配置

Oracle Database11g 使用由Internet 安全中心(CIS) 基准推荐的特定安全功能安装和创建数据库。与10gR2 的默认安装相比，CIS 推荐的配置更安全，而且开放程度足以使大多数应用程序都能成功运行。许多客户已采用了此基准。CIS 基准的一些建议可能与一些应用程序不兼容。