记录学习

显示标签为“Oracle”的博文。显示所有博文
显示标签为“Oracle”的博文。显示所有博文

2008年3月8日星期六

调度程序

您是否厌倦了在 dbms_job 中手工管理时间间隔的繁琐,需要数据库内部有个新调度系统? 让我们就着眼于数据库本身来解决这个问题。

你们中的一部分人可能广泛使用 dbms_job 程序包来将数据库作业提交到后台运行,控制运行的时间或时间间隔,报告故障等等。 然而,我感觉你们中的大部分人不会这么做。


这个程序包存在的问题是它只能够处理 PL/SQL 代码段 — 仅能处理匿名程序块和存储程序单元。 它不能在数据库外部处理操作系统命令文件或可执行文件中的任何东西。 为此,您将不得不求助于操作系统调度实用工具(如 Unix 中的 cron 或 Windows 中的 AT 命令)。 或者,您可以使用甚至可能通过提供图形用户界面来扩展这种功能的第三方工具。

虽然如此,dbms_job 有一个超过这些替代方法的独特优点: 它只有在数据库启动并运行时才有效。 如果数据库关闭,则作业不会运行。 数据库外部的工具必须人工检查数据库是否启动 — 而这可能很困难。 另一个优点是 dbms_job 在数据库内部,因此您可以通过数据库访问实用工具(如 SQL*Plus)来访问它。

Oracle 数据库 10g 调度程序特性提供了各方面的好处: 它是直接在数据库内部的一个作业调度实用程序,强大到足够处理所有类型的作业,而不只是 PL/SQL 代码段。 最好的一点是,它是数据库自带的,无需任何额外的成本。 在这一部分中,我们将看看它是如何工作的。

将作业与程序连接

也许最好通过一个例子来介绍这个概念。 假定您创建了一个 shell 脚本,以将存档的日志文件转移到一个不同的文件系统中,如下:
/home/arup/dbtools/move_arcs.sh

首先,您需要使数据库知道这个脚本是一个要在作业中使用的程序。 要创建这个程序,您必须拥有 CREATE JOB 权限。
begin
dbms_scheduler.create_program
(
program_name => 'MOVE_ARCS',
program_type => 'EXECUTABLE',
program_action => '/home/arup/dbtools/move_arcs.sh',
enabled => TRUE,
comments => 'Moving Archived Logs to Staging Directory'
);
end;
/

这里您创建了一个命名程序单元,将其指定为可执行文件。注意这个程序单元叫什么。

接下来,您将创建一个每 30 分钟运行一次的命名计划,该计划的名称为 EVERY_30_MINS。 您将使用以下命令来完成这一操作:
begin
dbms_scheduler.create_schedule
(
schedule_name => 'EVERY_30_MINS',
repeat_interval => 'FREQ=MINUTELY; INTERVAL=30',
comments => 'Every 30-mins'
);
end;
/


现在创建了程序和计划,接着您将把程序与计划连接来创建作业。
begin
dbms_scheduler.create_job
(
job_name => 'ARC_MOVE',
program_name => 'MOVE_ARCS',
schedule_name => 'EVERY_30_MINS',
comments => 'Move Archived Logs to a Different Directory',
enabled => TRUE
);
end;
/

这将创建一个每 30 分钟运行一次的作业,该作业执行 shell 脚本 move_arcs.sh。它将由数据库内部的调度程序特性来处理 — 无需 cron 或 AT 实用工具。

创建没有程序的作业

在上述情况下,您创建了一个程序来引用一个操作系统实用工具或程序,并创建了一个计划来指定运行的次数,最后将这两者连接起来创建作业。 不过,不需要从程序中创建作业;也可以独立地定义它们。 例如,您可以创建上述作业,而无需首先创建一个程序。
begin
dbms_scheduler.create_job
(
job_name => 'ARC_MOVE_2',
schedule_name => 'EVERY_30_MINS',
job_type => 'EXECUTABLE',
job_action => '/home/arup/dbtools/move_arcs.sh',
enabled => true,
comments => 'Move Archived Logs to a Different Directory'
);
end;
/

这里直接指定 OS 可执行文件,而无需首先将其创建为一个程序。 同样,您可以创建一个作业,而无需一个命名的计划。
begin
dbms_scheduler.create_job
(
job_name => 'ARC_MOVE_3',
job_type => 'EXECUTABLE',
job_action => '/home/arup/dbtools/move_arcs.sh',
repeat_interval => 'FREQ=MINUTELY; INTERVAL=30',
enabled => true,
comments => 'Move Archived Logs to a Different Directory'
);
end;
/

Scheduler 超过 dbms_job 的一个优点从我们最初的例子中可以很清楚地看出来: 能够调用 OS 实用工具和程序,而不只是 PL/SQL 程序单元。 这一能力使它成为管理 Oracle 数据库和相关作业的最全面的作业管理工具。
不过,您可能已经注意到了另一个同样重要的优点: 能够以自然语言定义时间间隔。 注意在上面的例子中,我们要我们的计划每 30 分钟运行一次,因此通过一个简单的类似英语的表达式(而不是 PL/SQL)定义了 REPEAT_INTERVAL 参数:

'FREQ=MINUTELY; INTERVAL=30'

一个更复杂的例子甚至可以更好地帮助说明这一优点。 假定您的生产应用程序在上午 7:00 和下午 3:00 变得最活跃,为了收集系统统计数据,您想从星期一到星期五仅在上午 7:00 和下午 3:00 运行 Statspack。 如果您使用 DBMS_JOB.SUBMIT 来创建一个作业,那么 NEXT_DATE 参数将看起来像这样:

DECODE
(
SIGN
(
15 - TO_CHAR(SYSDATE,'HH24')
),
1,
TRUNC(SYSDATE)+15/24,
TRUNC
(
SYSDATE +
DECODE
(
TO_CHAR(SYSDATE,'D'), 6, 3, 1
)
)
+7/24
)

这种代码容易理解吗?实际上不容易。

现在让我们看看 DBMS_SCHEDULER 中的等价的作业。 REPEAT_INTERVAL 参数将像下面这么简单:
'FREQ=DAILY; BYDAY=MON,TUE,WED,THU,FRI; BYHOUR=7,15'

此外,这个参数值可以接收各种时间间隔,它们中的一些非常强大。 下面是更多的一些例子:
每月的最后一个星期天:
FREQ=MONTHLY; BYDAY=-1SUN

每月的第三个星期五:
FREQ=MONTHLY; BYDAY=3FRI

从每月底算起(而不是从每月初算起)的第二个星期五:
FREQ=MONTHLY; BYDAY=-2FRI

数字前面的负号指示从月底算起,而不是从月初算起。

如果您想要验证时间间隔设置是否正确,那应该怎么办? 看看从日历字符串中构造的各个日期不是很好吗? 好的,您可以使用 EVALUATE_CALENDAR_STRING 过程来预览接下来的日期的计算。 利用第一个例子 — 从星期一到星期五每天在上午 7:00 和下午 3:00 运行 Statspack — 您可以按如下方式检查您的时间间隔字符串的准确性:
set serveroutput on size 999999

declare
L_start_date TIMESTAMP;
l_next_date TIMESTAMP;
l_return_date TIMESTAMP;
begin
l_start_date := trunc(SYSTIMESTAMP);
l_return_date := l_start_date;
for ctr in 1..10 loop
dbms_scheduler.evaluate_calendar_string(
'FREQ=DAILY; BYDAY=MON,TUE,WED,THU,FRI; BYHOUR=7,15',
l_start_date, l_return_date, l_next_date
);
dbms_output.put_line('Next Run on: ' ||
to_char(l_next_date,'mm/dd/yyyy hh24:mi:ss')
);
l_return_date := l_next_date;
end loop;
end;
/

输出结果如下:
Next Run on: 03/22/2004 07:00:00
Next Run on: 03/22/2004 15:00:00
Next Run on: 03/23/2004 07:00:00
Next Run on: 03/23/2004 15:00:00
Next Run on: 03/24/2004 07:00:00
Next Run on: 03/24/2004 15:00:00
Next Run on: 03/25/2004 07:00:00
Next Run on: 03/25/2004 15:00:00
Next Run on: 03/26/2004 07:00:00
Next Run on: 03/26/2004 15:00:00

这确认您的设置是正确的。

类、计划和窗口

一个称职的好的作业调度系统必须支持为作业安排优先级的能力。 例如,统计数据收集作业突然进入 OLTP 工作负载窗口,从而可能影响那里的性能。 为了确保统计数据收集作业不消耗资源从而影响 OLTP,您可以使用作业类、资源计划和调度程序窗口。

例如,当定义一个作业时,您可以使之属于一个作业类,作业类映射到一个资源使用组上,以进行资源分配。 为此,首先您需要定义一个名称为(比如说) OLTP_GROUP 的资源使用组。
begin
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.create_consumer_group (
consumer_group => 'oltp_group',
comment => 'OLTP Activity Group'
);
dbms_resource_manager.submit_pending_area();
end;
/

接下来,您需要创建一个资源计划。
begin
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.create_plan
('OLTP_PLAN', 'OLTP Database Activity Plan');
dbms_resource_manager.create_plan_directive(
plan => 'OLTP_PLAN',
group_or_subplan => 'OLTP_GROUP',
comment => 'This is the OLTP Plan',
cpu_p1 => 80, cpu_p2 => NULL, cpu_p3 => NULL, cpu_p4 => NULL,
cpu_p5 => NULL, cpu_p6 => NULL, cpu_p7 => NULL, cpu_p8 => NULL,
parallel_degree_limit_p1 => 4,
active_sess_pool_p1 => NULL,
queueing_p1 => NULL,
switch_group => 'OTHER_GROUPS',
switch_time => 10,
switch_estimate => true,
max_est_exec_time => 10,
undo_pool => 500,
max_idle_time => NULL,
max_idle_blocker_time => NULL,
switch_time_in_call => NULL
);
dbms_resource_manager.create_plan_directive(
plan => 'OLTP_PLAN',
group_or_subplan => 'OTHER_GROUPS',
comment => NULL,
cpu_p1 => 20, cpu_p2 => NULL, cpu_p3 => NULL, cpu_p4 => NULL,
cpu_p5 => NULL, cpu_p6 => NULL, cpu_p7 => NULL, cpu_p8 => NULL,
parallel_degree_limit_p1 => 0,
active_sess_pool_p1 => 0,
queueing_p1 => 0,
switch_group => NULL,
switch_time => NULL,
switch_estimate => false,
max_est_exec_time => 0,
undo_pool => 10,
max_idle_time => NULL,
max_idle_blocker_time => NULL,
switch_time_in_call => NULL
);
dbms_resource_manager.submit_pending_area();
end;
/

最后,您利用之前创建的资源使用组来创建一个作业类。
begin
dbms_scheduler.create_job_class(
job_class_name => 'OLTP_JOBS',
logging_level => DBMS_SCHEDULER.LOGGING_FULL,
log_history => 45,
resource_consumer_group => 'OLTP_GROUP',
comments => 'OLTP Related Jobs'
);
end;
/

让我们看看这个调用中的各个参数。 LOGGING_LEVEL 参数设置为作业类跟踪多少日志数据。 设置 LOGGING_FULL 指示这个类中的作业上的所有活动 — 创建、删除、运行、更替等等 — 都将被记录在日志中。 这些日志可以从 DBA_SCHEDULER_JOB_LOG 视图中看到,并保留 45 天(在 LOG_HISTORY 参数中指定,默认值是 30 天)。 还指定了与这个类相连的资源使用组。 这些作业类可以从 DBA_SCHEDULER_JOB_CLASSES 视图中看到。

当您创建一个作业时,您可以随意地将其与一个类关联。 例如,当创建 COLLECT_STATS 时,对于一个通过执行一个存储过程来收集优化程序统计数据的作业 collect_opt_stats(),您可能已经指定了:
begin
dbms_scheduler.create_job
(
job_name => 'COLLECT_STATS',
job_type => 'STORED_PROCEDURE',
job_action => 'collect_opt_stats',
job_class => 'OLTP_JOBS',
repeat_interval => 'FREQ=WEEKLY; INTERVAL=1',
enabled => true,
comments => 'Collect Optimizer Stats'
);
end;
/

这些命令将把新创建的作业放在 OLTP_JOBS 类中,然后后者由资源计划 OLTP_GROUP 来管理,该资源计划将限制分配多少 CPU 给过程、在它被切换到一个不同的组之前的最大运行数、要切换到的组等等。 在这个类中定义的任意作业都将由相同的资源计划指令来管理。 这一功能对于防止不同类型的作业过度占用系统资源特别有用。

调度程序窗口是拥有一个相关的资源计划的时间帧,它用于激活该计划 — 从而在一个时间帧上支持作业的不同优先级。 例如,一些作业(如更新数据库以支持实时决策的批量程序)在白天需要高优先级但在晚上变为低优先级(反之亦然)。 您可以通过定义不同的资源计划,然后使用调度程序窗口激活它们来实施这种调度。

监视

在一个作业启动之后,您可以从 DBA_SCHEDULER_JOB_LOG 视图中监视它的状态,其中 STATUS 列显示了作业的当前状态。 如果它显示 FAILED,那么您可以进一步向下查看,以从 DBA_SCHEDULER_JOB_RUN_DETAILS 视图中找出原因。

管理

迄今为止,我们已经讨论了如何创建几种类型的对象: 程序、计划、作业类和作业。 如果您想修改它们中的一些,以调整适应不断变化的需求,那该怎么办? 好的,您可以通过 DBMS_SCHEDULER 程序包中提供的 API 来实现这一目的。

从企业管理器 10g 主页的 Database 标签中,单击 Administration 链接。 这将显示 Administration 屏幕(如图 1 所示)。所有与调度程序相关的任务都可以在右下角的 "Scheduler" 标题下找到(显示在图中的一个红色椭圆中)。



图 1: Administration 页面

所有与调度程序相关的任务(如创建、删除和维护作业)都能够通过该页面中的超链接任务轻松完成。 让我们看看这些任务中的一部分。 我们在早些时候创建了所有这些任务,因此单击 Jobs 标签将显示一个类似于图 2 的屏幕。



图 2: 计划作业

单击 COLLECT_STATS 作业允许您修改它的属性。 当您单击 "Job Name" 时,将出现图 3 中显示的屏幕。



图 3: 作业参数

正如您所看到的,您可以通过单击相应的标签来修改作业的参数以及计划和选项。 在完成所有的修改之后,您可以按下 "Apply" 键,使修改变为永久性的。 在这么做之前,您可能想单击标记为 "Show SQL" 的按钮,它显示将执行的确切的 SQL 语句 — 即使原因只是要查看调用了哪些 API,从而使您能够了解幕后的工作。 您还可以将 SQL 存储在一个脚本中,并在以后执行它,或者将它存储为一个模板,以便将来使用。

结论

Oracle 数据库 10g 中的调度程序是从原来的 dbms_job 接口实现的巨大的飞跃。 关于这些特性和其它更高级的特性的更多信息,请参考 Oracle 数据库管理员指南的第 25 章。

ADDM 和 SQL Tuning Advisor

ADDM 和 SQL Tuning Advisor

从最终权威那儿获得关于 SQL 调整的帮助:该权威就是 Oracle 数据库本身!使用 SQL 配置文件进行查询,并了解如何使用 ADDM 来快速、轻松解决常见的性能问题。

迄今为止这是平静的一天:在数据库中没有重大问题发生,不需要去灭“火”。您几乎可以放松一下了;接下来正好可以抓紧处理那些重要任务了,如对 RMAN 调整参数或多个块大小进行调整等。


突然,一位开发人员出现在您面前。他的 SQL 查询要运行很长一段时间。他问您是否能尽快调整该查询使其能够“工作”。

也许您放松得太早了。您最初的日程安排是花些时间制定战略决策,以使您的数据库运行得更好、更快、更安全。例如,确保数据库是可恢复的,增强底层技术或研究安全性更新等等。相反,您将又花一天的时间集中处理 SQL 等战术活动,而很少或没有时间来考虑战略问题。

作为一名战略 DBA,您想把自己从日常琐事中解脱出来,更多地关注那些引人深思的领域。让一名助理 DBA 帮助您做那些琐事难道不好吗?

有了 Oracle 数据库 10g,您就有了一位自动数据库诊断监控程序 (ADDM) 形式的助理 DBA,这种机器人式的 DBA 会不知疲倦地反复搜索数据库性能统计,以标识瓶颈、分析 SQL 语句、并据此提供多种改进性能的建议,它通常与其他“顾问”(如 SQL Tuning Advisor)一起使用。在这篇文章中,对该过程的工作方式进行了概述。

自动数据库诊断监控程序 (ADDM)

在第 6 周,您了解到被称作快照的自动负载信息库 (AWR),它定期从数据库中收集详细的与性能相关的度量标准。每次快照后,调用 ADDM 来彻底分析源自快照间差异的数据和度量标准,然后就必要的操作提出建议。正如我早先所提及的,发现问题后,ADDM 可能会依次调用其他顾问(如 SQL Tuning Advisor),来提出改进建议。

我将为您完全展示(而不是用文字来解释)这种特性是如何运行的。假定您正设法诊断一个不可解释的性能问题。在我们介绍的示例中,您知道了哪些 SQL 语句需要调整,或至少知道了哪些 SQL 语句存在问题。但是在现实生活中,您可能没有这些有用信息。

要在 10g 中执行诊断,您将在相关的时间间隔内选择快照进行深入、透彻的分析。在 Enterprise Manager 10g 中,从 Database 主页上,您将选择 "Advisor Central",然后单击 "ADDM" 链接,它将出现一个类似于图 1 的页面。



图 1:创建 ADDM 任务

在该页中,您可以创建 ADDM 要分析的任务。您知道性能问题发生在晚上 11 点左右,因此选择那个时间间隔的快照,通过 "eriod Start" 和 "eriod End" 值进行指示。您也可以单击照相机图标,指示开始和终止快照的时间间隔,如此处的红色椭圆形所示。选择时间间隔后,按下 "OK" 按钮,将出现一个类似于图 2 所示的页面。



图 2:ADDM 查找结果

这里 ADDM 在该时间间隔内标识了两个关键的、相关的性能问题:某些 SQL 语句消耗着重要的 CPU 时间,从而使数据库的速度显著减慢。基于这些查找结果,ADDM 建议对图中突出显示的那些语句进行 SQL 调整。

如果您单击某条查找结果,ADDM 会显示更多详细信息。例如,单击问题查找结果,将会出现一个类似于图 3 所示的页面。



图 3:ADDM 查找结果的详细信息

在此您可以看到引发该问题的特定 SQL 语句。ADDM 建议您用 SQL Tuning Advisor 对该 SQL 语句进行彻底的分析,正如在 "Action" 部分中所提到的那样。您可以通过单击它旁边的按钮立即运行该任务,这将调用 SQL Tuning Advisor。

在图 2 中,您可能注意到了一个名称为 "View Report" 的按钮。除了在单独的 Web 页面中提供建议外,ADDM 还能够创建纯文本报表,以进行更快速的一步到位的分析。列表 1 显示了在我们的示例纯文本报表中提出的全面建议。注意报表是如何给出相关细节的,如所考虑的 SQL 语句、它的散列值等。可以在 Enterprise Manager 的 SQL Tuning Advisor 页中或通过命令行将 SQL ID 用于独立的分析。

在收集了每一张 AWR 快照后就会调用 ADDM,因此可以查看基于相邻快照的建议。因此,如果分析的范围只是两张相邻的快照,就不必创建上面所示的 ADDM 任务。如果您想在两张不相邻的快照之间进行分析,就需要创建 ADDM 任务。

记住 ADDM 所能做的远不止这些;正如您在以前的文章中所看到的,它还提供内存管理、段管理、重作/撤消以及更多的分析和建议。由于在一篇简短的文章中描述所有的 ADDM 功能是不可能的,在此我们只关注 SQL Tuning Advisor。现在让我们看看它是如何工作的。

用 SQL Tuning Advisor 访问分析

在一个典型的运行时优化中,优化器生成一组可能的访问路径,并基于对象统计从中选择出最“经济”的路径。但是,那时它没有时间考虑是否能够调整语句、统计 是否陈旧、是否能够创建索引等问题。相反,SQL Tuning Advisor 可以执行这种“专家系统”类型的思考。实质上,优化器能够回答的问题是:“基于可用的资源,获得结果的最佳方式是什么?”而 SQL Tuning Advisor 能够回答的问题是:“基于用户的需求,还需要做些什么来增强性能?”

正如您可能预期的那样,这种“思考”消耗了资源(如 CPU);因此 SQL Tuning Advisor 在调整模式期间处理 SQL 语句,该模式可以在非高峰时间运行。在创建调整任务时,通过在函数中设置 SCOPE 和 TIME 参数来指示这种模式。在数据库活动少的期间运行调整模式是一个好方法,以使常规用户相对不受影响,稍后再进行分析。

这个概念可以通过示例很好地解释。就看看如下所示的开发人员引起您注意的那个查询事例吧。
select account_no from accounts where old_account_no = 11

该语句调整起来并不难,但是为了更容易说明问题,假定它很难调整。激发顾问的方式有两种:使用 Enterprise Manager 或简单明了的命令行。

首先,让我们看看如何在命令行中使用它。我们通过调用提供的包 dbms_sqltune 来调用顾问。
declare

l_task_id varchar2(20);
l_sql varchar2(2000);
begin
l_sql := 'select account_no from accounts where old_account_no = 11';
dbms_sqltune.drop_tuning_task ('FOLIO_COUNT');
l_task_id := dbms_sqltune.create_tuning_task (
sql_text => l_sql,
user_name => 'ARUP',
scope => 'COMPREHENSIVE',
time_limit => 120,
task_name => 'FOLIO_COUNT'
);
dbms_sqltune.execute_tuning_task ('FOLIO_COUNT');
end;
/

这个包创建并执行了一个名为 FOLIO_COUNT 的调整任务。接下来,您将需要查看任务执行的结果(也就是说,查看建议)。
set serveroutput on size 999999
set long 999999
select dbms_sqltune.report_tuning_task ('FOLIO_COUNT') from dual;


列表 2 显示的是输出结果。仔细查看这些建议;顾问说您可以通过在 OLD_ACCOUNT_NO 列上创建一个索引来改进性能。更佳的是,如果创建索引,顾问计算了查询成本,从而使潜在的节省量变得更加可定义、更加具体。
当然,考虑到本示例的简单性,通过手动检查也能得到这种结论。但是,可以想象出该工具对于那些更复杂的查询十分有用,因为对这些查询执行手动检查也许是不可能的或不实际的。


中级调整:查询重构

假定查询更复杂:
select account_no from accounts a
where account_name = 'HARRY'
and sub_account_name not in
( select account_name from accounts
where account_no = a.old_account_no and status is not null);


顾问建议如下:
1- Restructure SQL finding (see plan 1 in explain plans section)
----------------------------------------------------------------
The optimizer could not unnest the subquery at line ID 1 of the execution
plan.

Recommendation
--------------
Consider replacing "NOT IN" with "NOT EXISTS" or ensure that columns used
on both sides of the "NOT IN" operator are declared "NOT NULL" by adding
either "NOT NULL" constraints or "IS NOT NULL" predicates.

Rationale
---------
A "FILTER" operation can be very expensive because it evaluates the
subquery for each row in the parent query.The subquery, when unnested can
drastically improve the execution time because the "FILTER" operation is
converted into a join.Be aware that "NOT IN" and "NOT EXISTS" might
produce different results for "NULL" values.


这一次顾问不会建议任何结构上的更改(如索引),但会通过用 NOT EXISTS 取代 NOT IN的方式很聪明地猜测到调整查询的正确方式。由于两种构造相似但不相同,顾问给出了这种改变的基本原理,并把决定权留给 DBA 或应用程序开发人员,由他们决定该建议是否对环境有效。
高级调整:SQL 配置文件


正如您可能知道的,优化器通过检查查询中引用的对象统计,来对查询执行计划作出决定,然后计算成本最低的方法。如果查询涉及到一张表以上这种典型情况,优化器就会通过检查所有引用对象的统计来计算成本最低的选项 — 但是它并不知道对象间的关系。
例如,假定一个 DELINQUENT 状态的帐户拥有不到 1000 美元的余额。如果谓词带有一个只筛选 DELINQUENT 的子句,那么连接 ACCOUNTS 表和 BALANCES 表的查询的报告行将较少。优化器不知道这种复杂关系 — 但是顾问知道;它从数据中“组合”了这种关系,并将其以 SQL 配置文件的形式存储起来。通过访问该 SQL 配置文件,优化器不但知道了表的数据分布,而且知道了这些表之间的数据相关系。这个附加信息可以让优化器生成一个高级执行计划,从而获得一个优良的查询。


SQL 配置文件通过手动将查询提示添加到代码中,而无需调整 SQL 语句。因此,SQL Tuning Advisor 使无需修改代码即可调整打包的应用程序成为可能且极具优势。

要点在于,与对象统计不同的是,SQL 配置文件映射到一个查询,而不是映射到一个或多个对象。涉及到同样两个表(ACCOUNTS 和 BALANCES)的另一个查询可能具有不同的配置文件。使用查询中的这种元数据信息,Oracle 就能够改进性能。

如果能够创建一个配置文件,它是在 SQL Tuning Advisor 会话期间完成的,该顾问将在会话中生成配置文件并建议您“接受”。除非接受了配置文件,否则它不会被捆绑到语句上。您可以通过发出如下语句随时接受配置文件:
begin
dbms_sqltune.accept_sql_profile (
task_name => 'FOLIO_COUNT',
name => 'FOLIO_COUNT_PROFILE'
description => 'Folio Count Profile',
category => 'FOLIO_COUNT');
end;

该命令将把顾问先前生成的名为 FOLIO_COUNT_PROFILE 的配置文件捆绑到一条语句上,该语句与前面示例中描述过的名为 FOLIO_COUNT 的调整任务相关联。(注意:尽管 SQL 配置文件只能由顾问而不能由 DBA 创建,但只有您能决定何时使用它。)

您可以在字典视图 DBA_SQL_PROFILES 中查看创建的 SQL 配置文件。SQL_TEXT 列显示分配给配置文件的 SQL 语句;STATUS 列指示是否启用给该配置文件。(即使它已经捆绑到一条语句上,也必须启用配置文件来影响执行计划。)可以从视图 DBMSHSXP_SQL_PROFILE_ATTR 查看配置文件的元数据信息,在该视图中,ATTR_VALUE 列显示了优化器用以确定计划的多种专有信息。

使用 ADDM 和 SQL Tuning Advisor


除了上面描述的三种情形外,SQL Tuning Advisor 还会标识出查询中引用的丢失统计的任何对象。因此,顾问执行四种独特类型的任务:
检查对象是否具有有效的、可用的统计,以进行适当优化
试图重新编写性能更好的查询并就重新编写提出建议
检查访问路径,查看是否能够通过添加额外的结构(如索引和物化视图)来改进性能。
创建 SQL 配置文件,并将它们附加到特定的查询上。
基于这些功能,我可以想到至少三种不同情况,将 ADDM 和 SQL Tuning Advisor 作为功能强大的工具来使用。
反应式调整:您的应用程序突然运行得很糟糕。使用 ADDM,您可以把问题深入剖析到一条 SQL 语句或一组语句的层面上,如 ADDM 一节所示。根据 ADDM 的建议,您可以启动 SQL Tuning Advisor 并矫正问题。
积极式调整:应用程序的运行情况尚好;但是,您希望确保执行了所有必要的维护任务,并知道是否可以对查询进行进一步调整。您将在独立模式下激发 SQL Tuning Advisor,以标识出可能的调整选择。
开发式调整:在开发过程中对代码进行测试时,相对于 QA 阶段或生产阶段,有许多机会可调整查询。在开发最后确定 SQL 语句前,可以使用顾问的命令行版本对这些语句进行单独测试。
使用 Enterprise Manager

前一个示例被有意用来说明如何在命令行模式下使用 SQL Tuning Advisor,该模式对积极编写这些任务的脚本非常有用。但是,在大多数情况下,您需要依据终端用户所报告的问题执行调整。Enterprise Manager 10g 在这些情况下就可以大显身手了。

几个星期以前(第 13 周),向您介绍了更新过的 Enterprise Manager 界面。这里将介绍您将如何用它来诊断和调整 SQL:从 Database 主页单击屏幕底部的 "Advisor Central" 链接,这将启动一个包含所有顾问的页面。接下来,单击屏幕顶部的 "SQL Tuning Advisor",如图 4 所示。



图 4:Enterprise Manager 中的 Advisor Central

您刚才启动了 SQL Tuning Advisor。从下一页选择 "Top SQL",如图 5 所示。



图 5:SQL Tuning Advisors

该操作启动了一个类似于图 6 所示的页面,其中有一个包含多种等待级别的沿时间维进行跟踪的图表。



图 6:顶部的 SQL 选择器

红色椭圆内的灰色矩形区域把焦点置于该图表上。用鼠标拖动该矩形,将其重新定位到 CPU 等待级别为高的位置上(如图中所示)。该页面的下面部分将显示那个时间间隔内相关的 SQL 语句,如图 7 所示。



图 7:选择基于活动性的 SQL 语句

正如您可以看到的,显示在顶部(被红色椭圆形所包围)的 SQL 语句活动性最高,其 CPU 消耗也最大。单击语句 ID 查看该语句的详细信息,这将引出一个如图 8 所示的屏幕。



图 8:SQL 详细信息

在该图中,您可以看到在那个时间段引发 CPU 消耗的确切的 SQL 语句。您可以单击 "Run SQL Tuning Advisor" 按钮(在图中作了标记)运行顾问。这将引出一个类似于图 9 所示的屏幕。



图 9:调度 SQL Tuning Advisor

在顾问调度程序中,您可以确定任务的类型,以及将要做多少分析工作。例如,在上图中,我选择了“全面”分析和顾问将会立即运行。在顾问结束运行后,您可以查看其建议,如图 10 所示。



图 10:顾问建议

我刚才描述的这个过程类似于您在命令行版本中所看到的过程;但是这个流程更反映了真实情况,在那种情况下,您对一个问题作出反应,深入剖析其原因,并接受关于如何修复它的建议。

结论

ADDM 是一个功能强大的“智能”工具,它能够自动根据最佳实践和经验丰富的 Oracel 专业人员公认的方法,来分析性能度量标准和提供建议。这种功能不但能告诉 DBA 发生了什么以及为什么发生,而且最为重要的是,它还指明了下一步怎么做。

虚拟专用数据库 VPD

虚拟专用数据库

五种类型的策略、列相关策略以及列屏蔽使得 VPD 成为 DBA 的安全工具箱中一种功能更加强大的工具

虚拟专用数据库 (VPD) 也称为细粒度访问控制,它提供强大的行级安全功能。它是在 Oracle8i 中推出的,已经受到广泛的欢迎,并且在从教育软件到金融服务等各种应用程序得到采用。


VPD 的工作方法是,通过透明地更改对数据的请求,基于一系列定义的标准向用户提供表的局部视图。在运行时,所有查询都附加了谓词,以便筛选出准许用户看到的行。例如,如果只允许用户查看帐户管理员 SCOTT 的帐户,则 VPD 设置自动地将查询:

select * from accounts;


重写为:

select * from accounts
where am_name = 'SCOTT';


DBA 在表 ACCOUNTS 上设置了一项安全策略。该策略具有一个相关函数,称为policy function,它返回一个用作谓词的字符串 where am_name = 'SCOTT'。如果您不熟悉该特性的全部功能,我建议您阅读 Oracle 杂志的文章“利用 VPD 保持信息的私密性”。

策略类型

生成谓词所需的重复分析是一种在某些情况下可以进行修整的开销。例如,在大部分实际情况中,谓词并不象 am_name = 'SCOTT' 那样是静态的;它基于用户的身份、用户的权限级别、用户向哪个帐户管理员进行报告等情况,可能更具有动态性。由策略函数创建并返回的字符串可能会具有很强 的动态性,而为了保证其结果,Oracle 必须每次重新执行策略函数,既浪费资源又降低性能。在这种类型的策略中,谓词每次执行时可能会有很大的差别,该策略称为“动态”策略,在 Oracle9i 数据库以及以前的版本中已经提供了这种策略。

除了保留动态策略之外,Oracle 数据库 10g 还基于谓词的构造推出了几种新类型的策略,为提高性能提供了更好的控制:context_sensitive、 shared_context_sensitive、shared_static 和 static。现在,让我们来了解每种策略类型的意义以及如何在适当的场合中使用它们。

动态策略。 为保持向后兼容性,10g 中的默认策略类型为“dynamic” — 正如 Oracle9i 中一样。在这种情况下,对于每行以及每位用户,在每次访问表时都对策略函数进行重新求值。让我们来详细分析策略谓词:
where am_name = 'SCOTT'


忽略掉 where 子句,谓词就具有两个不同的部分:在等式操作符之前的部分 (am_name) 和等式操作符之后的部分 ('SCOTT')。在大多数情况下,后面的部分更象是变量,因为它是由用户的数据提供的(如果用户是 SCOTT,则其值为 'SCOTT')。在等号前面的部分是静态的。因此,即使函数不必为生成适当的谓词而对每行求出策略函数的值,由于了解前面部分的静态性以及后面部分的动 态性,也可以提高性能。在 10g 中,可以在 dbms_rls.add_policy 调用中使用 "context_sensitive" 类型的策略作为参数来实现这种方法:
policy_type => dbms_rls.context_sensitive


在另一个示例中,我们有一个称为 ACCOUNTS 的表,它拥有几列,其中一列是 BALANCE,表示帐户余额。假设允许某个用户查看低于某特定余额的帐户,而该余额由应用程序上下文所决定。我们并不在策略函数中将此余额值固定,而是 3是根据应用程序上下文确定,如:
create or replace vpd_pol_func
(
p_schema in varchar2,
p_table in varchar2
)
return varchar2
is
begin
return 'balance < cust_name =" 'ACME';而对于" cust_name =" 'GOLDTONE'。在这里,谓词依赖于他们的" cust_name =" sys_context(''vpdctx''," policy_type =""> dbms_rls.static


这种方法确保策略函数只执行一次。即使应用程序上下文在会话中改变,也从不重新执行该函数,使得此过程的速度非常快。

建议将静态策略用于在几个用户中托管应用程序的情况。在这种情况下,单个数据库拥有几个用户的数据。当每个用户登录时,登录后触发器可以设置用于策略函数的应用程序上下文的值,以便快速生成谓词。

但是,将策略定义为静态也是一把双刃剑。在以上的示例中,我们假设应用程序上下文属性 VPDCTX.CUST_NAME 的值在会话中不改变。如果这种假设不正确,将会怎样呢?如果该值改变,策略函数将不会执行,因此在谓词中将不会使用新值,而返回错误的结果!因此,在将策 略定义为静态时要非常小心;您必须绝对确信该值不会改变。如果您不能作这种假设,则最好将策略定义为对上下文敏感。

共享策略类型。 为了重用代码并最大限度地利用已经分析过的代码,您可以决定为几个表使用通用的策略函数。例如,在上述示例中,我们可能对于不同类型的帐户拥有不同的表 — SAVINGS 和 CHECKING — 但是规则仍然是相同的:限制用户查看余额超过其授权范围的帐户。这种情况要求为 CHECKING 和 SAVINGS 表上的策略使用统一的函数。该策略创建为 context_sensitive。

假设事件按如下顺序发生:

1. 连接会话
2. 设置应用程序上下文
3. select * from savings;
4. select * from checking;

即使应用程序上下文在第 3 步与第 4 步之间没有改变,策略函数也会重新执行,因为现在所选择的表已经不同。这不是我们所希望的情况,因为策略函数相同,不需要重新执行该函数。

10g 中的新功能是能够在对象间共享策略。在上述示例中,您可以将这些策略的策略类型定义为:
policy_type => dbms_rls.shared_context_sensitive


将策略声明为 "shared" 可以在以上所示的情况中不再执行该函数,从而提高了性能。

选择性的列

现在设想一种情况,只有在选择了特定列时才会应用 VPD 策略。在上述示例的表 ACCOUNTS 中,各行如下所示:
ACCTNO ACCT_NAME BALANCE
------ ------------ -------
1 BILL CAMP 1000
2 TOM CONNOPHY 2000
3 ISRAEL D 1500


不允许 Michelle 查看余额超过 1600 的帐户。当她执行类似以下的查询时:
select * from accounts;


她将看到:
ACCTNO ACCT_NAME BALANCE
------ ------------ -------
1 BILL CAMP 1000
3 ISRAEL D 1500


acctno 2 的余额超过 1600,它已禁止显示。对于 Michelle 而言,表中只有两行,而不是三行。当她执行类似以下的查询时:
select count(*) from accounts;


该查询只计算表中的记录数,输出是二,而不是三。
但是,此时我们可以决定将安全策略稍微放松一些。在本查询中,Michelle 不能查看帐户余额等秘密数据;她只是计算表中所有记录的数目。在与安全策略一致的情况下,我们可以允许此查询计算所有记录的数目,无论是否允许她查看这些 记录。如果需要这样,则在对 10g 的 dbms_rls.add_policy 的调用中的另一个参数允许实现此功能:

sec_relevant_cols => 'BALANCE'


现在,当用户选择列 BALANCE 时,无论是显式选择还是隐含在 select * 中,VPD 策略都会介入,对行作出限制。否则将会选择表中所有的行,因为在查询中用户只选择了总计行数,而没有选择列 BALANCE。如果将以上参数设置为所示的形式,则查询
select count(*) from accounts;


将显示三列,而不是两列。但是查询:
select * from accounts;


仍将只返回两条记录,与预期的情况相同。

列屏蔽

现在,让我们对当前的示例再增加些要求。我们不禁止显示那些余额高于阈值的行,而是希望显示所有的行,同时屏蔽那些数值超过阈值的余额列。与安全性相关的列仍然是 BALANCE。

不允许 Michelle 看到余额超过 1600 的帐户。当她执行类似以下的查询时:
select * from accounts;


她将只看到两行,acctnos 1 和 3。但是,我们可能希望她看到:
ACCTNO ACCT_NAME BALANCE
------ ------------ -------
1 BILL CAMP 1000
2 TOM CONNOPHY
3 ISRAEL D 1500


注意,显示都所有行,但是 acctno 2 的列 BALANCE 的值显示为空(显示为 ),它的余额实际上是 2000,超过阈值 1600。这种方法称为“列屏蔽”,可以通过在对 dbms_rls.add_policy 的调用中指定参数来实现:
sec_relevant_cols_opt => dbms_rls.all_rows


在只有某些特定列值很重要的情况下,这种策略才可能非常有用,并且不需要复杂的自定义代码。它也是一种很好的变通方法,不需要对存储数据进行加密。

结论

在 Oracle 数据库 10g 中,VPD 已经发展为一种功能非常强大的特性,它能够支持多种需求,例如基于策略有选择性地屏蔽列,只在访问特定列时应用策略等。利用应用程序特有的性质,还可以通过多种类型的策略来提高策略的性能,使得该特性适用于多种情况。

有关 VPD 和 dbms_rls 程序包的更多信息,请参阅 PL/SQL 程序包和类型参考的第 79 章以及 Oracle 数据库安全指南。您还可以阅读由我与 Don Burleson 合著的一本关于该主题的书籍 Oracle 保密安全性审计 (Rampant TechPress)。

EXPDP和IMPDP使用说明

Oracle Database 10g引入了最新的数据泵(Data Dump)技术,使DBA或开发人员可以将数据库元数据(对象定义)和数据快速移动到另一个oracle数据库中.
数据泵导出导入(EXPDP和IMPDP)的作用
1,实现逻辑备份和逻辑恢复.
2,在数据库用户之间移动对象.
3,在数据库之间移动对象
4,实现表空间搬移.

数据泵导出导入与传统导出导入的区别
在10g之前,传统的导出和导入分别使用EXP工具和IMP工具,从10g开始,不仅保留了原有的EXP和IMP工具,还提供了数据泵导出导入工具EXPDP和IMPDP.使用EXPDP和IMPDP时应该注意的事项;
EXP和IMP是客户段工具程序,它们既可以在可以段使用,也可以在服务段使用.
EXPDP和IMPDP是服务端的工具程序,他们只能在ORACLE服务端使用,不能在客户端使用
IMP只适用于EXP导出文件,不适用于EXPDP导出文件;IMPDP只适用于EXPDP导出文件,而不适用于EXP导出文件.

数据泵导出包括导出表,导出方案,导出表空间,导出数据库4种方式.
EXPDP命令行选项
1. ATTACH
该选项用于在客户会话与已存在导出作用之间建立关联.语法如下
ATTACH=[schema_name.]job_name
Schema_name用于指定方案名,job_name用于指定导出作业名.注意,如果使用ATTACH选项,在命令行除了连接字符串和ATTACH选项外,不能指定任何其他选项,示例如下:
Expdp scott/tiger ATTACH=scott.export_job
2. CONTENT
该选项用于指定要导出的内容.默认值为ALL
CONTENT={ALL | DATA_ONLY | METADATA_ONLY}
当设置CONTENT为ALL 时,将导出对象定义及其所有数据.为DATA_ONLY时,只导出对象数据,为METADATA_ONLY时,只导出对象定义
Expdp scott/tiger DIRECTORY=dump DUMPFILE=a.dump
CONTENT=METADATA_ONLY
3. DIRECTORY
指定转储文件和日志文件所在的目录
DIRECTORY=directory_object
Directory_object用于指定目录对象名称.需要注意,目录对象是使用CREATE DIRECTORY语句建立的对象,而不是OS 目录
Expdp scott/tiger DIRECTORY=dump DUMPFILE=a.dump

建立目录:
CREATE DIRECTORY dump as ‘d:dump’;
查询创建了那些子目录:
SELECT * FROM dba_directories;
4. DUMPFILE
用于指定转储文件的名称,默认名称为expdat.dmp
DUMPFILE=[directory_object:]file_name [,….]
Directory_object用于指定目录对象名,file_name用于指定转储文件名.需要注意,如果不指定directory_object,导出工具会自动使用DIRECTORY选项指定的目录对象
Expdp scott/tiger DIRECTORY=dump1 DUMPFILE=dump2:a.dmp
5. ESTIMATE
指定估算被导出表所占用磁盘空间分方法.默认值是BLOCKS
EXTIMATE={BLOCKS | STATISTICS}
设置为BLOCKS时,oracle会按照目标对象所占用的数据块个数乘以数据块尺寸估算对象占用的空间,设置为STATISTICS时,根据最近统计值估算对象占用空间
Expdp scott/tiger TABLES=emp ESTIMATE=STATISTICS
DIRECTORY=dump DUMPFILE=a.dump

6. EXTIMATE_ONLY
指定是否只估算导出作业所占用的磁盘空间,默认值为N
EXTIMATE_ONLY={Y | N}
设置为Y时,导出作用只估算对象所占用的磁盘空间,而不会执行导出作业,为N时,不仅估算对象所占用的磁盘空间,还会执行导出操作.
Expdp scott/tiger ESTIMATE_ONLY=y NOLOGFILE=y
7. EXCLUDE
该选项用于指定执行操作时释放要排除对象类型或相关对象
EXCLUDE=object_type[:name_clause] [,….]
Object_type用于指定要排除的对象类型,name_clause用于指定要排除的具体对象.EXCLUDE和INCLUDE不能同时使用
Expdp scott/tiger DIRECTORY=dump DUMPFILE=a.dup EXCLUDE=VIEW
8. FILESIZE
指定导出文件的最大尺寸,默认为0,(表示文件尺寸没有限制)
9. FLASHBACK_SCN
指定导出特定SCN时刻的表数据
FLASHBACK_SCN=scn_value
Scn_value用于标识SCN值.FLASHBACK_SCN和FLASHBACK_TIME不能同时使用
Expdp scott/tiger DIRECTORY=dump DUMPFILE=a.dmp
FLASHBACK_SCN=358523
10. FLASHBACK_TIME
指定导出特定时间点的表数据
FLASHBACK_TIME=”TO_TIMESTAMP(time_value)”
Expdp scott/tiger DIRECTORY=dump DUMPFILE=a.dmp FLASHBACK_TIME=
“TO_TIMESTAMP(’25-08-2004 14:35:00’,’DD-MM-YYYY HH24:MI:SS’)”

11. FULL
指定数据库模式导出,默认为N
FULL={Y | N}
为Y时,标识执行数据库导出.
12. HELP
指定是否显示EXPDP命令行选项的帮助信息,默认为N
当设置为Y时,会显示导出选项的帮助信息.
Expdp help=y
13. INCLUDE
指定导出时要包含的对象类型及相关对象
INCLUDE = object_type[:name_clause] [,… ]
14. JOB_NAME
指定要导出作用的名称,默认为SYS_XXX
JOB_NAME=jobname_string
15. LOGFILE
指定导出日志文件文件的名称,默认名称为export.log
LOGFILE=[directory_object:]file_name
Directory_object用于指定目录对象名称,file_name用于指定导出日志文件名.如果不指定directory_object.导出作用会自动使用DIRECTORY的相应选项值.
Expdp scott/tiger DIRECTORY=dump DUMPFILE=a.dmp logfile=a.log
16. NETWORK_LINK
指定数据库链名,如果要将远程数据库对象导出到本地例程的转储文件中,必须设置该选项.
17. NOLOGFILE
该选项用于指定禁止生成导出日志文件,默认值为N.
18. PARALLEL
指定执行导出操作的并行进程个数,默认值为1
19. PARFILE
指定导出参数文件的名称
PARFILE=[directory_path] file_name
20. QUERY
用于指定过滤导出数据的where条件
QUERY=[schema.] [table_name:] query_clause
Schema 用于指定方案名,table_name用于指定表名,query_clause用于指定条件限制子句.QUERY选项不能与CONNECT= METADATA_ONLY,EXTIMATE_ONLY,TRANSPORT_TABLESPACES等选项同时使用.
Expdp scott/tiger directory=dump dumpfiel=a.dmp
Tables=emp query=’WHERE deptno=20’
21. SCHEMAS
该方案用于指定执行方案模式导出,默认为当前用户方案.
22. STATUS
指定显示导出作用进程的详细状态,默认值为0
23. TABLES
指定表模式导出
TABLES=[schema_name.]table_name[:partition_name][,…]
Schema_name用于指定方案名,table_name用于指定导出的表名,partition_name用于指定要导出的分区名.
24. TABLESPACES
指定要导出表空间列表
25. TRANSPORT_FULL_CHECK
该选项用于指定被搬移表空间和未搬移表空间关联关系的检查方式,默认为N.
当 设置为Y时,导出作用会检查表空间直接的完整关联关系,如果表空间所在表空间或其索引所在的表空间只有一个表空间被搬移,将显示错误信息.当设置为N时, 导出作用只检查单端依赖,如果搬移索引所在表空间,但未搬移表所在表空间,将显示出错信息,如果搬移表所在表空间,未搬移索引所在表空间,则不会显示错误 信息.

26. TRANSPORT_TABLESPACES
指定执行表空间模式导出
27. VERSION
指定被导出对象的数据库版本,默认值为COMPATIBLE.
VERSION={COMPATIBLE | LATEST | version_string}
为COMPATIBLE时,会根据初始化参数COMPATIBLE生成对象元数据;为LATEST时,会根据数据库的实际版本生成对象元数据.version_string用于指定数据库版本字符串.

调用EXPDP
使用EXPDP工具时,其转储文件只能被存放在DIRECTORY对象对应的OS目录中,而不能直接指定转储文件所在的OS目录.因此,使用EXPDP工具时,必须首先建立DIRECTORY对象.并且需要为数据库用户授予使用DIRECTORY对象权限.
CREATE DIRECTORY dump dir AS ‘D:DUMP’;
GRANT READ, WIRTE ON DIRECTORY dump_dir TO scott;
1,导出表
Expdp scott/tiger DIRECTORY=dump_dir DUMPFILE=tab.dmp TABLES=dept,emp
2,导出方案
Expdp scott/tiger DIRECTORY=dump_dir DUMPFILE=schema.dmp
SCHEMAS=system,scott
3.导出表空间
Expdp system/manager DIRECTORY=dump_dir DUMPFILE=tablespace.dmp
TABLESPACES=user01,user02
4,导出数据库
Expdp system/manager DIRECTORY=dump_dir DUMPFILE=full.dmp FULL=Y


使用IMPDP
IMPDP命令行选项与EXPDP有很多相同的,不同的有:
1,REMAP_DATAFILE
该选项用于将源数据文件名转变为目标数据文件名,在不同平台之间搬移表空间时可能需要该选项.
REMAP_DATAFIEL=source_datafie:target_datafile
2,REMAP_SCHEMA
该选项用于将源方案的所有对象装载到目标方案中.
REMAP_SCHEMA=source_schema:target_schema
3,REMAP_TABLESPACE
将源表空间的所有对象导入到目标表空间中
REMAP_TABLESPACE=source_tablespace:target:tablespace
4.REUSE_DATAFILES
该选项指定建立表空间时是否覆盖已存在的数据文件.默认为N
REUSE_DATAFIELS={Y | N}
5.SKIP_UNUSABLE_INDEXES
指定导入是是否跳过不可使用的索引,默认为N


6,SQLFILE
指定将导入要指定的索引DDL操作写入到SQL脚本中
SQLFILE=[directory_object:]file_name
Impdp scott/tiger DIRECTORY=dump DUMPFILE=tab.dmp SQLFILE=a.sql
7.STREAMS_CONFIGURATION
指定是否导入流元数据(Stream Matadata),默认值为Y.
8,TABLE_EXISTS_ACTION
该选项用于指定当表已经存在时导入作业要执行的操作,默认为SKIP
TABBLE_EXISTS_ACTION={SKIP | APPEND | TRUNCATE | FRPLACE }
当 设置该选项为SKIP时,导入作业会跳过已存在表处理下一个对象;当设置为APPEND时,会追加数据,为TRUNCATE时,导入作业会截断表,然后为 其追加新数据;当设置为REPLACE时,导入作业会删除已存在表,重建表病追加数据,注意,TRUNCATE选项不适用与簇表和 NETWORK_LINK选项
9.TRANSFORM
该选项用于指定是否修改建立对象的DDL语句
TRANSFORM=transform_name:value[:object_type]
Transform_name 用于指定转换名,其中SEGMENT_ATTRIBUTES用于标识段属性(物理属性,存储属性,表空间,日志等信息),STORAGE用于标识段存储属 性,VALUE用于指定是否包含段属性或段存储属性,object_type用于指定对象类型.
Impdp scott/tiger directory=dump dumpfile=tab.dmp
Transform=segment_attributes:n:table
10.TRANSPORT_DATAFILES
该选项用于指定搬移空间时要被导入到目标数据库的数据文件
TRANSPORT_DATAFILE=datafile_name
Datafile_name用于指定被复制到目标数据库的数据文件
Impdp system/manager DIRECTORY=dump DUMPFILE=tts.dmp
TRANSPORT_DATAFILES=’/user01/data/tbs1.f’

调用IMPDP
1, 导入表
Impdp scott/tiger DIRECTORY=dump_dir DUMPFILE=tab.dmp
TABLES=dept,emp

Impdp system/manage DIRECTORY=dump_dir DUMPFILE=tab.dmp
TABLES=scott.dept,scott.emp REMAP_SCHEMA=SCOTT:SYSTEM
第一种方法表示将DEPT和EMP表导入到SCOTT方案中,第二种方法表示将DEPT和EMP表导入的SYSTEM方案中.
注意,如果要将表导入到其他方案中,必须指定REMAP SCHEMA选项.

2,导入方案
Impdp scott/tiger DIRECTORY=dump_dir DUMPFILE=schema.dmp
SCHEMAS=scott

Impdp system/manager DIRECTORY=dump_dir DUMPFILE=schema.dmp
SCHEMAS=scott REMAP_SCHEMA=scott:system
3,导入表空间
Impdp system/manager DIRECTORY=dump_dir DUMPFILE=tablespace.dmp
TABLESPACES=user01
4,导入数据库
Impdp system/manager DIRECTORY=dump_dir DUMPFILE=full.dmp FULL=y