Sql 正在运行多天的存储过程。。。。我的语法有什么问题吗'；是什么导致它无限循环？

我有一个存储过程在游标中循环，直到找不到更多的条目。根据我得到的数据结构，它提取了所有尚未用于求和计算的“小时时间戳”。这些计算是通过将这些“小时时间戳”作为输入参数插入子程序的where子句（即PROC1）来完成的。当我从光标中进行计数（*）时，我会得到157000个条目（这意味着我最多只能有一百万个条目）。超过2天的百万条记录似乎不正确。在我的代码中是否有我可能遗漏的可能导致这种情况发生的东西？（以下是我的代码的简化版本）

提前谢谢

create or replace PROCEDURE RUN_AGG
is
 v_Flag_id NUMBER;
  CURSOR hours IS
    SELECT distinct(HR) as RHR
    , submission_value_id
    from (
    select  
        v.DATA_DATE,
        v.HR,
        sv.submission_value_id
     from value v
     inner join submission_value sv on sv.value_id = v.value_id
     where sv.SUBMISSION_VALUE_ID NOT IN (
     SELECT SUBMISSION_VALUE_ID FROM VALUE_FLAG WHERE VALUE_FLAG.FLAG_ID =   (SELECT FLAG_ID from FLAG where FLAG_TX = 'Processed'))
  ));
l_hr hours%ROWTYPE;
BEGIN
  SELECT FLAG_ID into v_flag_id from FLAG where FLAG_TX = 'Processed';
OPEN hours;
 LOOP 
    FETCH hours into l_hr;
    EXIT WHEN hours%NOTFOUND;
      PROC1(l_hr.RHR);
      PROC2(l_hr.RHR);
      PROC3(l_hr.RHR);
      PROC4(l_hr.RHR);
      PROC5(l_hr.RHR);
      insert into value_flag (value_flag_id, submission_value_id, value_flag_type_id)
                      values (null, l_hr.submission_value_id, (select value_flag_type_id from value_flag_type where value_flag_tx = 'AGG_HOURLY'));
END LOOP;
CLOSE hours;

不确定是否相关或是否有帮助，但5个“子过程”是基于不同过滤/where标准按小时汇总的过程。下面是每个过程的示例：

create or replace PROCEDURE PROC1(rHR IN TIMESTAMP WITH TIME ZONE) 
is
CURSOR c1 is
select  SUM(v.value_tx)as sum_of_values
      , v.data_Code
      , v.region_id
      , v.hr
      , ABS(tz.TIME_ZONE_OFFSET) as utc_offset
  from value v
  inner join submission_value sv on v.value_id = sv.value_id
  inner join region r on r.REGION_ID = v.REGION_ID
  left join time_zone tz on r.TIME_ZONE_ID = tz.TIME_ZONE_ID
 where ff.form_field_tx in ('SAMPLE', 'NO')
   and sv.submission_value_id in (
    select
        distinct(max(sv_all.submission_value_id) over (partition by v9.auth_code, v9.data_date, form_field_id, v9.data_code, v9.hr)) max_svid 
    from submission_value sv_all 
        inner join value v9 on v9.value_id = sv_all.value_id
        where v9.HR = rHR
        )   
   and v.HR = rHR
group by v.region_id, ff.form_field_id, ff.form_field_tx, v.hr, v.data_code, ABS(tz.TIME_ZONE_OFFSET);
  l_var c1%ROWTYPE;
  v_value_id value.value_id%type;
BEGIN
Open c1;
     FETCH c1 into l_var;
              insert into calculation (calculation_id, calculation_date, calculation_name, report_period_dt)
                               values (null, sysdate, 'AGG_HR_REG ' || trunc(rHR) || ' ' || to_char(sysdate, 'hh24:mi:ss'), trunc(l_var.hr))
Close c1;
Open c1;
LOOP
     FETCH c1 into l_var;
     EXIT WHEN c1%NOTFOUND;
          insert into value (value_id, energy_product_id, data_source_id, unit_cd, value_tx, utc_offset, data_date, hr_utc, hr, hr_num, data_code)
                         values (null, '1', '2', 'NA', l_var.sum_of_values, l_var.utc_offset, null, null, l_var.hr, null, l_var.data_code)
      END LOOP;
      CLOSE c1;
commit;
END PROC1;

---

任何指点都将不胜感激。谢谢大家!

你需要通过优化来分而治之。单独运行每个查询/子查询，看看是否可以识别瓶颈。如果所有查询只快速运行，那么您需要考虑重构游标逻辑。您确定所有子进程中的所有游标循环都有退出条件吗？如果使用隐式游标循环而不是显式的open/loop/fetch模式，您可能会发现这更容易。您是否排除了另一个未提交更改的会话阻止您尝试插入的可能性？@Error\u 2646谢谢，我会这样做。感谢you@AlexPoole是的，我回去检查过了，他们确实检查过了。我将研究隐式游标循环，因为我对它们不太熟悉。此外，在运行此存储过程之前，我已提交了所有更改。顺便说一下，谢谢<代码>对于一百万个条目来说，超过2天似乎是不正确的。-这取决于每个过程需要多长时间。假设一个过程平均需要200毫秒，乘以5次（5个过程），乘以157.000条记录，那么整个过程将需要43小时。但是，如果每个过程需要1000毫秒而不是200毫秒，那么整个过程将需要215小时（9天）。您是否分析了代码和测量时间？