eygle.com   eygle.com
eygle.com  
 
Digest Net: March 2007 Archives

March 2007 Archives

Oracle OpenWorld HA Presentations

Oracle Maximum Availability Architecture

Source Link: http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm

Quick Links




What is Oracle Maximum Availability Architecture?

Oracle Maximum Availability Architecture (MAA) is Oracle's best practices blueprint based on proven Oracle high availability technologies and recommendations. The goal of MAA is to remove the complexity in designing the optimal high availability architecture.

Background

Businesses today operate in a highly networked, 24x7 global economy. They cannot afford to be down, and the IT systems supporting today’s businesses have to be reliable and always available. However, as more system capabilities are introduced, IT managers, architects and administrators often find it difficult to integrate a suitable set of features to build the unified high availability (HA) solution that fits all of their business requirements. In the absence of any clear and cohesive direction, IT managers often rely on hiring a team of consultants and go through hundreds of pages of documentation to determine the appropriate HA systems configuration, that in turn - may, or may not solve their unique business availability needs.

This is where MAA comes in. MAA has been conceptualized with the philosophy that designing an HA system involving Oracle technologies should not be complex, and should not involve any guesswork. With this goal, the MAA framework provides various in-depth best practices using Oracle's proven HA and grid computing technologies to help maximize systems availability and meet the highest SLA requirements for a business.

MAA Features

  • MAA involves HA best practice recommendations for a comprehensive set of Oracle products - Oracle Database, Oracle Application Server, Oracle Applications, Oracle Collaboration Suite, Grid Control. These best practices include architectural, configuration and operational best practices.
  • MAA considers various business SLAs to make these best practices as widely applicable as possible.
  • MAA leverages database grid servers with commodity servers and storage grid with resilient low cost storage to provide highly resilient, lower cost infrastructure.
  • MAA evolves with new Oracle versions and features.
  • MAA is hardware and OS independent.

MAA Benefits

  • MAA reduces the implementation costs for a highly available Oracle system by providing detailed configuration guidelines. The results of performance impact studies for different configurations are highlighted to ensure that the chosen highly available architecture can continue to perform and scale accordingly to business needs.
  • MAA reduces possible costs of downtime by providing best practices to eliminate or minimize downtime that could occur because of scheduled and unscheduled outages such as human errors, system faults and crashes, maintenance, data failures, corruptions, and disasters.
  • MAA gives the ability to control the length of time to recover from an outage and the amount of acceptable data loss under disaster conditions thus allowing mean time to recovery (MTTR) to be tailored to specific business requirements.

MAA Best Practice Publications

MAA publications consist of a series of architectural, configuration and operational HA best practice blueprints on various Oracle technologies. For example, the following diagram represents an HA architecture involving the Oracle Database and Oracle Application Server.


Fig. 1: Example of an HA Configuration using MAA Best Practices


This architecture involves identically configured primary and secondary sites. The primary site contains multiple application servers and a production database using Oracle Real Application Clusters (RAC) to protect from host and instance failures. The secondary site also contains similarly configured application servers, and a physical standby database kept synchronized with the primary database by Oracle Data Guard. Clients are initially routed to the primary site. If a severe outage affects the primary site, Data Guard fails over the production database role to the standby database, following which clients may be directed to this new primary database at the secondary site, thereby resuming business availability.

The various HA best practice publications are grouped under the following categories:


HA Best Practices for Oracle Database

Oracle Database 10g Release 2

Oracle Database 10g Release 1 Oracle Database 10g - General

Oracle9iDatabase



HA Best Practices for Oracle Application Server

Oracle Application Server 10g Release 2

Oracle Application Server 10g



HA Best Practices for Oracle Applications

HA Best Practices for Oracle Collaboration Suite


HA Best Practices for Oracle Grid Control

Oracle Enterprise Manager 10g Release 2 and Release 3

Oracle Enterprise Manager 10g Release 1

Additional HA-related Information

Please visit the following links for additional HA-related information in various Oracle product areas:


MAA Presentations at Oracle OpenWorld

Oracle OpenWorld 2006
Oracle OpenWorld 2005
  • Best Practices To Achieve Business Continuity Using Oracle Applications and Oracle Database Technology - Presentation, Paper
  • What They Don't Print in the Doc - HA Best Practices by Gurus from Oracle's Maximum Availability Architecture Team - Presentation, Paper
  • Best Practices for Automatic Failover Using Oracle Data Guard 10g Release 2 - Presentation, Paper

Oracle MAA and Vendor Partnerships

The Oracle Maximum Availability Architecture focuses on complete solutions and best practices. As an integral part of these solutions our vendor partners also play key and complementary roles in enterprise customer deployments and therefore in MAA as well. For these reasons the Oracle MAA team also works closely with our vendor partners to ensure we can deliver complete and robust solutions to our customers. Below are the best practices and case studies done through these joint efforts.

F5
Foundry Networks
HP

Additional joint projects are currently in progress which will also have papers available soon:
  • SUN - Transitioning E-Business Suite to the Maximum Availability Architecture on SUN Systems: E-Business Suite 11i.10.2 and Database 10gR2
  • Engenio - Oracle’s Maximum Availability Architecture and Engenio’s Resilient Low Cost Storage Solution
Active Oracle MAA partners include: SUN, HP, Engenio, Apple, EMC and F5.

The MAA Team

The MAA team is a group of technical HA engineering experts with deep-domain expertise in designing, developing, implementing, deploying and supporting various Oracle and systems technologies at customer sites worldwide. This team is responsible for developing specific HA-oriented product capabilities, as well as working very closely with other internal engineering teams, consultants and enterprise customers with the goal to disseminate best-of-breed HA architecture and practices. The team’s close relationship and involvement with the different product engineers and their constant interaction with selected customers allow them to tailor these best practices to a wide variety of customer needs, and also provide and influence specific product enhancements and general future product directions.

Contact

Oracle Consulting Services (OCS) offers highly specialized consultants to efficiently lead the implemention of MAA solutions. If you are interested in a quote for services, please send an overview of your MAA requirements to MAA-NorthAmerica-OCS_us@oracle.com in North America or MAA-EMEA-OCS_ww@oracle.com in EMEA. (Other regional contact points will be set up soon.)

You may also contact maa_ww@oracle.com if you have specific questions/feedback related to the MAA best practice publications, or if you have any suggestions on important HA topics that are not currently covered by MAA.

Please note that these email lists may not be used for MAA support or general MAA-related questions - please contact Oracle Support for your MAA questions/support issues.

Oracle10g 的等待界面

原文链接 等待界面

10g 等待界面为还没有被 ADDM 捕获的即时性能问题提供了有价值的诊断数据

“数据库太慢了!”

这句话通常出自一位严格的用户之口。如果您和我一样,那么在您的 DBA 生涯中您肯定无数次听到过这句话。

那么,您又怎样解决该问题呢?除了对用户置之不理之外(这是我们大多数人都不敢奢望的想法),您可能要做的第一件事就是查看是否有任何会话在等待数据库内部或外部的任何事件。

Oracle 提供了一个简单但一流的机制来达到此目的:V$SESSION_WAIT 视图。该视图显示了有助于您的诊断的各种信息,如一个会话正在等待或已经等待的事件,以及等待了多长时间和多少次。例如,如果会话在等待事件 "db file sequential read",列 P1 和 P2 将显示会话正在等待的块的 file_id 和 block_id。

对于大多数等待事件而言,这个视图足够了,但它还不是一个强健的调整工具,之所以如此说,至少是因为以下两个重要原因:
  • 该视图是当前情况的一个快照。当等待不再存在时,会话先前出现的那些等待的历史也将消失,从而使得事后诊断非常困难。V$SESSION_EVENT 提供了累积的但不是非常详细的数据。
  • V$SESSION_WAIT 包含了只与等待事件相关的信息;要获得所有其它的相关信息(如用户 ID 和终端),您必须将它和 V$SESSION 视图结合使用。

在 Oracle 数据库 10g 中,等待界面经过了彻底的重新设计,从而只需更少的 DBA 干预即可提供更多的信息。在本文中,我们将浏览这些新的特性,并了解它们如何帮助我们诊断性能问题。对于大多数性能问题,您可以从自动数据库诊断管理器 (ADDM) 中获得扩展分析,但对于还没有被 ADDM 捕获的即时问题,等待界面将提供有价值的诊断数据。

增强的会话等待

第一个增强涉及到 V$SESSION_WAIT 本身。这一点通过示例可以很好地说明。

假定您的用户抱怨会话挂起了。您查明了该会话的 SID,并在 V$SESSION_WAIT 视图中选中了该 SID 的记录。输出显示如下。

SID                      : 269
SEQ#                     : 56
EVENT                    :enq:TX - row lock contention
P1TEXT                   :name|mode
P1                       : 1415053318
P1RAW                    : 54580006
P2TEXT                   :usn<<16 | slot
P2                       : 327681
P2RAW                    : 00050001
P3TEXT                   :sequence
P3                       : 43
P3RAW                    :0000002B
WAIT_CLASS_ID            : 4217450380
WAIT_CLASS#              : 1
WAIT_CLASS               : Application
WAIT_TIME                : -2
SECONDS_IN_WAIT          : 0
STATE                    :WAITED UNKNOWN TIME

注意以黑体显示的列;在这些列中,WAIT_CLASS_IDWAIT_CLASS#WAIT_CLASS 是 10g 中新增的列。列 WAIT_CLASS 指示等待的类型,必须将其作为有效的等待事件解决或者作为空闲的等待事件退出。在上面的例子中,等待类显示为 Application,这表示它是一个需要您注意的等待。

该列突出显示那些能够证明与您的调整最相关的少数几条记录。例如,您可以使用如下查询来获取事件的等待会话。

select wait_class, event, sid, state, wait_time, seconds_in_wait
from v$session_wait
order by wait_class, event, sid
/

下面是一个样例输出:

WAIT_CLASS  EVENT                       SID STATE                WAIT_TIME SECONDS_IN_WAIT
----------  -------------------- ---------- ------------------- ---------- ---------------
Application enq:TX -                   269 WAITING                      0              73
row lock contention        
Idle        Queue Monitor Wait          270 WAITING                      0              40
Idle        SQL*Net message from client 265 WAITING                      0              73
Idle        jobq slave wait             259 WAITING                      0            8485
Idle        pmon timer                  280 WAITING                      0              73
Idle        rdbms ipc message           267 WAITING                      0          184770
Idle        wakeup time manager         268 WAITING                      0              40
Network     SQL*Net message to client   272 WAITED SHORT TIME           -1               0

在这,您可以看到几个事件(如 Queue Monitor WaitJobQueue Slave)被明确地归为 Idle 事件。您可以将它们作为非阻塞等待消除掉;不过,有时这些“空闲”事件可能指示一个内在的问题。例如,与 SQL*Net 相关的事件可能指示高网络延迟(除其他因素外)。

另一件要注意的重要的事情是,WAIT_TIME 的值为 -2。某些平台(如 Windows)不支持快速计时机制。如果在这些平台上没有设定初始化参数 TIMED_STATISTICS,那么将无法获得准确的计时统计数据。在这种情况下,在 Oracle9i 中,该列将显示一个非常大的数字,这使问题变得更加不清晰。在 10g 中,值 -2 指示这种情况 — 平台不支持快速定时机制并且没有设定 TIMED_STATISTICS。(对于本文剩下的部分,我们将假定存在一个快速计时机制。)

会话也显示等待

记得长期以来一直需要将 V$SESSION_WAIT 与 V$SESSION 结合使用以获得有关会话的其他详细信息吗?嗯,这已经成为历史了。在 10g 中,V$SESSION 视图还显示由 V$SESSION_WAIT 显示的等待。下面是 V$SESSION 视图其余的列,这些列显示了会话当前等待的等待事件。

EVENT#                     NUMBER
EVENT                      VARCHAR2(64)
P1TEXT                     VARCHAR2(64)
P1                         NUMBER
P1RAW                      RAW(4)
P2TEXT                     VARCHAR2(64)
P2                         NUMBER
P2RAW                      RAW(4)
P3TEXT                     VARCHAR2(64)
P3                         NUMBER
P3RAW                      RAW(4)
WAIT_CLASS_ID              NUMBER
WAIT_CLASS#                NUMBER
WAIT_CLASS                 VARCHAR2(64)
WAIT_TIME                  NUMBER
SECONDS_IN_WAIT            NUMBER
STATE                      VARCHAR2(19)

这些列与 V$SESSION_WAIT 中的那些列相同,且显示相同的信息,从而不再需要在那个视图中查看它们了。因此,对于等待任意事件的任意会话,您仅需要查看一个视图。

让我们回到原来的问题:SID 为 269 的会话正等待事件 enq:TX — row lock contention,指示它正等待被另一个会话占用的锁。要诊断该问题,您必须识别占用锁的那个会话。但您如何才能做到这一点?

在 Oracle9i 及更低版本中,您可能得编写复杂(和极耗资源)的查询来获得占用锁的会话的 SID。而在 10g 中,您所要做的就是执行以下查询:

select BLOCKING_SESSION_STATUS, BLOCKING_SESSION
from v$session 
where sid = 269

BLOCKING_SE BLOCKING_SESSION
----------- ----------------
VALID                    265

找到了:SID 为 265 的会话阻塞了会话 269。还能更容易吗?

有多少等待?

用户仍然在缠着您,因为用户的问题仍然没有得到满意的解答。为什么用户的会话花了这么长时间才完成?您可以执行以下命令来找出原因:

select * from v$session_wait_class where sid = 269;

输出返回为:

SID SERIAL# WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS    TOTAL_WAITS TIME_WAITED
---- ------- ------------- ----------- ------------- ----------- -----------
269    1106    4217450380           1 Application           873      261537
269    1106    3290255840           2 Configuration           4           4
269    1106    3386400367           5 Commit                  1           0
269    1106    2723168908           6 Idle                   15      148408
269    1106    2000153315           7 Network                15           0
269    1106    1740759767           8 User I/O               26           1

注意这里有关会话等待的大量信息。现在您知道了,该会话已经为与应用程序相关的等待等待了 873 次(共 261,537 厘秒),在与网络相关的事件中等待了 15 次等等。

以此类推,您可以使用以下查询来查看系统范围的等待类的统计数据。同样,时间是以厘秒为单位的。

select * from v$system_wait_class;

WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS    TOTAL_WAITS TIME_WAITED
------------- ----------- ------------- ----------- -----------
1893977003           0 Other                2483       18108
4217450380           1 Application          1352      386101
3290255840           2 Configuration          82         230
3875070507           4 Concurrency            80         395
3386400367           5 Commit               2625        1925
2723168908           6 Idle               645527   219397953
2000153315           7 Network              2125           2
1740759767           8 User I/O             5085        3006
4108307767           9 System I/O         127979       18623

大多数问题不是孤立出现的;它们留下了揭示真相的线索,模式可以识别这些线索。可以按如下方式从等待类的一个历史视图中查看模式。

select * from v$waitclassmetric;

这个视图存储了最后一分钟内与等待类相关的统计数据。

select wait_class#, wait_class_id, 
average_waiter_count "awc", dbtime_in_wait,
time_waited,  wait_count
from v$waitclassmetric
/

WAIT_CLASS# WAIT_CLASS_ID  AWC DBTIME_IN_WAIT TIME_WAITED WAIT_COUNT
----------- ------------- ---- -------------- ----------- ----------
          0    1893977003    0              0           0          1
          1    4217450380    2             90        1499          5
          2    3290255840    0              0           4          3
          3    4166625743    0              0           0          0
          4    3875070507    0              0           0          1
          5    3386400367    0              0           0          0
          6    2723168908   59              0      351541        264
          7    2000153315    0              0           0         25
          8    1740759767    0              0           0          0
          9    4108307767    0              0           8        100
         10    2396326234    0              0           0          0
         11    3871361733    0              0           0          0

注意 WAIT_CLASS_ID 和相关的统计数据。对于值 4217450380,我们看到 2 个会话在最后一分钟内总共等待了该类 5 次(1,499 厘秒)。但该等待类是什么?您可以从 V$SYSTEM_WAIT_CLASS 中获取这一信息(如上所示)— 就是 Application 类。

注意名称为 DBTIME_IN_WAIT 的列,这是一个非常有用的列。在我们第 6 周关于自动工作负载信息库 (AWR) 的部分中,您可能还记得在 10g 中是以更细粒化的方式来报告时间的,并且可以确定在数据库中花费的准确时间。DBTIME_IN_WAIT 显示在数据库中花费的时间。

一切都留有线索

用户终于离开了,您长舒了一口气。但您可能仍然想寻根究底,希望查明主要是哪些等待造成用户会话中的问题。当然,您可以通过查询 V$SESSION_WAIT 而轻易地得到答案 — 但不幸的是,等待事件现在不存在了,因此该视图没有它们的任何记录。您该怎么办?

在 10g 中,自动保留活动会话最后 10 个事件的会话等待历史。这个历史可通过 V$SESSION_WAIT_HISTORY 视图查看。要找出这些事件,您可以简单地执行:

select event, wait_time, wait_count
from v$session_wait_history
where sid = 265
/

EVENT                           WAIT_TIME WAIT_COUNT
------------------------------ ---------- ----------
log file switch completion              2          1
log file switch completion              1          1
log file switch completion              0          1
SQL*Net message from client         49852          1
SQL*Net message to client               0          1
enq:TX - row lock contention          28          1
SQL*Net message from client           131          1
SQL*Net message to client               0          1
log file sync                           2          1
log buffer space                        1          1

当会话变为非活动状态或断开时,记录从该视图中消失。不过,这些等待的历史保留在 AWR 表中,以便进一步分析。从 AWR 中显示会话等待的视图是 V$ACTIVE_SESSION_HISTORY。(同样,有关 AWR 的更多信息,请参考本系列的第 6 周。)

结论

通过 Oracle 数据库 10g 中的等待模型的增强,分析性能问题变得非常容易。提供的会话等待历史可以帮助您在会话经历等待后诊断问题。将等待归为各种等待类还有助于您了解每种类型等待所造成的影响,这在研究正确的纠正方法时将带来便利。

有关等待事件动态性能视图和等待事件本身的更多信息,请参考《Oracle 数据库性能调整指南 10g 第 1 版 (10.1)》的第 10 章

Oracle10g 自动工作负载信息库

原文链接 自动工作负载信息库

学习使用新的特性,这些特性采集数据库性能统计数据和量度,以供分析和调整,并显示在数据库中花费的准确时间,甚至保存会话信息

当您有数据库性能问题时,要解决它您首先要作的是什么?一种常见的方法是看是否存在一种模式:回答诸如“相同的问题是否重复出现?”,“它是否在某个特定的时间段出现?”和“两个问题之间是否有联系?”之类的问题,将几乎总会带来更好的诊断结果。

作为一个数据库管理员,您可能已经投资购买了第三方工具或使用自己开发的工具来在数据库运行期间采集详细的统计数据,并从这些统计数据中导出获得性能量度。在紧急的情况下,您可以访问这些量度来与当前的情况作比较。再度查看这些过去的事件可以给当前的问题带来一些启发,因此不断采集相关的统计数据对于性能分析变得很重要。

一段时间以来,Oracle 在这个领域中的解决方案是它内置的工具 Statspack。虽然某些情况下证明它是非常有价值的,但常常缺少性能故障诊断实践所需的强健性。Oracle Database 10g 提供了一个显著改进的工具:自动工作负载信息库 (AWR)。AWR 和数据库一起安装,不但采集统计数据,还采集导出的量度。

快速测试驱动程序

通过运行 $ORACLE_HOME/rdbms/admin 目录中的 awrrpt.sql 脚本,AWR 的功能可以立即通过它从采集的统计数据和量度中生成的报表得到最好的说明。这个脚本从外观和感觉上类似于 Statspack,它显示所有的现有 AWR 快照并请求两个特定的快照作为时间间隔边界。它产生两种类型的输出:文本格式(类似于 Statspack 报表的文本格式但来自于 AWR 信息库)和默认的 HTML 格式(拥有到部分和子部分的所有超链接),从而提供了非常用户友好的报表。现在运行该脚本以查看报表,从而对 AWR 的功能有一个了解。

实施

现在,让我们来看看 AWR 是如何设计和构建的。AWR 实质上是一个 Oracle 的内置工具,它采集与性能相关的统计数据,并从那些统计数据中导出性能量度,以跟踪潜在的问题。与 Statspack 不同,快照由一个称为 MMON 的新的后台进程及其从进程自动地每小时采集一次。为了节省空间,采集的数据在 7 天后自动清除。快照频率和保留时间都可以由用户修改。要查看当前的设置,您可以使用下面的语句:

select snap_interval, retention
from dba_hist_wr_control;

SNAP_INTERVAL       RETENTION
------------------- -------------------
+00000 01:00:00.0   +00007 00:00:00.0

这些 SQL 语句显示快照每小时采集一次,采集的数据保留 7 天。要修改设置 例如,快照时间间隔为 20 分钟,保留时间为两天 您可以发出以下命令。参数以分钟为单位。

begin
   dbms_workload_repository.modify_snapshot_settings (
      interval => 20,
      retention => 2*24*60
   );
end;

AWR 使用几个表来存储采集的统计数据,所有的表都存储在新的名称为 SYSAUX 的特定表空间中的 SYS 模式下,并且以 WRM$_*WRH$_* 的格式命名。前一种类型存储元数据信息(如检查的数据库和采集的快照),后一种类型保存实际采集的统计数据。(您可能已经猜到,H 代表“历史数据 (historical)”而 M 代表“元数据 (metadata)”。)在这些表上构建了几种带前缀 DBA_HIST_ 的视图,这些视图可以用来编写您自己的性能诊断工具。视图的名称直接与表相关;例如,视图 DBA_HIST_SYSMETRIC_SUMMARY 是在WRH$_SYSMETRIC_SUMMARY 表上构建的。

AWR 历史表采集的信息比 Statspack 多许多,这些信息包括表空间使用率、文件系统使用率、甚至操作系统统计数据。这些表的完整的列表可以通过以下命令从数据字典中看到:

select view_name from user_views where view_name like 'DBA\_HIST\_%' escape '\';

视图 DBA_HIST_METRIC_NAME 定义 AWR 采集到的重要的量度、它们所属的组和采集它们的单位。例如,下面是一个记录(竖直格式):

DBID                  : 4133493568
GROUP_ID              : 2
GROUP_NAME            : System Metrics Long Duration
METRIC_ID             : 2075
METRIC_NAME           : CPU Usage Per Sec
METRIC_UNIT           : CentiSeconds Per Second 

它显示一个量度“每秒 CPU 使用率”以“每秒的厘秒数”为单位进行测量,并且该量度属于一个量度组 “System Metrics Long Duration”。这条记录可以和其它的表(如 DBA_HIST_SYSMETRIC_SUMMARY)结合,以获得数据库的活动信息,形式如下:

select begin_time, intsize, num_interval, minval, maxval, average, standard_deviation sd 
from dba_hist_sysmetric_summary where metric_id = 2075;

BEGIN    INTSIZE NUM_INTERVAL   MINVAL  MAXVAL  AVERAGE           SD
----- ---------- ------------   ------- ------- --------  ----------
11:39     179916           30         0      33        3  9.81553548
11:09     180023           30        21      35       28  5.91543912

... and so on ...

下面我们看看 CPU 时间是如何消耗的(以厘秒为单位)。标准差加入到了我们的分析中,它有助于确定平均数字是否反映了实际的工作负载。在第一条记录中,平均值是每秒消耗 CPU 时间 3 厘秒,但标准差是 9.81,这意味着平均值 3 不能反映工作负载。在第二个例子中,平均值为 28,标准差为 5.9,这更具有代表性。这种类型的信息趋势有助于了解几个环境参数对性能量度的影响。

使用统计数据

迄今为止,我们看到了 AWR 所采集的内容,现在让我们看看它将如何处理数据。

大多数性能问题并不是孤立存在的,而留有指示性的迹象,这些迹象将通向问题最终的根源。让我们使用一个典型的调整实践来说明这一点:您注意到系统很慢,于是决定查看等待的原因。您检查发现“缓冲区忙等待”非常高。问题可能出在哪里呢?有几种可能:可能有一个单调增加的索引,可能一个表太满了,以至于要求将单个数据块非常快速地加载到内存中,或其它一些因素。无论在哪种情况下,您都首先要确定存在问题的段。如果它是一个索引段,那么您可以决定重新构建它,把它修改为一个反向键索引,或把它转换成一个在 Oracle Database 10g 中引进的散列分区索引。如果它是一个表,您可以考虑修改存储参数来使它不那么密集,或者利用自动段空间管理把它转移到一个表空间中。

您的处理计划一般是有规律的,并且通常基于您对各种事件的了解和您处理它们的经验。现在设想相同的事情由一个引擎来完成,这个引擎采集量度并根据预先确定的逻辑来推出可能的计划。您的工作不就变得更轻松了吗?

现在在 Oracle Database 10g 中推出的这个引擎称为自动数据库诊断监控程序 (ADDM)。为了作出决策,ADDM 使用了由 AWR 采集的数据。在上面的讨论中,ADDM 可以看到发生了缓冲区忙等待,然后取出相应的数据来查看发生缓冲区忙等待的段,评估其特性和成分,最后为数据库管理员提供解决方案。在 AWR 进行的每一次快照采集之后,调用 ADDM 来检查量度并生成建议。因此,实际上您拥有了一个一天二十四小时工作的自动数据库管理员,它主动地分析数据并生成建议,从而把您解放出来,使您能够关注更具有战略意义的问题。

要查看 ADDM 建议和 AWR 信息库数据,请使用在名称为 DB Home 的页面上的新的 Enterprise Manager 10g 控制台。要查看 AWR 报表,您可以从管理转至工作负载信息库,然后转至 Snapshots 来查看它们。在以后的部分中,我们将更详细地讨论 ADDM。

您还可以指定根据特定的情况来生成警报。这些警报称为服务器生成警报,它们被推送到高级队列中,在其中它们可以被任意监听它的客户端使用。一个这样的客户端是 Enterprise Manager 10g,在其中警报被突出显示。

时间模型

当您有性能问题时,要缩短响应时间您最先想到的是什么?很明显,您希望消除(或减少)增加时间的因素的根源。您如何知道时间花费在哪里 不是等待,而是真正在进行工作?

Oracle Database 10g 引进了时间模型,以确定在各个地方花费的时间。花费的总的系统时间记录在视图 V$SYS_TIME_MODEL 中。下面是查询和输出结果。

STAT_NAME                                     VALUE
-------------------------------------         --------------
DB time                                       58211645
DB CPU                                        54500000
background cpu time                           254490000
sequence load elapsed time                    0
parse time elapsed                            1867816
hard parse elapsed time                       1758922
sql execute elapsed time                      57632352
connection management call elapsed time       288819
failed parse elapsed time                     50794
hard parse (sharing criteria) elapsed time    220345
hard parse (bind mismatch) elapsed time       5040
PL/SQL execution elapsed time                 197792
inbound PL/SQL rpc elapsed time               0
PL/SQL compilation elapsed time               593992
Java execution elapsed time                   0
bind/define call elapsed time                 0 

注意名称为 DB Time 的统计量,它代表自从例程启动起在数据库中花费的时间。运行示例工作负载,并再次从视图中选中统计值。统计值的差异将代表该工作负载在数据库中花费的时间。在又一个调整回合之后,执行相同的分析,统计值的差异将显示在调整之后 DB Time 的变化,这可以与第一次修改进行比较,以查看调整动作对数据库时间的影响。

除数据库时间之外,V$SYS_TIME_MODEL 视图显示了很多其它的统计量,如在不同类型的分析,甚至在 PL/SQL 编译中花费的时间。

这个视图还显示了总的系统时间,不过您可能对一个更加详细的视图感兴趣:会话级时间。时间统计数据还在会话级进行采集,如视图 V$SESS_TIME_MODEL 中所示,在其中可以看到当前连接的会话(活动和不活动的)的所有统计数据。额外的列 SID 指示显示的统计数据的会话的 SID。

在早期的版本中,这种分析是不可能得到的,用户被迫进行猜测或从各种来源进行分析。在 Oracle Database 10g 中,获得这种信息轻而易举。

活动会话历史

Oracle Database 10g 中的视图 V$SESSION 得到了改善;所有这些改善中最有价值的是包含了等待事件和它们的持续时间,从而不再需要查看视图 V$SESSION_WAIT。不过,因为这个视图只反映实时的值,所以当稍后查看它时,一些重要的信息丢失了。例如,如果您选择从这个视图中检查是否有任何会话在等待任何非空闲的事件,如果有的话,调查这个事件,您可能发现不了任何东西,因为到您选中它的时候等待一定已经结束了。

进入新的特性活动会话历史 (ASH),它类似于 AWR,在一个缓冲区中存储会话性能统计数据,以便稍后进行分析。不过,与 AWR 不同,存储不是永久性地在一个表中进行,而是在内存中进行,并在视图 V$ACTIVE_SESSION_HISTORY 中显示。数据每秒轮询一次,并且只有轮询活动会话。随着时间进行,旧的项目在一个循环缓冲区中被删除,以容纳新的项目,并且这些旧的项目将在视图中显示。要找出有多少个会话在等待某些事件,您可以使用下面的命令

select session_id||','||session_serial# SID, n.name, wait_time, time_waited
from v$active_session_history a, v$event_name n
where n.event# = a.event#

这条命令告诉您事件的名称和等待花费了多少时间。如果您想要深入调查某个特定的等待事件,ASH 的额外的列也将帮助您实现这一目的。例如,如果会话等待的事件之一是缓冲区忙等待,那么正确的诊断必须指出发生等待事件的段。您可以从 ASH 视图列 CURRENT_OBJ# 中获得这一信息,然后该列可以和 DBA_OBJECTS 结合,以获得存在问题的段。

ASH 还记录并行查询服务器会话,这对诊断并行查询等待事件非常有用。如果记录是针对一个并行查询从属进程,那么协调服务器会话的 SID 由 QC_SESSION_ID 列指定。列 SQL_ID 记录产生等待事件的 SQL 语句的 ID,该列可以和 V$SQL 视图结合,以获取存在问题的 SQL 语句。为了方便一个共享用户环境(如 web 应用程序)中的客户端的识别,也显示了 CLIENT_ID 列,这可以由 DBMS_SESSION.SET_IDENTIFIER 来设置。

既然 ASH 信息这么有价值,那么如果以一种类似于 AWR 的永久方式来保存这种信息不是很好吗?幸运的是,它是以这种方式来进行保存的;由 MMON 从进程将信息刷新到 AWR 表中,从而保存在磁盘上,并且信息可以通过视图 DBA_HIST_ACTIVE_SESS_HISTORY 来查看。

人工采集

快照默认是自动采集的,但您也可以按需要采集它们。所有的 AWR 功能都在程序包 DBMS_WORKLOAD_REPOSITORY 中实施。要采集一次快照,只需发出下面的命令:

execute dbms_workload_repository.create_snapshot

它立即采集一次快照,快照被记录在表 WRM$_SNAPSHOT 中。采集的量度是针对 TYPICAL 级别的。如果您想采集更详细的统计数据,您可以在上面的过程中将参数 FLUSH_LEVEL 设置为 ALL。统计数据自动删除,但也可以通过调用过程 drop_snapshot_range() 来手动删除。

基准线

一次典型的性能调整实践从采集量度的基准线集合、作出改动、然后采集另一个基准线集合开始。可以比较这两个集合来检查所作的改动的效果。在 AWR 中,对现有的已采集的快照可以执行相同类型的比较。假定一个名称为 apply_interest 的高度资源密集的进程在下午 1:00 到 3:00 之间运行,对应快照 ID 56 到 59。我们可以为这些快照定义一个名称为 apply_interest_1 的基准线:

exec dbms_workload_repository.create_baseline (56,59,'apply_interest_1')

这一操作将快照从 56 到 59 编号,作为上面指定的基准线的一部分。查看现有的基准线:

select * from dba_hist_baseline;

      DBID BASELINE_ID BASELINE_NAME        START_SNAP_ID END_SNAP_ID
---------- ----------- -------------------- ------------- -----------
4133493568           1 apply_interest_1                56          59

在一些调整步骤之后,我们可以创建另一个基准线 假设名称为 apply_interest_2,然后只为那些与这两条基准线相关的快照比较量度。像这样把快照分隔在仅仅几个集合中有助于研究调整对于性能量度的影响。您可以在分析之后使用 drop_baseline() 来删除基准线;快照将保留。此外,当清除例程开始删除旧的快照时,与基准线相关的快照不会被清除,从而允许进行进一步的分析。

结论

这一部分的目的只是介绍 AWR 非常基本的方面。关于更完整的内容,请参见 Oracle Database 10g 文档。此外,关于 AWR 和 ADDM 的一个极好的论述可以在技术白皮书自我管理的数据库:自动性能诊断中找到。在第 15 周,您将了解到关于 ADDM 及使用它来解决实际问题的更多内容,。

Oracle Enterprise Manager 10g

原文链接 Enterprise Manager 10g

最后,讨论一种管理和运用 Oracle 的一站式工具 — 无论对于初学者还是专家

您在日常的 DBA 相关活动中使用什么工具?我最近在一个用户群会议中提出了这个问题。

答案依 DBA 的工作经验而有所不同。大部分高级管理员偏爱简单的命令行 SQL*Plus(我的个人偏好),而其余的人则偏爱使用一些第三方产品。但是,同一个问题在入门级 DBA 那里却得到了不同反应:在这一群体中,Enterprise Manager (EM) 显然是他们的选择。

这些偏好不难理解。Oracle Enterprise Manager 自从几年前推出以来一直不断进行完善,它开始时是字符模式显示的 SQL*DBA,随后发展为基于操作系统的客户端工具,最后具有了 Java 风格。EM 提供的信息非常详细,足够完成大多数 DBA 任务,可作为不愿或者无暇了解新语法并且希望使用 GUI 工具来管理常见数据库任务(如添加用户、修改数据文件和检查回退段)的用户的解决方案。诊断程序包为性能调节提供了非常需要的 GUI 支持。

但是,阻碍 EM 广泛使用的一个主要问题是它无法跟上数据库服务器本身的发展。例如,EM 的 Oracle9i 数据库版本不支持子分区(该特性在 Oracle8i 中首次引入)。

Oracle 数据库 10g 中的 EM 新版本改变了这种情况。它具有新的体系结构和新的界面,而最重要的是,它具有一个功能非常强大而完善的工具箱,提供从初学者到高级用户所需的所有 DBA 技能集。而最好之处在于,它是安装本身的一部分,无需额外费用。如果您正在评估第三方工具,您当然可以将 EM 加入评估行列中,从而使竞争更加激烈。即使您是那种“笃信命令行”的 DBA(象我这样),您也会非常欣赏 EM 在某些情况下能为您所提供的帮助。

在本文中,我将为您介绍新的 EM。由于该工具所涉范围甚广,因此不可能在此讨论所有的特性;我将在此介绍几个基本特性,并提供其他材料的线索。我将遵循本系列之精神提供实际的示例,演示如何使用该工具解决实际问题。

体系结构

缺省情况下,在安装 10g 软件时,即安装 EM 10g时,在概念上它与以前版本的不同之处在于,它不是客户端安装的工具;实际上它是位于数据库服务器本身上的 HTTP 服务器(称为 DB 控制台)。(参见图 1。)您可以使用任何浏览器查看 EM 界面。

图 1
图 1:EM 体系结构

DB 控制台的端口号可在 $ORACLE_HOME/install/portlist.ini 中找到。以下是一个文件的示例;对于您来说,端口可能不相同。

Ultra Search HTTP port number = 5620
iSQL*Plus HTTP port number = 5560
Enterprise Manager Agent Port =
Enterprise Manager Console HTTP Port (starz10) = 5500
Enterprise Manager Agent Port (starz10) = 1830

从这个文件中我们了解到,数据库 starz10 的代理程序监听端口 1830,而 EM 控制台监听 5500。我们可以通过输入以下 URL 来调用 EM 登录画面:

http://starz/em/console/logon/logon

该 URL 调出登录画面,从中您可以以 DBA 用户登录。在我们的示例中,我们将以 SYS 登录。

主数据库主页

登录后即出现主数据库主页。主页的上部提供对重要细节的快速浏览。(参见图 2。)

图 2
图 2:主数据库主页(上部)

在上图中已圈出了最重要的一些部分,并用本文中编号的引用对其进行了标注。首先,请注意标为“General”(1) 的部分;这一部分显示了有关数据库的一些最基本细节,如数据库从 3 月 20 日起已经启动,以及实例名称等。Oracle Home 显示为一个超链接,当单击该链接时,将显示所有产品以及共享该主目录的所有其他 Oracle 数据库。Listener 的超链接显示注册到监听器(其名称就显示在紧靠它的下方)的所有数据库和实例。最后,显示主机名 (starz)。

在名为“Host CPU”(2) 的部分中,醒目地显示了 CPU 的详细信息。“Active Sessions”(3) 部分显示了活动的会话及其当前状态 (4)。从上面我们看到,99% 的时间被处于等待状态的会话所占用。(我们稍后将找出导致这些等待的原因。)“High Availability”(5) 部分显示了与可用性相关的信息。例如,“Instance Recovery Time”的值(实例的 MTTR Target 的值)确定实例崩溃恢复可能需要的时间。

“Space Usage”(6) 部分很有趣:它显示与 23 个段相关的警告。(同样,稍后再详细介绍这些警告。)“Diagnostic Summary”(7) 部分提供数据库良好运行的概要信息。所发现的性能问题的数量表示自动数据库诊断监控程序 (ADDM) — 在 10g 中新增的自诊断引擎 — 主动识别出多少问题。EM 还自动分析您的环境,以确定是否违反了所建议的最佳实践;此分析的结果显示在“Policy Violation”部分。最后,EM 扫描警报日志,并显示任何最新的 ORA 错误。这种信息非常有价值 — 在警报日志中自动扫描 Oracle 错误使您避免了手动搜索这些错误的很多麻烦。

在数据库主页的下部,如图 3 所示,我们可以更详细地查看其中的一些消息。“Alerts”(1) 部分显示了需要您注意的所有相关警报,每个警报都可以方便地进行配置。以第一个警报 (2) 为例,它显示 Archiver 进程因为某种原因而挂起。当然,下一步就是确定其原因。要查明原因,只需单击它即可。您将从包含该错误的 alert.log 文件中获得更多详细信息。在此情形下,故障点是一个已经填满的闪回恢复区;我们只需将其清空,Archiver 即可重新开始工作。

图 3
图 3:主数据库主页(下部)

另一个警报 (3) 是有关等待的:数据库在 69% 的时间中等待一个与等待类“Application”相关的等待。还记得主页上部是如何显示一个会话处于等待状态的吗?这个警报向我们显示它正在等待什么。单击超链接将会立即为您显示实际的等待。

下一个警报 (4) 显示一个审计项目,即用户 SYS 从特定的客户端机器连接到数据库。同样,通过单击超链接,您可以显示有关该连接的所有详细信息。最后一个警报 (5) 显示某些对象无效。单击超链接,您将转到对象被验证无效的画面。

如您所见,数据库主页犹如显示需要您注意的所有事项的仪表板。该界面没有将详细信息堆积在屏幕上,其界面相当简洁,只需单击即可获得这些详细信息。您可以手动搜集所有这些信息,但这可能会花费很多时间和精力。EM 10g 提供了随取随用的解决方案。

一般应用

让我们来看看如何使用新的 EM 来完成一些较常见的任务。

一项常见的任务是变更表及其相应的索引。在数据库主页,如图 3 所示选择“Administration”选项卡,并引用标记为 6 的项目。在本页中,您可以管理数据库来配置回退段、创建表空间和模式对象、设置资源管理器、使用新的调度程序(将在以后的文章中介绍)以及更多事项。在此处选择“Tables”,这将调出如图 4 所示的画面。

图 4
图 4:表管理

注意红色圆圈中高亮显示的手电筒标志;这是用于调出数值列表的按钮。在图中所示画面中,您可以单击 LOV 标志,调出数据库中的用户列表,并从列表中选择一个用户。单击按钮“Go”,出现该用户的表的一个列表。您还可以使用“%”符号指定通配符 — 例如,通过使用 %TRANS%,可以找出名称中带有单词 TRANS 的所有表。

让我们来看一个示例。选择表 TRANS,更改其中的一列。单击超链接,调出如图 5 所示的“编辑表”画面。

图 5
图 5:表管理

如果您要将列 ACTUAL_RATE 从 NUMBER(10) 改为 NUMBER(11),则可以更改数字(引用 1),然后单击“Apply”。要查看完成该任务的实际 SQL 语句,可以单击按钮“Show SQL”。

在同一画面上还可以获得另一条重要信息:增长趋势。您将在以后一篇有关段管理的文章中了解到,观察一段时间内的对象增长情况是可能的。该画面提供了相同的信息,但却是以图形方式表示的。要查看该画面,可单击选项卡“Segments”(图 5 引用 2)。该操作调出段画面,如图 6 所示。

图 6
图 6:段画面

注意红色圆圈中标记的项目。该画面显示有多少空间分配给段 (2)、实际使用了多少 (1) 以及浪费了多少 (3)。在该画面的下部 (4),您可以看到一幅有关对象所用空间以及分配给对象的空间的图形。在本示例中,表的使用模式已经稳定 — 因此是直线。

您可以对表执行其他管理操作,方法是使用那些用于该目的的选项卡,如用于管理约束的“Constraints”。

使用 EM 进行性能调节

到目前为止您已经了解到,虽然 EM 的外观已经更改,但它提供了至少与以前的 Java 版本同样多的功能。但是,与后者不同的是,EM 现在还支持更新的 Oracle 数据库功能。例如,EM 现在能够处理子分区。

但是,有经验的 DBA 希望这种工具能完成更多的工作 — 尤其是在故障诊断或主动性能调节方面。让我们举个例子。回忆前文中我们的数据库正在“Application”等待类上处于等待状态,如数据库主页所示(图 3 引用 3),而我们需要诊断其原因。在任何调整过程中需要了解的关键事情之一是有多少种组件(如 CPU、磁盘和主机子系统)在相互作用,这样有助于在上下文环境中综合观察所有这些变量。为此,可在数据库主页中选择“Performance”选项卡。此操作调出如图 7 所示的画面。

图 7
图 7:“Performance”选项卡

请注意所有量度已在同一时间轴上对齐,这样更容易观察它们的相互依赖性。注意尖峰 (3),它对应于调度程序任务。它表明,在该时刻约有七个会话正在等待与调度程序相关的等待事件。那么,影响因素是什么?注意处于同一位置(绿色区域)的 CPU 量度 — 它们显示了曾经使用过的最大 CPU 使用率,在图形中以虚线 (4) 表示。在该点前后,我们没有看到 CPU 尖峰出现,这就提供了一条线索。注意 CPU 运行队列长度中的尖峰 (1),这是调度程序的直接后果,调度程序可能产生了过多的内存需求,导致增加了分页活动 (2)。如您所见,所有现象集中在一起,促进了对数据库负载“概况”的了解。

注意在时间轴末尾的尖峰 — 增加了运行队列长度 (5) 和分页速率 (6)— 它们与物理读取的另一个尖峰相关 (7)。原因是什么?

通过比较图形“Sessions:Waiting and Working”与尖峰发生的时间,我们可以看到,大部分会话都在“Application”等待类上进行等待。但是我们需要确切地查明它在该时期内正在等待什么?单击该时间的区域,调出活动会话画面,如图 8 所示。

图 8
图 8:活动会话等待

该画面显示会话正在等待的等待事件是 enq:TX ?row lock contention。那么导致此问题的 SQL 语句是什么?很简单:画面本身显示了语句 8rkquk6u9fmd0 的 SQL ID(在红色圆圈中)。单击该 SQL ID,调出如图 9 所示的 SQL 画面。

图 9
图 9:SQL 详细信息

在该画面上,您可以看到关于它的 SQL 语句以及相关的详细信息,包括执行计划。它表明,这条 SQL 导致行锁争用,因此应用程序设计可能是问题的根源。

栓锁争用

假设单击“Performance”选项卡出现类似图 10 所示的画面。

图 10
图 10:“Performance”选项卡,示例 2

在图中,请注意红色矩形中高亮显示的量度。您可以看到在 12:20AM 左右有很多与 CPU 相关的等待,这导致在 CPU 中出现庞大的运行队列。我们需要诊断这一等待。

首先,单击显示 CPU 争用区域的图形(在图上标有“Click Here”),以详细查看该特定等待,如图 11 所示。

图 11
图 11:活动会话等待

注意在“Active Sessions Working:CPU Used”图形中带阴影的框 (1)。您可以使用鼠标拖动它来放置焦点。此操作导致以下的饼形图(2 和 3)只在该框所包含的时段内进行计算。在这里我们看到,一个具有 id 8ggw94h7mvxd7 的特定 SQL 正在非常困难地运行 (2)。我们还看到,具有用户名 ARUP 和 SID 265 的用户会话是最主要的运行会话 (3)。单击该会话,查看其详细信息。此操作调出“Session Details”画面。单击选项卡“Wait Events”,调出该会话所经历的等待事件的详细信息,其画面类似于图 12 所示。

图 12
图 12:等待事件的详细信息

在该画面中,请注意在红色圆圈中高亮显示的 118 厘秒的最长等待,它在等待库高速缓存。当您单击“Latch:Library Cache”的超链接时,将会看到类似图 13 所示的画面。

图 13
图 13:等待直方图

该画面提供了 10g 数据库之前所没有提供的一些独特信息。在诊断这个栓锁争用问题时,如何知道这 118 厘秒的等待是由几个会话中的多个小等待组成,还是只是由一个会话中的一个大等待组成,从而使数据出现偏差呢?

在这里,直方图可以帮助我们。从图上看,您知道大约 250 次会话拥有 1 毫秒的等待(在圆圈中高亮显示)。会话在 4 与 8 毫秒之间的某处等待了大约 180 次。该画面显示,这些等待的时间通常很短,因而它们不是栓锁争用的主要症状。

在数据库主页上,您可以通过单击标为“Advisor Central”的选项卡来访问 ADDM、SQL Access Advisor 以及其他顾问程序。ADDM 在收集量度时自动运行,并且结果立即发布在 Advisor Central 页中;当单击该页时,将显示由 ADDM 给出的建议。SQL Tuning Advisor 也检查这些量度,并在此页上发布其建议。(我们将在以后的文章中更加详细地研究 ADDM 和 SQL Tuning Advisor。)

简化维护

数据库主页上标为“Maintenance”的选项卡是常用维护活动 — 如备份和恢复、数据导出或导入(数据泵)、数据库克隆以及更多活动 — 的启动控制台。在该画面上,您还可以对策略验证警报所基于的最佳实践的基本原理进行编辑。

结论

如先前所述,这篇文章所涉及的只是巨大冰山的一角。在本文中,我的目的不是为了提供全面的概述;而是希望提供对一些跨多个技能集的特定活动的快速浏览。

Oracle 10g EM 为 DBA 新手提供了足够的资源,以便很快地了解 Oracle 数据库管理的微妙之处。一本有关使用 EM 的任务及技术的好提纲是 Oracle“两日速成 DBA”参考手册。我强烈建议您阅读它,尤其是在您刚开始学习的时候。

Oracle 数据库10g-可传输表空间

原文链接,英文版链接 可传输表空间

可传输表空间现在可以跨平台移植,从而使得数据发布更快更容易。此外,外部表下载使得通过转换进行数据转移的任务更简单更快。

您如何将数据从一个数据库转移到另一个数据库?在现有的几种方法中,有一种方法尤为出色:可传输表空间。在这种方法中,您使用一组自包含、只读的表空间,只导出元数据,在操作系统层将这些表空间的数据文件拷贝至目标平台,并将元数据导入数据字典 — 这个过程称为插入

操作系统文件拷贝一般比其它传统的数据转移方法(如导出/导入或 SQL*Loader)要快得多。然而,在 Oracle9i 数据库和更低版本中,可传输表空间仅限于在目标数据库和源数据库都运行在同一操作系统平台上的少数情况下才有用 — 例如,您不能在 Solaris 和 HP-UX 平台之间传输表空间。

在 Oracle 数据库 10g 中,这个局限消失了:只要操作系统字节顺序相同,您就可以在平台之间传输表空间。本文将不就字节顺序展开长篇的讨论,但这里只要提几句话就足够了:一些操作系统(包括 Windows)在低位内存地址中用最低有效字节存储多字节二进制数据;因此这种系统被称为低地址低字节序。相反,其它的操作系统(包括 Solaris)将最高有效字节存储在低位内存地址中,因此这种系统被称为低地址高字节序。当一个低地址高字节序的系统试图从一个低地址低字节序的系统中读取数据时,需要一个转换过程 — 否则,字节顺序将导致不能正确解释读取的数据。(有关字节顺序的详细说明,请阅读嵌入式系统编程的 2002 年 1 月刊中的一篇极好的文章“字节顺序介绍”。)不过,当在相同字节顺序的平台之间传输表空间时,不需要任何转换。

您怎么知道哪一种操作系统采用哪一种字节顺序?不需猜测或搜索互联网,相反只需简单地执行以下查询:
SQL> select * from v$transportable_platform order by platform_id;

PLATFORM_ID PLATFORM_NAME                       ENDIAN_FORMAT
----------- ----------------------------------- --------------
1 Solaris[tm] OE (32-bit)             Big
2 Solaris[tm] OE (64-bit)             Big
3 HP-UX (64-bit)                      Big
4 HP-UX IA (64-bit)                   Big
5 HP Tru64 UNIX                       Little
6 AIX-Based Systems (64-bit)          Big
7 Microsoft Windows IA (32-bit)       Little
8 Microsoft Windows IA (64-bit)       Little
9 IBM zSeries Based Linux             Big
10 Linux IA (32-bit)                   Little
11 Linux IA (64-bit)                   Little
12 Microsoft Windows 64-bit for AMD    Little
13 Linux 64-bit for AMD                Little
15 HP Open VMS                         Little
16 Apple Mac OS                        Big

假设您想从一台在 Intel 体系结构上运行 Linux 操作系统的主机 SRC1 中将一个表空间 USERS 传输到运行 Microsoft Windows 操作系统的计算机 TGT1 上。源平台和目标平台都是低地址低字节序的。表空间 USERS 的数据文件是 users_01.dbf。您将按照类似以下的方法来进行操作。
  1. 使表空间为只读:
    alter tablespace users read only;
  2. 导出表空间。在操作系统提示符下执行:
    exp tablespaces=users transport_tablespace=y file=exp_ts_users.dmp
    exp_ts_users.dmp 文件只包含元数据(不是表空间 USERS 的内容)因此它将非常小。

  3. 将文件 exp_ts_users.dmp 和 users_01.dbf 拷贝至主机 TGT1。如果您使用 FTP,那么您将需要指定二进制选项。
  4. 将表空间插入到数据库中。在操作系统命令提示符下执行下面的语句:
    imp tablespaces=users transport_tablespace=y file=exp_ts_users.dmp datafiles='users_01.dbf'
在第 4 步之后,目标数据库将有一个名称为 USERS 的表空间,并将提供该表空间的内容。

请记住,系统 SRC1 和 TGT1 分别是 Linux 和 Windows。到 Oracle9i 为止,运行在 TGT1 上的数据库不能识别第 4 步中的数据文件 users_01.dbf,从而使得整个过程无用。您将必须求助其它一些方法(如常规的导出和导入、创建纯文本文件并通过 SQL*Loader 加载,或直接在不同的数据库间连接加载插入)。

在 10g 中,不再需要这些替代方法,因为目标数据库能够识别来自另一个平台的数据文件。在我们的示例中,源主机和目标主机运行的操作系统的字节顺序是相同的(低地址低字节序),因此不需要任何转换。

这个功能在数据仓库中特别有用,其中更小的面向对象的数据集市常常在刷新之后从仓库中进行填充。利用 10g,这些数据集市现在能够放在更小、更廉价的计算机(如运行 Linux 的 Intel boxes)中,而将数据仓库服务器放在更大的企业级计算机中。从本质上讲,利用可传输表空间,您现在可以更好地利用各种硬件和操作系统的组合。

跨不同字节顺序的平台

如果平台是不同字节顺序的,那么您将如何实现可传输性?正如我之前说明的,目标计算机的字节顺序如果与源计算机的字节顺序不同,那么将不能正确地读取数据文件,因而不可能简单地拷贝数据文件。但别灰心,在 Oracle 10g RMAN 实用程序中提供了帮助,它支持将数据文件从一种字节顺序向另一种字节顺序转换。

在上面的例子中,如果主机 SRC1 运行在 Linux 上(低地址低字节序),而目标主机 TGT1 运行在 HP-UX 上(低地址高字节序),那么您需要在第 3 步和第 4 步之间引入另一个步骤,以进行转换。利用 RMAN,您将在源计算机 SRC1 上把数据文件从 Linux 转换成 HP-UX 格式(假定您已经使表空间变为只读):
RMAN> convert tablespace users
2> to platform 'HP-UX (64-bit)'
3>  format='/home/oracle/rman_bkups/%N_%f';

Starting backup at 14-MAR-04
using channel ORA_DISK_1
channel ORA_DISK_1:starting datafile conversion
input datafile fno=00004 name=/usr/oradata/dw/starz10/users01.dbf
converted datafile=/home/oracle/rman_bkups/USERS_4
channel ORA_DISK_1:datafile conversion complete, elapsed time: 00:00:07
Finished backup at 14-MAR-04

这个步骤在目录 /home/oracle/rman_bkups 中创建了一个标准 RMAN 文件格式 <tablespace_name>_<absolute_datafile_no> 的文件。注意我们没有触及表空间 USERS 的数据文件;而是为 HP-UX 创建了一个新文件。现在可以将这个文件拷贝至目标系统,剩下的步骤很简单。

这个 RMAN 转换命令非常强大。按照上面给定的形式,它可以按顺序创建数据文件。对于包含多个数据文件的表空间,您可以命令同时转换并运行多个数据文件。要实现这一目的,您将需要在上述命令中添加一个子句:
parallelism = 4

该子句创建四个 RMAN 通道,每一个通道处理一个数据文件。不过,一种更有用的方法是用一个步骤转换大量的表空间,在这种情况下并行转换将真正带来很大的帮助。下面我们将两个表空间 USERS 和 MAINTS 转换至 HP-UX:
RMAN> convert tablespace users, maints
2> to platform 'HP-UX (64-bit)'
3> format='/home/oracle/rman_bkups/%N_%f'
4> parallelism = 5;

Starting backup at 14-MAR-04
using target database controlfile instead of recovery catalog
allocated channel:ORA_DISK_1
channel ORA_DISK_1:sid=244 devtype=DISK
allocated channel:ORA_DISK_2
channel ORA_DISK_2:sid=243 devtype=DISK
allocated channel:ORA_DISK_3
channel ORA_DISK_3:sid=245 devtype=DISK
allocated channel:ORA_DISK_4
channel ORA_DISK_4:sid=272 devtype=DISK
allocated channel:ORA_DISK_5
channel ORA_DISK_5:sid=253 devtype=DISK
channel ORA_DISK_1:starting datafile conversion
input datafile fno=00004 name=/usr/oradata/dw10/dw10/users01.dbf
channel ORA_DISK_2:starting datafile conversion
input datafile fno=00005 name=/usr/oradata/dw10/dw10/users02.dbf
channel ORA_DISK_3:starting datafile conversion
input datafile fno=00006 name=/usr/oradata/dw10/dw10/maints01.dbf
channel ORA_DISK_4:starting datafile conversion
input datafile fno=00007 name=/usr/oradata/dw10/dw10/maints02.dbf
converted datafile=/home/oracle/rman_bkups/USERS_4
channel ORA_DISK_1:datafile conversion complete, elapsed time: 00:00:03
converted datafile=/home/oracle/rman_bkups/USERS_5
channel ORA_DISK_2:datafile conversion complete, elapsed time: 00:00:00
converted datafile=/home/oracle/rman_bkups/MAINTS_6
channel ORA_DISK_3:datafile conversion complete, elapsed time: 00:00:01
converted datafile=/home/oracle/rman_bkups/MAINTS_7
channel ORA_DISK_4:datafile conversion complete, elapsed time: 00:00:01
Finished backup at 14-MAR-04

在上述例子中,转换后的文件名难于辨认并很难与原始文件关联(例如,文件 users01.dbf 变为 USERS_4)。相反,您还可以使用其它格式来为数据文件命名。这个过程类似于在 Data Guard 中为数据文件重命名的过程。您可以使用如下命令:
RMAN> convert tablespace users
2> to platform 'HP-UX (64-bit)'
3> db_file_name_convert '/usr/oradata/dw10/dw10','/home/oracle/rman_bkups'
4> ;

Starting backup at 14-MAR-04
using channel ORA_DISK_1
channel ORA_DISK_1:starting datafile conversion
input datafile fno=00004 name=/usr/oradata/dw10/dw10/users01.dbf
converted datafile=/home/oracle/rman_bkups/users01.dbf
channel ORA_DISK_1:datafile conversion complete, elapsed time: 00:00:03
channel ORA_DISK_1:starting datafile conversion
input datafile fno=00005 name=/usr/oradata/dw10/dw10/users02.dbf
converted datafile=/home/oracle/rman_bkups/users02.dbf
channel ORA_DISK_1:datafile conversion complete, elapsed time: 00:00:01
Finished backup at 14-MAR-04 

这将在转换后保留文件名。如果您切换到目录 /home/oracle/rman_bkups,您将看到文件 users01.dbf 和 users02.dbf,它们对应相同名称的原始文件。

在上述情况下,我们在源平台上转换文件。不过,您也可以在目标平台上转换文件。例如,您可以将文件 users01.dbf 拷贝至运行 HP-UX 的主机 TGT1 上,然后利用以下命令将文件转换成 HP-UX 格式:
RMAN> convert
2> datafile '/usr/oradata/dw10/dw10/users01.dbf'
3> format '/home/oracle/rman_bkups/%N_%f'
4> ;

这种方法将以指定的格式在目录中创建文件。

但为什么您会想在目标平台上转换数据文件,确切的原因是什么?一个原因是更短的停机时间,这要求表空间仅在拷贝至目标主机期间为 READ ONLY 状态。您可以为数据文件创建三个镜像,使表空间为只读,分开第三个镜像,然后立即使表空间为读/写状态。然后可以把第三个镜像加载到目标系统上,并在空闲时进行转换。这种安排使得表空间必须保持为只读的时间最少。

另一个原因可能是性能。OLTP 数据库可能承担一个持续的负载,而使用 RMAN 转换操作可能使系统负载超出期望的范围。相反,可以把转换操作卸载到数据仓库服务器上,其中通常提供了更多的 CPU,以进行并行操作。

将外部表用作数据传输机制

Oracle9i 数据库引入了外部表,外部表使得格式化的纯文本文件在数据库中视为一个表,此表可以通过常规 SQL 进行选择。假设您必须使用这种外部表方法将名称为 TRANS 的表的内容从 OLTP 数据库转移到数据仓库数据库中。下面是实现这一目的的步骤。
  1. 从 OLTP 数据库中,使用表 TRANS 的内容创建一个纯文本文件。该文件可以在目录 /home/oracle/dump_dir 中命名为 trans_flat.txt。该文件通常是用这条 SQL 语句创建的:
    spool trans_flat.txt
    select <column_1> ||','|| <column_2> ||','|| ...
    from trans;
    spool off
  2. 利用 ftp、rcp 或其它一些机制将文件拷贝至数据仓库服务器中。该文件位于目录 /home/oracle/dump_dir 中。
  3. 在数据仓库数据库上,创建一个名称为 dump_dir 的目录对象,方法如下:
    create directory dump_dir as '/home/oracle/dump_dir';
  4. 创建一个外部表:
    create table trans_ext
    (
    ... <columns of the table> ...
    )
    organization external
    (
    type oracle_loader
    default directory admin
    access parameters
       (
    records delimited by newline
    badfile 'trans_ext.bad'
    discardfile 'trans_ext.dis'
    logfile 'trans_ext.log'
    fields terminated by ","  optionally enclosed by '"'
          (
    ... <columns> ...
          )
       )
    location ('trans_flat.txt')
    )
    reject limit unlimited;
  5. 现在利用任意一种常用的方法(如直接加载插入和合并)将外部表加载到常规表中。
这里最费时的操作是第 1 步,在这个步骤中创建了纯文本文件。您可以使用纯 SQL 来创建这个文件,然后假脱机到一个文件 — 一个简单但却漫长的过程。您可以使用 Pro*C 或 OCI 程序(替代 SQL*Plus)来将记录卸载到一个纯文本文件中,以使这个过程稍微快一些,但它仍将花费一段时间。另一个“速度障碍”是需要人工指定列 — 又一个费时的过程。

这两个问题在 10g 中都已得到了解决。现在您可以利用外部表创建过程快速地将一个表卸载成可移植的格式。上面的第 1 步变为这条简单的 SQL 语句:
create directory dump_dir as '/home/oracle/dump_dir';

create table trans_dump
organization external
(
type oracle_datapump
default directory dump_dir
location ('trans_dump.dmp')
)
as
select * from trans
/

这些命令在目录 /home/oracle/dump_dir 中创建了一个名称为 trans_dump.dmp 的文件。这个文件不完全是 ASCII 文本;元数据是纯文本,但实际的数据是原始格式的。不过,这个文件是可以移植到不同的操作系统 — 类似于导出转储文件,但与导出不同的是,数据下载非常快。您将把这个文件拷贝到数据仓库服务器中,然后用与之前提到的相同的方式创建外部表,但这次用这个文件替换源文件。

那么旧的数据传输机制和这种数据传输机制有什么不同?有一些不同。首先,您可以非常快速地创建一个可移植的文件,而无需编写任何复杂的 SQL,选择表的列等等。其次,您可以用这种文件作为外部表的输入,从而使得将数据作为一个常规的表进行查看并在数据处理之后将数据加载到其它的表中成为可能。您还可以按如下所示方法提高到这种外部表中的数据下载的性能。
create table trans_dump
organization external
(
type oracle_datapump
default directory dump_dir
location ('trans_dump.dmp')
)
parallel 2
as
select * from trans
/
这些命令创建了相同的文件,只不过是以并行的方式。您应当这么做,以利用多个主机 CPU(如果提供的话)。除了并行化之外,您还可以按照如下所示方法将表下载到多个外部文件中。
create table trans_dump
organization external
(
type oracle_datapump
default directory dump_dir
location ('trans_dump_1.dmp','trans_dump_2.dmp')
)
parallel 4
as
select * from trans
/

这些命令创建了两个文件 trans_dump_1.dmp 和 trans_dump_2.dmp,而不只是一个。这种方法在将文件扩散到多个物理设备或控制器上以减少与 I/O 相关的等待时非常有帮助。

结论

通过使表空间能够跨平台传输,10g 为数据仓库数据转移提供了一个强大的解决方案。该特性与外部表下载相结合,消除了在源数据库和目标数据库之间进行数据发布的阻碍(无论它是 OLTP 数据库、数据仓库数据库或数据集市数据库)并使您能够为特定类型的应用程序作出适当的平台选择。

此外,通过使可传输表空间变得可行,10g 使得数据刷新更快更频繁,以便能够更快地把经过分析的数据提供给最终用户。该功能还可以用来通过离线介质将数据发布给不同的数据库,而不管它们的主机系统是什么。利用外部表下载,终于为最终用户提供了一个作为 ETL 工具的实用程序,以用来转移大量的数据。

亲身经验预测胎儿性别

(引自网络

我的儿子现在马上快7个月了,妹妹前天也生了女儿。前后亲戚朋友也有怀孕生字的,总结以下经验供各位姐妹参考,不准全当娱乐!!

  预测男女不准的——

  肚子形态:因为根据孕前个人体型及体质发展差异,老人们说的女孩全在前,男孩不显怀并不准。(本人就是例子)

  浮肿:女孩脚肿,男孩不舯(准确率不高,不过肿的话晚上将脚垫高些能有效缓解,如果休息一宿还不能缓解就要及时到医院去查查)

  妊晨线:女孩的妈妈妊晨线也可很黑很长到乳房

  脸色:男孩妈变丑,女孩脸色好

  生男生女:酸儿辣女你信是不信

  预测男女比较准——

  肚脐状态:到7.8月分后躺下摸肚脐中间软软的是男孩,没有软软的还比较有弹力是女孩

  腋下:很黑是女孩,不太黑是男孩

  食性:男孩特殊爱吃肉尤其孕初,女孩没有特殊需求

  胎梦:我的先生是韩国人他门讲究胎梦还比较准,但是在刚怀的时候

  胎动:男孩摸到硬硬的不知是手脚还是胳腿关节,女孩是小包用手摸才慢慢下去

  胎心:女孩150以上,男孩150以下(但排除最后几周有制养和压迫现象)

  胎囊形状:50-70多天比超显示胎囊长性男孩,近似圆扁型是女孩

  以上有医生说的大部分是我自己调查的,不准不要怪我啊!!

  看过网友的,现在咱们来看看专家的说法!


Pages

Powered by Movable Type 6.3.2

About this Archive

This page is an archive of entries from March 2007 listed from newest to oldest.

January 2007 is the previous archive.

April 2007 is the next archive.

回到 首页 查看最近文章或者查看所有归档文章.