小编fil*_*ppo的帖子

包含我的 Oracle 11g 安装的分区开始填满跟踪文件，当我去寻找这些文件时，我发现了这篇关于如何禁用跟踪文件生成的令人不安的帖子。

我有两个相关的问题是：

1. 我可以简单地从我的 FS 中删除这些跟踪文件而不会有任何后果吗？（我知道，如果他们出现了，人们可能应该看看他们......但不会发生，而且数据库没有任何生产用途。下次必须发生。）
2. 应该怎么做才能防止它再次出现？

我正在一些大表中运行查询，尽管它运行良好，即使是大量数据也很困难，但我想了解它的哪一部分对执行有影响。不幸的是，我不太擅长解释计划，所以我寻求帮助。

以下是有关这些表的一些数据：

• history_state_table 7.424.65行（其中只有13.412被后留下的t1.alarm_type = 'AT1'）
• costumer_price_history 448.284.169行
• cycle_table 215行

这将是查询（不要介意逻辑，仅供参考）：

SELECT t1.id_alarm, t2.load_id, t2.reference_date
  FROM history_state_table t1,
       (SELECT   op_code, contract_num,
                 COUNT (DISTINCT id_ponto) AS num_pontos,
                 COUNT
                    (DISTINCT CASE
                        WHEN vlr > 0
                           THEN id_ponto
                        ELSE NULL
                     END
                    ) AS bigger_than_zero,
                 MAX (load_id) AS load_id,
                 MAX (reference_date) AS reference_date
            FROM costumer_price_history
           WHERE load_id IN
                            (42232, 42234, 42236, 42238, 42240, 42242, 42244) /* arbitrary IDs depending on execution*/
             AND sistema = 'F1'          /* Hardcoded …

我正在处理一个相当庞大的 ETL 处理，它不断向我抛出ORA-12549错误。

一直在寻找数据库中的问题，至今一无所获。DBA 说数据库“很好” - 有资源，没有达到要打开或处理的最大文件数，并且在所有表空间上都有空间。

我开始怀疑这个错误是否可能是由客户端抛出的。但是它是一个使用JDBC连接的Java应用程序，堆大小为16GB，根据GC日志也几乎没有填满。

这个过程本身相当简单：在 Oracle 中进行大量选择，对数据应用一些逻辑，然后定期提交到另一个表。我使用了从 500 万行到仅仅 10 万行的提交（分为 100 批 1k 行）。错误总是在同一点上。

有人能给我一些关于正在发生的事情的见解吗？我应该去哪里寻找线索？

客户端，ulimit 是 1024（在 Oracle 的服务器上是 65k），这有关系吗？

这个查询并不太复杂：

select
    trunc(created_date, 'MONTH') as created_date,
    al.op_name,
    al.region,
    al.alarm_type,
     COUNT(1) as total_new,
     SUM(
        (SELECT
            COUNT(1)
         from alarm_table ial
            WHERE ial.status_alarm = 'SOLVED'
            AND TRUNC(ial.solved_date, 'MONTH') = TRUNC(al.created_date, 'MONTH')
            AND ial.region = al.region
            AND ial.op_name = al.op_name
            AND ial.alarm_type = al.alarm_type)
    ) as total_solved
FROM
    alarm_table al
WHERE
    created_date is not null
group by
    trunc(al.created_date, 'MONTH'),
    al.op_name,
    al.region,
    al.alarm_type
order by trunc(al.created_date, 'MONTH') desc

这是它的解释计划：

Plan
SELECT STATEMENT  ALL_ROWSCost: 5,497           
    3 SORT AGGREGATE  Bytes: 51  Cardinality: 1         
        2 TABLE ACCESS BY …