ORACLE数据库同步故障处理专题.doc

资料编码产品名称IVAS使用对象语音增值工程师产品版本编写部门语音增值团队资料版本V1.0ORACLE数据库同步故障处理专题拟 制：刘建军日 期：2007-05-30审 核：丁杰日 期：2007-06-20审 核：日 期：批 准：日 期：华 为 技 术 有 限 公 司版权所有 侵权必究Oracle数据库同步故障处理专题内部公开修订记录日期修订版本描述作者2007-05-3010初稿刘建军华为机密，未经许可不得扩散目 录第1章 需同步的表、字段、索引11.1 问题描述11.2 解决办法1第2章 管理节点MLOG高水位问题22.1 问题描述22.2 分析过程22.3 原因分析22.4 解决办法3第3章 数据库存在阻塞锁导致同步JOB不能执行63.1 问题描述63.2 分析过程63.3 解决办法7第4章 管理节点MLOG$表中数据不能自动删除94.1 问题描述94.2 分析过程94.3 原因分析94.4 解决办法9第5章 呼叫节点唯一性索引冲突引起数据库同步中断115.1 问题描述115.2 分析过程115.3 原因分析115.4 解决办法11第6章 Revoke彩铃数据库用户DBA权限后同步中断136.1 问题描述136.2 分析过程136.3 原因分析146.4 解决办法14第7章 节点同步或单表同步时ORA-12034错误处理157.1 问题描述157.2 分析过程157.3 原因分析157.4 解决办法15第8章 呼叫节点同步job 下一次执行时间为4000年问题168.1 问题描述168.2 原因分析168.3 解决办法16第9章 彩铃数据库exp/imp操作导致数据库同步异常179.1 问题描述179.2 原因分析179.3 解决办法17第10章 MV LOG缺失导致同步节点redo log切换频繁1910.1 问题描述1910.2 分析过程1910.3 原因分析2010.4 解决办法20关键词：IVAS、数据库同步摘 要：目前彩铃系统中采用只读物化视图增量复制方式来搭建数据库之间同步环境，即将管理节点的数据在指定间隔时间内把增量的数据同步到呼叫节点的物化视图中。呼叫节点物化视图中的数据只能被查询，不能被更新。数据库同步操作方法请参考彩铃Oracle9i数据库同步安装指导书UNIX-UNIX V3.2-20070518-B指导书，本文仅针对网上运行中出现的一些常见Oracle数据库同步问题进行整理、解答。数据库单表同步请参考彩铃Oracle数据库同步单表恢复指导书UNIX-UNIX V1.0-20070105以及配套脚本。缩略语清单：参考资料清单：彩铃Oracle9i数据库同步安装指导书UNIX-UNIX V3.2-20070518-B华为机密，未经许可不得扩散第1章 需同步的表、字段、索引1.1 问题描述经常听到一线工程师提出不知道怎么确定在同步环境中需要同步哪些表、字段，管理节点物化视图日志MLOG开头表以及呼叫节点同步表需要建立哪些索引。1.2 解决办法具体请参考Oracle9i数据库同步安装指导书UNIX-UNIX 文档以及配套脚本。1. 首先在管理节点数据库sqlplus环境下运行脚本sync.sql：2. 运行如下语句查询上面脚本执行后是否正常select object_name, status from user_objects where object_name = upper(p_tmp_syncobject);注：STATUS为VALID表明存储过程有效，没有异常3. 在SQLPLUS环境下运行：SQL exec p_tmp_syncobject; 如果运行过程中没有报错，则正常。4. 查询同步环境中需要同步的所有表对象：select content from t_tmp_mlogobject where type=tables;5. 查询同步环境中需要同步表的字段：select content from t_tmp_mlogobject where type=columns;6. 查询同步环境中管理节点MLOG开头表需要建索引的脚本：select content from t_tmp_mlogobject where type=master_mlog_pk or type = master_mlog_index;7. 查询同步环境中呼叫节点同步表需要建索引的脚本：select content from t_tmp_mlogobject where type=sync_index;第2章 管理节点MLOG高水位问题2.1 问题描述某省彩铃系统业务升级后一段时间，小型机的WIO异常升高，数据库数据文件所在磁盘阵列的IO繁忙率经常保持在100%（而升级前磁盘IO繁忙率不超过10%），严重影响系统性能。2.2 分析过程为分析问题原因，让现场做了几个statspack报告分析，发现db file scattered read等待事件占用了系统近64%的等待时间。db file scattered read通常显示与全表扫描有关的等待，这表明数据库执行了过多的全表扫描。一般来说，这个等待事件过高，可能说明对某些经常访问的表没有创建索引或索引建的不合适，导致应用程序的SQL不能使用索引。（当然这也并不绝对，在某些情况下，oracle会主动使用全表扫描来代替索引扫描来提高性能。）于是进一步检查statspack报告的SQL部分。因为db file scattered read等待事件过高，所以我们重点检查报告中SQL ordered by Reads的SQL语句。我们发现以下几条SQL产生了最高的物理读，并且执行频率比较频繁：delete from RING.MLOG$_T_LOOPTONE where snaptime$ = :1SELECT /*+ */ A2.PHONENUMBER,A2.TONEGROUPID,A2.LOOPNO,A2.TONECODE FROM RING.T_LOOPTONE A2, (SELECT /*+ */DISTINCT A3.LOOPNO LOOPNO,A3.TONEGROUPID TONEGROUPID FROM RING.MLOG$_T_LOOPTONE A3 WHERE A3.SNAPTIME$:1AND A3.DMLTYPE$D) A1 WHERE A2.LOOPNO=A1.LOOPNO2.3 原因分析仔细分析这些SQL，我们发现它们都是由oracle自己生成的（可以从sql使用的hint和涉及的表名看出）。彩铃数据库使用了oracle的高级复制技术，利用实体化视图(materialized view)在不同数据库节点间同步数据，这些SQL就是在做数据同步时自动产生的。从报告中可以看到，这些SQL都涉及MLOG$_T_LOOPTONE表，这个表是实体化视图t_looptone的log表。oracle利用实体化视图的log表来跟踪每张实体化视图主表的变化情况，在正常情况下，实体化视图的log表都不大，因为oracle会在每次成功刷新了所有实体化视图后将历史记录删除。在这个不大的表上产生了很高的物理读显然并不正常。进一步了解oracle的复制机制，我们发现oracle对实体化视图log表的访问一律使用全表扫描(full table scan)，而每次全表扫描需要进行多少物理读，取决于每张表的高水位标志(high water mark)。简单的说，高水位标志（hwm）记录存储数据表记录的最高块的编号。高水位标志开始在新创建的表的第一个块上，随着数据不断放入表内，使用了更多的块，从而使高水位标志上升。如果删除表中的一些（甚至所有）行，有许多块可能已经不再包含数据，但是这些块仍然在高水位标志以下，并且保持在高水位标志以下直到对象被重建或重置。每当发生全表扫描时，oracle将读取该表hwm之下的所有数据块，即使这些块已经不包含数据。比如，如果把需占用100000个块的数据insert进某表，则该表的hwm被置为100000个块的位置。这时若用delete命令将该表数据全部删除，那该表的hwm并不变化，仍然保持在高位。即如果此时做select count(*)操作（需做全表扫描），那么需要的时间和未删除该表记录前所需的时间将基本相等。在oracle 10g以前，只有truncate操作才能重置一张表的hwm（从10g开始，oracle可以用alter table table_name shrink space来重置hwm）。了解了关于hwm的知识，我们基本可以得出结论，是mlog$表的hwm太高，导致了尽管该表记录数不多，但在做全表扫描时仍然产生了很高的物理读（mlog$表之所以会有很高的hwm,应该是因为某段时间内因为网络中断或其它原因导致数据同步失败，历史记录一直保存在mlog$表内，后来同步恢复，oracle自动将历史记录delete掉，但hwm并未降低）。因此，解决系统IO过高问题的关键是降低实体化视图相关的mlog$表的hwm。2.4 解决办法1. 可以使用如下语句估算一下MLOG$表是否存在高hwm：select segment_name, bytes/1024/1024 from user_segments where segment_name like MLOG$%如果查询出来的MLOG表占用的空间很大，那就说明此MLOG表存在HWM.2. 将各呼叫节点JOB时间延长到10个小时，并手动执行JOB一次。第一步，用彩铃用户登陆呼叫节点数据库，查找JOB号和刷新组名字。select job, rname from user_refresh where rowner=USDP JOB：job号 RNAME：刷新组名第二步，修改job刷新间隔时间为10个小时。SQL BEGIN DBMS_REFRESH.CHANGE( name = G88, -第一步中查询的刷新组名 next_date = SYSDATE,interval = sysdate + 36000/86400);END;第三步，手动执行呼叫节点job。SQL exec dbms_job.run(81); -第一步中查询的JOB号SQL commit;【注意】：在各个呼叫节点数据库上都必须执行上述1，2，3步骤，注意每个呼叫节点的作业号和刷新组名可能不同，请根据实际查找替换。3. 清理MLOG表高水位以mlog$_t_looptone表为例，其他表参照清理即可。高水位清除操作需要用两个session连接管理节点数据库，配合操作才可以完成清除工作。第一步，在第一个session中操作，对t_looptone表加排它锁，防止其它人更新该表(相应的mlog$表也就不会再有变化)。-session 1SQL LOCK TABLE T_LOOPTONE IN EXCLUSIVE MODE;第二步，在第二个session中操作，将MLOG$_T_LOOPTONE表的记录复制到临时表TEMP_MLOG_T_LOOPTONE中。-session 2SQLCREATE TABLE TEMP_MLOG_T_LOOPTONE AS SELECT * FROM MLOG$_T_LOOPTONE;第三步，在第二个session中操作，用truncate清空MLOG$_T_LOOPTONE表，降低该表的hwm-session 2SQL TRUNCATE TABLE MLOG$_T_LOOPTONE;第四步，在第二个session中操作，将临时表的记录重新插回MLOG$_T_LOOPTONE表，然后drop掉临时表TEMP_MLOG_T_LOOPTONE。-session 2SQL INSERT INTO MLOG$_T_LOOPTONE SELECT * FROM TEMP_MLOG_T_LOOPTONE;SQL DROP TABLE TEMP_MLOG_T_LOOPTONE;SQL COMMIT;第五步，在第一个session中操作，执行rollback，释放T_LOOPTONE表的排它锁。-session 1SQL ROLLBACK; 注意：由于牵涉到人为锁表，以上操作动作要快，并建议在业务量小时操作。4. 恢复各呼叫节点的同步JOB间隔执行时间，并手工执行一次JOB。5. 现场做了以上操作后，mlog$表的hwm被置位，效果明显，系统IO使用大幅度降低，磁盘IO繁忙率恢复正常。第3章 数据库存在阻塞锁导致同步JOB不能执行3.1 问题描述某省移动彩铃数据库的一个呼叫节点发现数据同步异常，导致该地当天新开户用户无法听到定制铃音，并引起部分用户投诉。3.2 分析过程为恢复同步，远程指导现场工程师对数据库执行手工同步：SQL exec dbms_job.run(81); -需要修改为现网同步job的JOB号 发现，执行上面语句后马上返回，但数据却没有成功同步。因为执行手工刷新数据同步不成功，初步怀疑可能是相关对象被锁导致同步失败,于是检查数据库的锁情况：SQLselect session_id,object_name from v$locked_object a,dba_objects b where a.object_id=b.object_id；结果返回如下：SESSION_ID OBJECT_NAME- - 23 JOB$ 34 SUMPARTLOG$ 34 T_USERINFO 34 T_CUSTOMIZE 34 SNAP_REFTIME$ 34 SNAP$ 查看系统存在哪些锁类型以及被阻塞的session： Select SID,TYPE,LMODE,REQUEST,BLOCK from v$lock where REQUEST0 or BLOCK0 查询结果如下：SIDTYPELMODEREQUESTBLOCK32JI06034JI601 SID: 会话（SESSION）标识; TYPE: 区分该锁保护对象的类型; LMODE: 锁模式 0（None），1（null）,2（row share）, 3（row exclusive）,4 （share）,5（share row exclusive）,6（exclusive） REQUEST: 申请的锁模式：具体值同上面的LMODE BLOCK: 是否阻塞其它锁申请从查询结果得知，SID为34的会话阻塞了SID为32的会话，需要先kill 掉SID为34的会话。3.3 解决办法1、 修改数据库参数job_queue_processes为0，防止同步job被自动运行。SQL alter system set job_queue_processes=0 scope=both; 2、 查询SID为34会话的相关信息：SQL select t.SID,t.SERIAL# from v$session t where t.SID=34t.SID t.SERIAL# 34 15273、 Kill 掉SID为34会话：SQL alter system kill session 34,15274、 手工运行数据库同步JOBSQL exec dbms_job.run(81); -需要修改为现网同步job的JOB号 注：如果需要同步的数据量很大，有可能执行同步job需要很长时间或执行不成功，此种场景将在其他案例中描叙。5、 如果此时数据库同步正常，则恢复数据库参数job_queue_processes为10。SQL alter system set job_queue_processes=10 scope=both;6、 观察数据库同步是否正常，并检查管理节点MLOG$表是否存在高水位现象。第4章 管理节点MLOG$表中数据不能自动删除4.1 问题描述某局点反馈彩铃管理节点数据库物化视图日志MLOG$表中的记录不能自动删除，表中数据越来越多，造成系统性能下降，磁盘IO升高。4.2 分析过程物化视图日志MLOG$表中的记录不能自动删除，存在三种情况：1、 创建数据库同步环境时，管理节点上的临时用户没有DROP掉。2、 同步环境中存在呼叫节点数据库同步不正常。3、 管理节点数据库中存在多余的实体化视图的注册信息。4.3 原因分析Oracle通过实体化视图（metarilized view）在主从数据库间做数据同步，一个主节点的数据，同步到一个或多个从节点数据库。主从节点实体化视图的刷新机制采用快速刷新（fast refresh），而实体化视图的快速刷新要求实体化视图对应的主表必须建立实体化视图log表（metarilized view log table）。如：欲对t_userinfo表建立实体化视图，就必须先建立t_userinfo表的实体化视图log表（会自动命名为mlog$_t_userinfo）。当从节点的实体化视图被异常删除时（即不是使用drop materialized view命令去drop），比如数据库被重建导致该实体化视图被drop，则该实体化视图的信息仍然会保留在主节点数据库的数据字典里。这将导致主节点数据库的实体化视图log表无限增长，引发数据库一系列性能及稳定性的问题。4.4 解决办法1、 检查管理节点数据库中是否还存在创建同步时的临时用户SQL select username from dba_users如存在此用户，则必须DROP掉；SQL DROP USER * CASCADE;2、 检查是否存在同步不成功的节点：可以采用修改管理节点数据库中某同步表中数据后，然后等待设定的同步时间后在每个呼叫节点上检查数据修改是否已同步；或在每个呼叫节点上反复几次（至少要间隔设定的同步时间）执行如下语句，检查last_refresh_date（表示上一次同步刷新时间）字段是否会全部正常变化。SQLselect mview_name,last_refresh_date from user_mviews3、 检查管理节点是否存在多余的实体化视图的注册信息：使用DBA用户登陆管理数据库, 反复几次执行如下语句（时间间隔大于设定的数据库同步时间间隔）SQLselect snapid,snaptime from slog$;如果某个（或某几个）snaptime始终不发生变化，则可以确认这个snaptime相对应的snapid就是多余的实体化视图id。根据上一步查到的snapid，执行如下语句手工删除掉该snapid对应的数据字典信息：SQLexec dbms_snapshot.purge_snapshot_from_log(snapid); -上面查到的snapidSQLcommit;第5章 呼叫节点唯一性索引冲突引起数据库同步中断5.1 问题描述某局点某日反馈数据库同步中断，查看数据库alert日志，发现同步时报如下错误“ORACLE报错信息为“ORA-00001: unique constraint (XXX) violated ”。5.2 分析过程由于呼叫节点的物化视图上存在唯一索引，可能引起在增量刷新时引发“唯一性冲突”，导致呼叫节点同步JOB执行失败。5.3 原因分析在增量刷新期间，ORACLE会将自上次刷新以来主节点的所有改变都放到一个大事务里，然后应用到同步节点上，但是这个大事务里DML操作的执行顺序不一定和在主节点上应用的顺序相一致。比如，主节点表T的A字段有两个值1和2，且A字段有唯一索引。先在主节点上将2改为3，再将1改为2，但是快速刷新时，在同步节点上可能是先将1改为2，再将2改为3，这样在同步节点上就发生了唯一性的冲突，ORACLE报错信息为“ORA-00001: unique constraint (XXX) violated“。5.4 解决办法1、 找出呼叫节点数据库中可能引起唯一性冲突的索引(主键也是唯一性索引，但主键不包含在内)，使用彩铃数据库用户名执行如下语句：SQL select A.index_name,A.table_name from user_indexes a where a.uniqueness=UNIQUE and a.index_name not in (select b.index_name from user_constraints b where b.constraint_type=P ) 如果上面语句查询有结果，表示当前数据库存在引起唯一性冲突的隐患。2、 将呼叫节点的唯一索引（主键除外）删除，改为建立普通索引即可：以下以表T_TONEBOXLOOP_mv的IX_TONEBOXLOOP_ID索引为例： 在呼叫节点上执行：SQLdrop index ix_toneboxloop_id;SQLcreate index ix_toneboxloop_id on t_toneboxloop_mv ( toneboxloopid ASC ) tablespace ringidx;3、 对于需要新建数据库同步的呼叫节点，请使用本文案例一中提供的脚本来生成建索引脚本。 第6章 Revoke彩铃数据库用户DBA权限后同步中断6.1 问题描述某局点开局时，彩铃呼叫节点业务数据库RING用户赋予了DBA的role，某日维护人员为了保持系统安全性，现场通过revoke DBA from ring语句删除ring用户的DBA角色，操作完后，发现数据库同步JOB执行失败。6.2 分析过程登录到此呼叫节点数据库上查看ALERT日志，发现日志中有如下报错：ORA-12012: error on auto execute of job 24ORA-12008: error in materialized view refresh pathORA-01536: space quota exceeded for tablespace RINGORA-06512: at SYS.DBMS_SNAPSHOT, line 803ORA-06512: at SYS.DBMS_SNAPSHOT, line 860ORA-06512: at SYS.DBMS_IREFRESH, line 683ORA-06512: at SYS.DBMS_REFRESH, line 195通过报错信息得知，是由于RING用户没有权限扩展表空间RING导致。通过对比此数据库RING用户和其他正常数据库RING用户的权限，发现有问题点RING用户发现少“dba”和“unlimited tablespace”两个权限，于是为了尽快恢复业务，执行了：grant unlimited tablespace to USDP;grant dba to USDP;之后同步恢复。6.3 原因分析在oracle数据库中，revoke某用户dba或resource角色的时候，oracle自动会把此用户的UNLIMITED TABLESPACE权限回收。如果数据库用户对某tablespace没有UNLIMITED TABLESPACE权限，当此用户下的table对象申请新的空间时就会失败，报错信息为“ORA-01536: space quota exceeded for tablespace *“。6.4 解决办法1、首先检查ring用户是否具备DBA角色：运行如下SQL语句可以查询： select * from dba_role_privs t where t.grantee=RING 查询结果如图： 2、如果ring用户具有DBA角色，删除DBA角色方法：使用具有DBA权限的用户登陆数据库，运行下面语句：SQL revoke dba from ring;SQL grant resource to ring;注：revoke dba角色后，必须重新grant resource给数据库用户第7章 节点同步或单表同步时ORA-12034错误处理7.1 问题描述某局点彩铃数据库，在新增数据库快照节点同步主数据库的时候报错，oracle错误码为ORA-12034，导致同步不成功7.2 分析过程数据库同步错误信息如下：ERRORatline1:ORA-12034:materializedviewlogonRBTDB0.T_USERINFOyoungerthanlast refresh ORA-06512:atSYS.DBMS_SNAPSHOT,line803ORA-06512:atSYS.DBMS_SNAPSHOT,line860ORA-06512:atSYS.DBMS_SNAPSHOT,line841ORA-06512:atline27.3 原因分析从错误日志提示中分析，mvlog已被其他节点刷新后删除，该节点无法做fastrefresh，只能先把其他节点的同步JOB停止或同步时间间隔改为足够长后，重新做该节点的同步。7.4 解决办法新增快照节点前，需要将已有的快照节点的同步JOB停止或同步间隔时间改为足够长，在新增快照完成后，并确认远程节点的数据已经同步过去后，再修改已有快照节点的数据库的同步时间间隔。同步方法请参考彩铃Oracle9i数据库同步安装指导书UNIX-UNIX。第8章 呼叫节点同步job 下一次执行时间为4000年问题8.1 问题描述某局点数据库同步中断，查看同步JOB的属性，发现Next date变成了4000-01-01。8.2 原因分析由于网络或是其他原因造成呼叫节点数据库连接不上管理数据库时，会造成同步JOB执行失败，当同步JOB执行失败次数达到16次时，oracle数据库会将同步完全停止，并将下次同步时间（Next date）修改为4000年。即使后来网络恢复，呼叫节点数据库连上了管理数据库，但是由于下次同步时间变为4000年，数据库同步依然不能正常进行。此时就需要手动修改下次同步时间并刷新同步作业保证同步正常进行。8.3 解决办法方法1：打开oracle网管工具OracleEnterpriseManager。用system/oracle帐号登陆发现问题的订阅数据库。选择“分布”“高级复制”“实体化视图复制”“实体化视图站点”“刷新组”“RING.G88”，手工修改“下一日期”为当前时间，然后点击“立即刷新”按钮。如状态由“失败”变为“正常”，则同步刷新成功。方法2： 运行如下语句SQLselectjobfromuser_jobswherebroken=Y;找出对应的job号后(如20)，用以下命令将其的broken改为N：SQLexecdbms_job.broken(20,false);SQLcommit;然后手工执行该job:SQLexecdbms_job.run(20);第9章 彩铃数据库exp/imp操作导致数据库同步异常9.1 问题描述某局点要进行业务版本升级，现场想搭建测试环境进行业务模拟测试，因此在主节点数据库新建一用户，然后用exp工具将主节点数据库彩铃ring用户的数据导出，再用imp工具将数据导入到新建用户内。Exp/imp操作结束后，发现数据库同步异常：数据库的同步任务显示正常，oracle的日志里也没有任何告警信息，但实际数据库同步失效，主节点实体化视图log表内没有任何记录。9.2 原因分析彩铃数据库用oracle的实体化视图做数据同步，为实现实体化视图的快速刷新，必须建立实体化视图的log表，实体化视图所对应主表的所有变化都会记录到log表里。此次发现数据同步异常时，无论主表如何变化(如t_userinfo)，它对应的log表(mlog$_t_userinfo)的记录数始终为零。通过咨询oracle公司，确认这是一个oracle未公开的bug.(2576724):当在主节点数据库的不同用户间做exp/imp操作时，即将同步表的log表所在的用户数据导出(exp),再导入(imp)到主节点数据库的另一个用户下时，将会导致被同步的主表的内部触发器被误删除，从而使同步中断。执行如下语句操作：$sqlplus/nologSQLconn/assysdbaSQLselect*fromdba_internal_triggerswheretable_name=T_USERINFOandOwner_name=RING;这个查询将返回0行，这说明t_userinfo表的内部触发器确实被删除了，该触发器被删除，将导致数据同步中断，但不会有任何告警或异常信息产生。9.3 解决办法1、如果被同步的表数据量较小（小于100000条记录），可以用以下方法处理：以T_USERINFO表为例，在主节点执行：$sqlplus/nologSQLconn/assysdbaSQLexecdbms_snapshot_utl.sync_up_log(ring,T_USERINFO);（以上操作可以恢复被删除的内部触发器）,然后在从节点执行一次完全刷新。SQLexecdbms_mview.refresh(T_USERINFO_MV,C);如果被同步的表数据量较大（大于100000条记录），执行重做数据库同步；（具体方法见彩铃数据同步指导书）。第10章 MV LOG缺失导致同步节点redo log切换频繁10.1 问题描述某地中发现同步节点的oracle数据库redo log切换频繁，WIO也特别高，从现场返回的alert log来看，基本上每12分钟切换一次。正常情况下，在系统忙时，应该是1530分钟切换一次。现场检查redo log file的个数和大小，反馈信息为3个，每个300M，符合安装指导书的要求。其他较大据点的切换时间一般不会少于15分钟。因此，可以断定redo log切换频繁不是由于文件太小造成的。10.2 分析过程现场做statspack检查结果:Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value- - - - - 471,505,525 8 58,938,190.6 99.6 2343.67 4140.85 3057692676DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate;broken BOOLEAN := FALSE; BEGIN dbms_refresh.refresh(RING.G80); :mydate := next_date; IF broken THEN :b := 1; ELSE :b := 0;END IF; END;411,739,098 7 58,819,871.1 87.0 1750.54 3123.05 255338816I