2

过程 PROCESS_EMP 引用表 EMP。过程 UPDATE_EMP 通过过程 PROCESS_EMP 更新表 EMP 的行。有一个远程过程 QUERY_EMP 通过本地过程 PROCESS_EMP 查询 EMP 表。在此会话中,依赖模式设置为 TIMESTAMP。哪两种说法是正确的?

1)如果PROCESS_EMP过程的签名被修改并成功重新编译,则EMP表无效。

2) 如果PROCESS_EMP过程的内部逻辑被修改并成功重新编译,则UPDATE_EMP失效并在第一次调用时重新编译。

3) 如果PROCESS_EMP 过程的签名被修改并成功重新编译,UPDATE_EMP 将失效并在第一次调用时重新编译。

4) 如果PROCESS_EMP 过程的内部逻辑被修改并成功重新编译,则QUERY_EMP 将失效并在第一次调用时重新编译。

5) 如果PROCESS_EMP 过程的内部逻辑被修改并成功重新编译,则QUERY_EMP 将失效并在第二次调用时重新编译。

据我所知,签名是返回类型和参数列表的组合。

1) 如果 PROCESS_EMP 的签名发生变化,它与 EMP 表无关,因为它本身正在引用 EMP。

2)这是正确的选择。UPDATE_EMP 使用 PROCESS_EMP 更新 EMP 表。如果 PROCESS_EMP 的内部逻辑发生变化,那么它如何影响 UPDATE_EMP ?如果 UPDATE_EMP 正在使用 PROCESS_EMP,那么它应该调用它。内部逻辑的更改包含在 PROCESS_EMP 中的主体中,而不是 UPDATE_EMP 中。

3)我认为这一定是正确的。但这是错误的。如果在 PROCESS_EMP 中更改了签名。就像如果返回类型或参数数量或两者都被修改,那么调用方式会受到影响。因此,UPDATE_EMP 应该受到影响。为什么是假的?

4) 和 5) 4 点不正确。我没有得到这个“第一次”和“第二次”。为什么是第二次?为什么不是第一次?5分是正确的。*

4

2 回答 2

1

3 和 5。

但是不要相信我的话,让我们测试一下。

创建测试对象

--Remote dependency mode
alter session set remote_dependencies_mode = timestamp;

--Table
drop table emp purge;
create table emp(id number, name varchar2(100));
insert into emp values(1, 'asdf');
commit;

--Database link - you don't need two databases, you can link to yourself
drop database link myself;
create database link myself connect to <user> identified by <password> using '<database>';
select * from dual@myself;

--Procedures
create or replace procedure process_emp(action_type in varchar2) is
    v_count number;
begin
    if action_type = 'U' then
        update emp set name = upper(name);
    elsif action_type = 'Q' then
        select count(*) into v_count from emp;
    end if;
end;
/

create or replace procedure update_emp is
begin
    process_emp('U');
end;
/

create or replace procedure query_emp is
begin
    process_emp@myself('Q');
end;
/

--Initial object times
select object_name, last_ddl_time, status
from user_objects
where object_name in ('PROCESS_EMP', 'UPDATE_EMP', 'QUERY_EMP')
order by last_ddl_time;

PROCESS_EMP 2013-04-02 00:25:47 VALID
UPDATE_EMP  2013-04-02 00:25:48 VALID
QUERY_EMP   2013-04-02 00:25:49 VALID

测试

1)如果PROCESS_EMP过程的签名被修改并成功重新编译,则EMP表无效。

错误- 甚至没有什么可以测试的。没有无效表之类的东西。(可能对象关系表除外,但我认为这不适用于这里。)

2) 如果PROCESS_EMP过程的内部逻辑被修改并成功重新编译,则UPDATE_EMP失效并在第一次调用时重新编译。

False - UPDATE_EMP 仍然有效,并且不会重新编译。LAST_DDL_TIME 不会改变。通常,一个过程只通过它的签名知道——如果它没有改变,那么就没有必要改变其他任何东西。

create or replace procedure process_emp(action_type in varchar2) is
    v_count number;
begin
    if action_type = 'U' then
        update emp set name = upper(name);
    elsif action_type = 'Q' then
        select count(*)+1 into v_count from emp;
    end if;
end;
/

select object_name, last_ddl_time, status
from user_objects
where object_name in ('PROCESS_EMP', 'UPDATE_EMP', 'QUERY_EMP')
order by last_ddl_time;

UPDATE_EMP  2013-04-02 00:25:48 VALID
QUERY_EMP   2013-04-02 00:25:49 VALID
PROCESS_EMP 2013-04-02 00:29:20 VALID

3) 如果PROCESS_EMP 过程的签名被修改并成功重新编译,UPDATE_EMP 将失效并在第一次调用时重新编译。

True - 更改参数可能会更改调用过程的方式。大多数更改都会导致失败,但在许多情况下,依赖过程将重新编译并且一切都会好起来的。例如,如果您添加一个默认参数:

create or replace procedure process_emp(action_type in varchar2, new_param in varchar2 default null) is
    v_count number;
begin
    if action_type = 'U' then
        update emp set name = upper(name);
    elsif action_type = 'Q' then
        select count(*)+1 into v_count from emp;
    end if;
end;
/

--Now the object is invalid:
select status from user_objects where object_name in ('UPDATE_EMP');
INVALID

--But no need to worry, just run it and it will automatically recompile and work correctly:
begin
    update_emp;
end;
/

select status from user_objects where object_name in ('UPDATE_EMP');
VALID

4) 如果PROCESS_EMP 过程的内部逻辑被修改并成功重新编译,则QUERY_EMP 将失效并在第一次调用时重新编译。

False - QUERY_EMP 仍然有效,但在第一次调用时会失败,并且不会重新编译。事实上,即使像我们上面所做的那样更改参数也不会使这一点无效。

select object_name, last_ddl_time, status
from user_objects
where object_name in ('QUERY_EMP')
order by last_ddl_time;

QUERY_EMP   2013-04-02 00:25:49 VALID

begin
    query_emp@myself;
end;
/

ORA-04062: timestamp of procedure "JHELLER.PROCESS_EMP" has been changed
ORA-06512: at "JHELLER.QUERY_EMP", line 3
ORA-06512: at line 2

View program sources of error stack?

5) 如果PROCESS_EMP 过程的内部逻辑被修改并成功重新编译,则QUERY_EMP 将失效并在第二次调用时重新编译。

True - QUERY_EMP 将失效(尽管直到第一次之后),然后第二次正确重新编译。查询运行,并且 LAST_DDL_TIME 现在已更新。

begin
    query_emp@myself;
end;
/

select object_name, last_ddl_time, status
from user_objects
where object_name in ('QUERY_EMP')
order by last_ddl_time;

QUERY_EMP   2013-04-02 00:37:01 VALID
于 2013-04-02T05:49:26.237 回答
1

第三点和第五点是对的。

你有第三点的原因。

第 5 点成立的原因:

  • 依赖模式设置为TIMESTAMP.

  • 当过程的内部逻辑PROCESS_EMP被修改并成功重新编译时,它的TIMESTAMP变化。您可以通过查询USER_OBJECTS视图来检查。

  • 所有依赖的程序PROCESS_EMP都立即失效。您也可以通过查询USER_OBJECTS视图来检查这一点。因此,当这些过程(如UPDATE_EMP)在第一次调用时被重新编译。

  • QUERY_EMP但是任何依赖的远程过程,例如,PROCESS_EMP都不会立即失效。在重新编译依赖过程后第一次调用它们后,它们将失效。因此QUERY_EMP第一次调用时不会重新编译。您可以通过USER_OBJECTS在调用之前和之后查询远程数据库上的视图来检查这一点QUERY_EMP

  • QUERY_EMP第二次调用时,由于状态无效,需要重新编译,签名没有变化,PROCESS_EMP成功重新编译执行。

有关更多信息,请阅读此处此处的 Oracle 文档。

于 2013-04-02T05:48:51.020 回答