在Oracle 18c上设置MAX_DUMP_FILE_SIZE参数时，为什么我得到的ORA-44737参数不存在？

这是我的代码，非常简单，但它不起作用。谢谢大家!

begin
    -- to set the max dump file size for a given session
    sys.dbms_system.set_int_param_in_session(
        217,
        36575,
        'MAX_DUMP_FILE_SIZE',
        1073741824
    );
end;

它产生：

ORA-44737: Parameter MAX_DUMP_FILE_SIZE did not exist.
ORA-06512: at "SYS.DBMS_SYSTEM", line 122
ORA-06512: at line 3

---

似乎18c只是报告了一个11g过去一直默默忽略的错误；也就是说，参数名不存在，或者至少不是过程的正确类型。在11g中，这没有出错，但也没有做任何事情。作为普通用户：

select name, type, display_value
from v$parameter
where name in ('max_dump_file_size', 'sort_area_size');

NAME                                 TYPE DISPLAY_VALUE
------------------------------ ---------- ------------------------------
sort_area_size                          3 65536
max_dump_file_size                      2 unlimited

在识别该会话之后：

begin
    sys.dbms_system.set_int_param_in_session(
        209,
        34295,
        'MAX_DUMP_FILE_SIZE',
        123456
    );
    sys.dbms_system.set_int_param_in_session(
        209,
        34295,
        'SORT_AREA_SIZE',
        123456
    );
end;
/

PL/SQL procedure successfully completed.

在原始用户的会话中：

select name, type, display_value
from v$parameter
where name in ('max_dump_file_size', 'sort_area_size');

NAME                                 TYPE DISPLAY_VALUE
------------------------------ ---------- ------------------------------
sort_area_size                          3 123456
max_dump_file_size                      2 unlimited

sort\u area\u size

更改已生效。

max\u dump\u file\u size

没有-但它没有报告或投诉。事实上，您可以传递任何您喜欢的参数名，它仍然会默默地忽略它

在18c中，它不再沉默，因此您可以看到ORA-44737错误

它抱怨的原因似乎归结于过程的名称——

set_int_param_in_session

——以及参数类型。它适用于

sort\u area\u size

，因为；但是

max\u dump\u file\u size

。如果错误表示“参数MAX\u DUMP\u FILE\u SIZE不存在或类型错误”，则可能会更有帮助，但您不能拥有所有内容

您正试图传递一个整数值，但可能没有传递，而且无法将

作为数字参数“UNLIMITED”

传递。在这种情况下，它可能已经被写入允许数字值，但您将无法重置它，这将是有问题的

不幸的是，在会话中没有一个等价的

set_str_param_过程，而且由于它是一个未记录且不受支持的包，因此您不太可能要求Oracle添加一个

我不认为有任何方法可以做你在另一个会议上尝试的事情

我也不知道如何通过配置文件或资源管理器应用此功能。通过一些预先计划，您可能有一种方法告诉Apex（例如，通过某个地方的参数）自行设置，但这听起来需要做很多工作。使用登录触发器通过
alter session
调用始终设置这一点可能更简单（对于某些用户，或者对于某个角色），因此在启动跟踪时不必考虑它。
我不确定我是否同意代码是直接的，因为DBMS\U系统是一个未记录的包。您不使用文档化的
alter会话集max\u dump\u file\u size=1073741824有什么原因吗相反？如何使用alter session限制此特定用户的转储大小？谢谢大家!@AlexPoole这会更改我会话的变量，而不是其他用户会话的变量。@AlexPoole，您可以更改其他用户的会话。我想这就是set_init_param_in_session所做的。它适用于我的Oracle 11服务器，但不适用于我的Oracle 18服务器。是的，这是通过Apex控制的程序的一部分。它设置用户参数，然后用户在DB上执行操作，然后当操作完成时，Apex应用程序可以关闭该会话的跟踪。你太棒了！是的，我还发现，由于沉默的忽视，这实际上一直在起作用。我只是使用“ALTER SYSTEM SET MAX\u DUMP\u FILE\u SIZE=123”，然后在完成后将其更改回原处。谢谢你这篇精彩的文章！