Oracle Life

May 22, 2012

性能优化-Oracle RAC中的Sequence Cache问题

在RAC环境中，序列的Cache问题可能会对性能有着决定性的影响，缺省的序列Cache值为20，这对RAC环境远远不够。
如果存在序列号使用的竞争，就可能在数据库中看到明显的队列等待：
enq: SQ - contention

在RAC情况下，可以将使用频繁的序列Cache值增加到10000，或者更高到50000，这些值在客户的环境中都有采用。
这是RAC设置和RAC使用的基本常识，不可或忘。

在以下测试中，可以显示Cache序列对于性能的影响：
http://space.itpub.net/14941137/viewspace-629941

摘要如下：
RAC两个会话分别处于不同node同时并发循环间断去取4万个值：

nocache：　　 2100s
cache ＝1000：　　 55s

差别却是好大。

单Instance数据库单会话循环不间断去1-4万个值测试（在家里笔记本上测试结果）过程如下：

nocache：             37.7s          10000　　　
cache ：20            4.31s          10000
cache ：100       2.92s           10000
cache ：1000      5.56s          40000
nocache：             97.7s         40000

基本上cache 大于20的时候性能基本可以接受，最好设置100以上，
nocache的时候性能确实很差，最大相差20倍．

排序参数：oracle默认是NOORDER，如果设置为ORDER；在单实例环境没有影响，在RAC环境此时，多实例实际缓存相同的序列，此时在多个实例并发取该序列的时候，会有短暂的资源竞争来在多实例之间进行同步。因次性能相比noorder要差，所以RAC环境非必须的情况下不要使用ORDER，尤其要避免NOCACHE ORDER组合；

在某些版本中存在BUG，会导致过度的 enq : SQ 竞争。
如在Oracle Database 11g中存在 IDGEN$ 序列 cache 设置过小问题，可能导致严重竞争，建议增加该序列的Cache值设置。

Posted by eygle at 8:10 AM | Permalink | Comments (0) | FAQ (235)

May 21, 2012

ORA-00600 kclchkblk_4 错误恢复案例一则

最近客户在恢复数据库时遇到了ORA-600 kclchkblk_4错误，这个错误在MOS上有官方的解释和解决方案。

在以下错误提示下：

Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_smon_7493.trc:
ORA-600: internal error code, arguments: [kclchkblk_4], [1904],[18446744073431179384], [1904],18446744073403569507], [], [], []

Starting background process QMNC
QMNC started with pid=24, OS id=8329

Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_smon_7493.trc:
ORA-600: internal error code, arguments: [2662], [1904], [3988985522],[1904], [4016595064], [8388610], [], []

Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_smon_7493.trc:
ORA-600: internal error code, arguments: [2662], [1904], [3988985525],[1904], [4016595064], [8388610], [], []
SMON: terminating instance due to error 474
Instance terminated by SMON, pid = 7493

其问题，可能是由于临时表空间的SCN问题导致的，可以尝试删除所有的临时文件，启动数据库，通常可能正常启动。
可能的采取步骤是，在Mount状态下确定并删除临时文件：

    SQL>select file_name, file_id from dba_temp_files;
    SQL>alter database tempfile_name drop;
    SQL>alter tablespace add tempfile size N;

如果数据库能够成功启动，可以重建临时文件。

顺便引用一下ITPUB上一个朋友的帖子供参考： http://www.itpub.net/thread-1404451-1-1.html

问题描述：
服务器突然故障死机，导致数据库无法驱动，redo的CURRENT组的损坏。oracle 10g rac环境，asm磁盘组，redhat linux系统。每个组一个成员这个是组被破坏无法修复的关键。
没有归档，没有备份。使用ASM无法将数据文件冷备份出来。

ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 254606 change 12131176305969 time 03/08/2011 01:03:00
ORA-00312: online log 2 thread 1: '+DG1/police/onlinelog/group_2.258.657430669'

查看日志组文件信息，报错的日志组为CURRENT模式。

SQL> select group#,sequence#,archived,status from v$log;

GROUP#  SEQUENCE# ARC STATUS
---------- ---------- --- ----------------
      1    17495 NO  INACTIVE
      2    17496 NO  CURRENT
      3    17365 NO  INACTIVE
      4    17366 NO  CURRENT

组成员只有一个。

SQL>

   Group Instance          Member          STATUS          Size(MB)
---------- ---------- ------------------------------ ---------------- ----------
      1       1 +DG1/police/onlinelog/group_1. INACTIVE             500
                  257.657430665

      2       1 +DG1/police/onlinelog/group_2. CURRENT                500
                  258.657430669

      3       2 +DG1/police/onlinelog/group_3. INACTIVE             500
                  265.657431819

      4       2 +DG1/police/onlinelog/group_4. CURRENT                500
                  266.657431825

无法使用clear命令清楚redo的信息

SQL> alter database clear unarchived logfile group 2
2 ;
alter database clear unarchived logfile group 2
*
ERROR at line 1:
ORA-01624: log 2 needed for crash recovery of instance police1 (thread 1)
ORA-00312: online log 2 thread 1: '+DG1/police/onlinelog/group_2.258.657430669'

SQL> alter database clear logfile group 2;
alter database clear logfile group 2
*
ERROR at line 1:
ORA-01624: log 2 needed for crash recovery of instance police1 (thread 1)
ORA-00312: online log 2 thread 1: '+DG1/police/onlinelog/group_2.258.657430669'

处理步骤

把数据库down掉

SQL>shutdown immediate

5、在init<sid>.ora中加入如下参数

_allow_resetlogs_corruption=TRUE

6、重新启动数据库,利用until cancel恢复

SQL>recover database until cancel;
Cancel

如果出错，不再理会，发出

SQL>alter database open resetlogs;

如果运气好的话可以正常启动数据库，就可以导出数据了。但是这里有点意外不知道是点背还是rac环境的恢复比较特殊。在alert.log中有如下报错：

Errors in file /u01/app/oracle/admin/police/bdump/police2_j003_17720.trc:
ORA-00600: internal error code, arguments: [4194], [9], [8], [], [], [], [], []
Wed Mar  9 18:08:06 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_j004_17722.trc:
ORA-00600: internal error code, arguments: [4193], [55749], [55753], [], [], [], [], []
Wed Mar  9 18:08:08 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_mmon_11328.trc:
ORA-00600: internal error code, arguments: [4194], [12], [17], [], [], [], [], []
Wed Mar  9 18:08:08 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_j002_17718.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

能后我就重复启动数据库这个错误就过去了，网上有一篇文档是这么说的，真的可以过去，不过我是将两个节点都同时启动的时候过去的，但是在开始出现如下错误：
ORA-600[KCLCHKBLK_4]【2824】，但是没有出现ORA-600[2662]的报错，不知道为什么，有人说是temp文件不一致造成，但是别人都有2662的报错我这里没有，不管了先将temp删了在说。

能后速度将temp删除，能后发现问题依旧。当时我就很失望了，情绪低落。这个报错在网上的解决办法只有这一个。也没有什么人有更好的建议。
ORA-00600: internal error code, arguments: [kclchkblk_4], [2824], [18446744071603238605], [2824], [18446744071593491338], [], [], []
Wed Mar 9 14:29:55 2011
Errors in file /u01/app/oracle/admin/police/udump/police1_ora_27660.trc:
ORA-00600: internal error code, arguments: [kclchkblk_4], [2824], [18446744071603238605], [2824], [18446744071593491338], [], [], []
Wed Mar 9 14:29:55 2011
Error 600 happened during db open, shutting down database
USER: terminating instance due to error 600

但是仔细观察后我发现18446744071593491338这个数据有问题，它在我每次重新启动数据库的时候会和前面的数值有所改变18446744071593491338，我的目标就是将
这个数值尽量的缩小和18446744071603238605的值，重复几遍后发现使用srvctl start database -d sid数据库会自动重启多次，我就不停地启动关闭。有希望了两个者还是相差太大，
这一步我们在这里卡了很久。这里有一个scn的问题，我这里碰到的是后面的比前面的低，所以adjust_scn没有效果。
无赖我将_allow_resetlogs_corruption=TRUE增加到spfile中让数据库同时启动。结果发现错误改变了，后来想想估计是要将参数添加到spfile中同时启动数据库才有效果，因为我单独启动数据库的时候效果不大。

Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Wed Mar  9 18:08:35 2011
ORACLE Instance police2 (pid = 16) - Error 600 encountered while recovering transaction (9, 46).
Wed Mar  9 18:08:35 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Wed Mar  9 18:08:35 2011
Trace dumping is performing id=[cdmp_20110309180835]
Wed Mar  9 18:08:37 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Errors in file /u01/app/oracle/admin/police/bdump/police2_p007_19333.trc:
ORA-00600: internal error code, arguments: [4198], [9], [], [], [], [], [], []

出现了这些报错，现在好了，4137,4138 ，4139不都是undo的报错吧，
新建立两个undo，修改spfile使用新的undo启动，删除旧的undo。
添加spfile参数

_allow_resetlogs_corruption"=true "
_allow_terminal_recovery_corruption"=true
_corrupted_rollback_segments ='_SYSSMU1$','_SYSSMU2$','_SYSSMU3$'

如果不能确定多少个，但是我在删除UNDO的时候提示_SYSSMU2无法删除，我还是坚持加到了20个，后来我查了一下一共有400多个还好没有每个都坏掉。
修改undo_management 这个参数
把参数文件中的undo_management 改为MANUAL

SQL> create undo tablespace undotbs3 datafile '/opt/oracle/oradata/conner/undotbs3.dbf' size 10M;
Tablespace created.
SQL> alter system set undo_tablespace=undotbs1 scope=spfile sid='sid';
System altered.
SQL> drop tablespace undotbs2;
Tablespace dropped.

将两个节点的undo都替换后发现数据库可以起来了，但还是有报错，

Errors in file /u01/app/oracle/admin/police/bdump/police2_j000_7977.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []
Wed Mar 9 23:56:10 2011

但还好可以exp数据了。

导出数据后，删除数据库，删除asm，
关闭第二台的asm实例，
登入第一台asm

SQL> select name from v$asm_diskgroup;
NAME
------------------------------
DG1
SQL> drop diskgroup DG1 including contents; -->删除磁盘组
SQL>SHUTDOWN IMMEDIATE

最后
crs_unregister ora.node1.ASM1.asm
crs_unregister ora.node1.ASM1.asm(后来极度后悔，应该在unregister前备份一下就好了）
在dbs和admin下删除asm相关文档
修改/etc/oratab文件将asm的注释。
dbca重新建立asm磁盘发现asm实例无法启动晕倒。好像是出现prks-1011，和ora-0210的报错
使用srvctl add asm -n node1 -i +ASM1 -o $ORACLE_HOME -p init+ASM1.ora
提示ora.node1.ASM1.asm服务已经存在了，但是crs_stat -t查看又没有ora.node1.ASM1.asm服务。
于是我使用crs_register ora.node1.ASM1.asm的时候提示找不到 ora.node1.ASM1.asm.cap的文件（这里折腾了一段时间）
没法我从别的rac上使用crs_stat -p ora.node1.ASM1.asm > ora.node1.ASM1.asm.cap导出了一份拷贝到提示的目录下，并且修改了文件中的主机信息等。
在使用crs_register ora.node1.ASM1.asm就注册成功了。其实 ora.node1.ASM1.asm.cap这个文件的东西和 ora.node1.lsnr的文件内容一样。就是有些东西自己动手修改一下就可以替代了。
重新建库导入文件
艰苦的数据恢复终于完成了。

Posted by eygle at 1:04 PM | Permalink | Comments (0) | Backup&Recovery (129)

May 17, 2012

Oracle安全 - SCN的可能最大值与耗尽问题

在2012年第一季度的CPU补丁中，包含了一个关于SCN修正的重要变更，这个补丁提示，在异常情况下，Oracle的SCN可能出现异常增长，使得数据库的一切事务停止，由于SCN不能后退，所以数据库必须重建，才能够重用。

我曾经在以下链接中描述过这个问题：
http://www.eygle.com/archives/2012/03/oracle_scn_bug_exhaused.html

Oracle使用6 Bytes记录SCN，也就是48位，其最大值是：

SQL> col scn for 999,999,999,999,999,999
SQL> select power(2,48) scn from dual;

SCN
------------------------
281,474,976,710,656

Oracle在内部控制每秒增减的SCN不超过 16K，按照这样计算，这个数值可以使用大约544年：

SQL> select power(2,48) / 16 / 1024 / 3600 / 24 / 365 from dual;

POWER(2,48)/16/1024/3600/24/365
-------------------------------
544.770078

然而在出现异常时，尤其是当使用DB Link跨数据库查询时，SCN会被同步，在以下链接中，我曾经描述过此问题：
http://www.eygle.com/archives/2006/11/db_link_checkpoint_scn.html

一个数据库当前最大的可能SCN被称为"最大合理SCN"，该值可以通过如下方式计算：

col scn for 999,999,999,999,999,999
select
(
    (
        (
            (
                (
                    (
                        to_char(sysdate,'YYYY')-1988
                    )*12+
                to_char(sysdate,'mm')-1
                )*31+to_char(sysdate,'dd')-1
            )*24+to_char(sysdate,'hh24')
        )*60+to_char(sysdate,'mi')
    )*60+to_char(sysdate,'ss')
) * to_number('ffff','XXXXXXXX')/4 scn
from dual
/

这个算法即SCN算法，以1988年1月1日 00点00时00分开始，每秒计算1个点数，最大SCN为16K。
这个内容可以参考如下链接：
http://www.eygle.com/archives/2006/01/how_big_scn_can_be.html

在CPU补丁中，Oracle提供了一个脚本 scnhealthcheck.sql 用于检查数据库当前SCN的剩余情况。
该脚本的算法和以上描述相同，最终将最大合理SCN 减去当前数据库SCN，计算得出一个指标：HeadRoom。也就是SCN尚余的顶部空间，这个顶部空间最后折合成天数：
以下是这个脚本的内容：

Rem
Rem $Header: rdbms/admin/scnhealthcheck.sql st_server_tbhukya_bug-13498243/8 2012/01/17 03:37:18 tbhukya Exp $
Rem
Rem scnhealthcheck.sql
Rem
Rem Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved.
Rem
Rem    NAME
Rem      scnhealthcheck.sql - Scn Health check
Rem
Rem    DESCRIPTION
Rem      Checks scn health of a DB
Rem
Rem    NOTES
Rem      .
Rem
Rem    MODIFIED   (MM/DD/YY)
Rem    tbhukya     01/11/12 - Created
Rem
Rem

define LOWTHRESHOLD=10
define MIDTHRESHOLD=62
define VERBOSE=FALSE

set veri off;
set feedback off;

set serverout on
DECLARE
verbose boolean:=&&VERBOSE;
BEGIN
For C in (
select
   version,
   date_time,
   dbms_flashback.get_system_change_number current_scn,
   indicator
from
(
   select
   version,
   to_char(SYSDATE,'YYYY/MM/DD HH24:MI:SS') DATE_TIME,
   ((((
    ((to_number(to_char(sysdate,'YYYY'))-1988)*12*31*24*60*60) +
    ((to_number(to_char(sysdate,'MM'))-1)*31*24*60*60) +
    (((to_number(to_char(sysdate,'DD'))-1))*24*60*60) +
    (to_number(to_char(sysdate,'HH24'))*60*60) +
    (to_number(to_char(sysdate,'MI'))*60) +
    (to_number(to_char(sysdate,'SS')))
    ) * (16*1024)) - dbms_flashback.get_system_change_number)
   / (16*1024*60*60*24)
   ) indicator
   from v$instance
)
) LOOP
dbms_output.put_line( '-----------------------------------------------------'
                        || '---------' );
dbms_output.put_line( 'ScnHealthCheck' );
dbms_output.put_line( '-----------------------------------------------------'
                        || '---------' );
dbms_output.put_line( 'Current Date: '||C.date_time );
dbms_output.put_line( 'Current SCN: '||C.current_scn );
if (verbose) then
    dbms_output.put_line( 'SCN Headroom: '||round(C.indicator,2) );
end if;
dbms_output.put_line( 'Version:      '||C.version );
dbms_output.put_line( '-----------------------------------------------------'
                        || '---------' );

IF C.version > '10.2.0.5.0' and
     C.version NOT LIKE '9.2%' THEN
    IF C.indicator>&MIDTHRESHOLD THEN
      dbms_output.put_line('Result: A - SCN Headroom is good');
      dbms_output.put_line('Apply the latest recommended patches');
      dbms_output.put_line('based on your maintenance schedule');
      IF (C.version < '11.2.0.2') THEN
        dbms_output.put_line('AND set _external_scn_rejection_threshold_hours='
                             || '24 after apply.');
      END IF;
    ELSIF C.indicator<=&LOWTHRESHOLD THEN
      dbms_output.put_line('Result: C - SCN Headroom is low');
      dbms_output.put_line('If you have not already done so apply' );
      dbms_output.put_line('the latest recommended patches right now' );
      IF (C.version < '11.2.0.2') THEN
        dbms_output.put_line('set _external_scn_rejection_threshold_hours=24 '
                             || 'after apply');
      END IF;
      dbms_output.put_line('AND contact Oracle support immediately.' );
    ELSE
      dbms_output.put_line('Result: B - SCN Headroom is low');
      dbms_output.put_line('If you have not already done so apply' );
      dbms_output.put_line('the latest recommended patches right now');
      IF (C.version < '11.2.0.2') THEN
        dbms_output.put_line('AND set _external_scn_rejection_threshold_hours='
                             ||'24 after apply.');
      END IF;
    END IF;
ELSE
    IF C.indicator<=&MIDTHRESHOLD THEN
      dbms_output.put_line('Result: C - SCN Headroom is low');
      dbms_output.put_line('If you have not already done so apply' );
      dbms_output.put_line('the latest recommended patches right now' );
      IF (C.version >= '10.1.0.5.0' and
          C.version <= '10.2.0.5.0' and
          C.version NOT LIKE '9.2%') THEN
        dbms_output.put_line(', set _external_scn_rejection_threshold_hours=24'
                             || ' after apply');
      END IF;
      dbms_output.put_line('AND contact Oracle support immediately.' );
    ELSE
      dbms_output.put_line('Result: A - SCN Headroom is good');
      dbms_output.put_line('Apply the latest recommended patches');
      dbms_output.put_line('based on your maintenance schedule ');
      IF (C.version >= '10.1.0.5.0' and
          C.version <= '10.2.0.5.0' and
          C.version NOT LIKE '9.2%') THEN
       dbms_output.put_line('AND set _external_scn_rejection_threshold_hours=24'
                             || ' after apply.');
      END IF;
    END IF;
END IF;
dbms_output.put_line(
    'For further information review MOS document id 1393363.1');
dbms_output.put_line( '-----------------------------------------------------'
                        || '---------' );
END LOOP;
end;
/

在应用补丁之后，一个新的隐含参数 _external_scn_rejection_threshold_hours 引入，通常设置该参数为 24 小时：

_external_scn_rejection_threshold_hours=24

这个设置降低了SCN Headroom的顶部空间，以前缺省的设置容量至少为31天，降低为 24 小时，可以增大SCN允许增长的合理空间。

但是如果不加控制，SCN仍然可能会超过最大的合理范围，导致数据库问题。

这个问题的影响会极其严重，我们建议用户检验当前数据库的SCN使用情况，以下是检查脚本的输出范例：

--------------------------------------
ScnHealthCheck
--------------------------------------
Current Date: 2012/01/15 14:17:49
Current SCN: 13194140054241
Version: 11.2.0.2.0
--------------------------------------
Result: C - SCN Headroom is low
If you have not already done so apply
the latest recommended patches right now
AND contact Oracle support immediately.
For further information review MOS document id 1393363.
--------------------------------------

这个问题已经出现在客户环境中，需要引起大家的足够重视。

Posted by eygle at 11:38 PM | Permalink | Comments (0) | Advanced (81) | Internal (119)

May 16, 2012

Oracle Exadata:上海银行 - Exadata的金融行业案例

根据上海银行发出的招标信息显示，上海银行已经确定选择Oracle的Exadata 进行系统建设，这是Oracle Exadata在金融行业的又一成功案例。

上海银行拟采购的2台Exadata一体机将用于"提高计算机辅助审计平台各方面的性能"，也就是说设备将用于进行金融审计平台，替换的硬件设备估计是IBM系统。

以下是部分招标信息显示：

上海银行股份有限公司采购中心拟采购2台Exadata一体机用于提高计算机辅助审计平台各方面的性能。现诚邀合格供应商参与本次供货代理商公开比选。相关事项公告如下。

一、项目概况：

1、项目编号：BOSCG-2012-JJ005

2. 项目名称: 上海银行计算机辅助审计项目

二、资格要求：
1、具有中华人民共和国境内独立法人资格的企业，相应的经营许可范围及工商行政管理部门核发的《企业法人营业执照》，且注册资本金不低于1000万元人民币；

2、需具有ORACLE公司的白金代理资格；

3、在上海地区拥有固定的经营场所并具有稳定的技术保障队伍，公司技术维护工程师应具备Exadata产品的服务认证资格。

从招标信息来看，客户已经选择了Exadata，招标不过是从多家供应商中寻找一个低价、服务保障良好的企业，从前提上看，Oracle已经成功。

从一体机市场来看，Oracle没有整体的强劲对手，只要最终用户能够从产品上获得良好的体验，以及优越的性价比，则Oracle的市场收获将是巨大的。

Posted by eygle at 10:17 PM | Permalink | Comments (0) | OraNews (204)

May 15, 2012

Oracle Exadata:巴黎银行 - Exadata的金融行业案例

根据2011年底的新闻消息，（北京，2011年12月27日）作为全球最顶尖的银行之一，法国巴黎银行通过采用Oracle Exadata数据库云服务器管理其电子交易平台数据，并取得显著成效。

Oracle Exadata数据库云服务器自2010年7月起便在法国巴黎银行发挥了重要作用，在不影响现有应用程序的情况下，其吞吐量轻松提升17倍。值得一提的是，法国巴黎银行于2010年5月才开始部署Oracle Exadata数据库云服务器。

· 电子交易平台数据规模主要基于行市巨幅波动而产生变化，而2011年对金融市场来说更是动荡的一年。法国巴黎银行的数据仓库以每天实时处理TB级原始数据的规模，管理着几十亿个交易信息。

· 通过采用一台半配的Oracle Exadata数据库云服务器，法国巴黎银行成功实现了数据增长的有效管理，并显著提高了应用系统性能。

· 法国巴黎银行通过Oracle Exadata数据库云服务器的Oracle混合列压缩功能，有效压缩了其活动数据规模，从而更加便捷的数据管理和更高效地存储使用。

· 作为法国巴黎银行企业及投资银行部门的高级商务智能和数据仓库架构师， Jim Duffy不久前在2011年旧金山甲骨文全球大会上，被授予欧洲、中东和非洲地区年度数据仓库领导者的荣誉。

· Jim Duffy与 Alex Afflerbach、Coumba Toure、Maxime Gontcharov共同组成商务智能和数据仓库集成的管理集成团队，负责法国巴黎银行全球股票及大宗商品衍生品部门（GECD）业务与世界电子市场之间的所有交易活动数据。

· 作为Oracle卓越奖下设的分类奖项之一，该年度数据仓库领导者奖项旨在奖励具有良好技术知识、创新使用Oracle数据仓库技术并实现其商业价值的优秀个人。

· 同时，甲骨文公司对来自亚太、欧洲、中东和非洲、拉丁美洲/加勒比海地区和北美的数据仓库领导者给予了高度认可并授予了相关奖项。

Posted by eygle at 10:45 PM | Permalink | Comments (0) | OraNews (204)