eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

September 10, 2019

AWR 报告解读:Time Model Statistics 信息的计算和获取

在 AWR 报告中,Time Model Statistics 记录了数据库用户维度(User Calls)的总时间消耗分布。

这部分信息来自:SYS.DBA_HIST_SYS_TIME_MODEL ,是通过针对前后两个采样点的差值计算得来的。

计算的SQL如下:

SQL> SELECT a.STAT_NAME,

2 ROUND((b.VALUE -a.VALUE)/1000000,2) "Time(s)"

3 FROM SYS.DBA_HIST_SYS_TIME_MODEL a,

4 SYS.DBA_HIST_SYS_TIME_MODEL b

5 WHERE a.snap_id = &start_snap_id

6 AND b.snap_id = &end_snap_id

7 AND a.STAT_NAME = b.STAT_NAME

8 AND ROUND((b.VALUE -a.VALUE)/1000000,2)>0

9 ORDER BY 2 DESC;

Enter value for start_snap_id: 34987

Enter value for end_snap_id: 34988

STAT_NAME Time(s)

---------------------------------------------------------------- ----------

background elapsed time 2720.51

background cpu time 2550.64

RMAN cpu time (backup/restore) 2518.73

DB time 53.21

DB CPU 48.83

sql execute elapsed time 33.66

connection management call elapsed time 10.67

parse time elapsed 2.26

PL/SQL execution elapsed time 1.01

inbound PL/SQL rpc elapsed time .96

hard parse elapsed time .7

hard parse (sharing criteria) elapsed time .68

PL/SQL compilation elapsed time .02

13 rows selected.

把这个结果和 AWR 报告中的相关部分对比,可以看到是完全吻合的(这个测试数据来自 11.2.0.4 版本)

TimeModelStatistics.jpg

这个SQL的语句如下,缺省的时间记录值是微秒,计算结果转换为秒显示:

SELECT a.STAT_NAME,

ROUND((b.VALUE -a.VALUE)/1000000,2) "Time(s)"

FROM SYS.DBA_HIST_SYS_TIME_MODEL a,

SYS.DBA_HIST_SYS_TIME_MODEL b

WHERE a.snap_id = &start_snap_id

AND b.snap_id = &end_snap_id

AND a.STAT_NAME = b.STAT_NAME

AND ROUND((b.VALUE -a.VALUE)/1000000,2)>0

ORDER BY 2 DESC;

了解 AWR 各部分的指标算法,非常有助于我们理解报告的真实表达。

Posted by eygle at 12:31 PM | Permalink | FAQ (261)

September 5, 2019

MySQL 基础:获取当前日期的时间函数 now 和sysdate

在 MySQL 中,获得系统当前时间可以使用 now() 函数,这是最简单和应用最广的函数。

除此之外,current_timestamp(),localtime(),localtimestamp() 都是 now() 函数的同义词,返回的结果相同:

mysql> select now();

+---------------------+

| now() |

+---------------------+

| 2019-09-05 12:28:16 |

+---------------------+

1 row in set (0.00 sec)

mysql> select current_timestamp(),localtime(),localtimestamp();

+---------------------+---------------------+---------------------+

| current_timestamp() | localtime() | localtimestamp() |

+---------------------+---------------------+---------------------+

| 2019-09-05 12:30:43 | 2019-09-05 12:30:43 | 2019-09-05 12:30:43 |

+---------------------+---------------------+---------------------+

1 row in set (0.00 sec)

配套的,实现同样效果的同义词还有 current_timestamp,localtime,localtimestamp :

mysql> select current_timestamp,localtime,localtimestamp;

+---------------------+---------------------+---------------------+

| current_timestamp | localtime | localtimestamp |

+---------------------+---------------------+---------------------+

| 2019-09-05 12:30:31 | 2019-09-05 12:30:31 | 2019-09-05 12:30:31 |

+---------------------+---------------------+---------------------+

1 row in set (0.00 sec)

now() 函数在一个 SQL 执行的过程中,取得的是执行开始的时间,并且在执行过程中保持不变,与之相对的则是 sysdate() 函数,sysdate 模拟 Oracle 数据库的实现,每次执行时,都调用时间函数获得时间,数值每次不同:

mysql> select now(),sysdate(),sleep(3),now(),sysdate() ;

+---------------------+---------------------+----------+---------------------+---------------------+

| now() | sysdate() | sleep(3) | now() | sysdate() |

+---------------------+---------------------+----------+---------------------+---------------------+

| 2019-09-05 13:34:47 | 2019-09-05 13:34:47 | 0 | 2019-09-05 13:34:47 | 2019-09-05 13:34:50 |

+---------------------+---------------------+----------+---------------------+---------------------+

1 row in set (3.00 sec)

在 MySQL的源码中,可以看到这行注释,item_func_sysdate_local 模拟了 Oracle 的行为,每次执行获取当前的真实时间 - Real current time,而不是 query_start() 的时间:

00516 /*
00517 This is like NOW(), but always uses the real current time, not the
00518 query_start(). This matches the Oracle behavior.
00519 */
00520 class Item_func_sysdate_local :public Item_func_now
00521 {
00522 public:
00523 Item_func_sysdate_local() :Item_func_now() {}
00524 Item_func_sysdate_local(Item *a) :Item_func_now(a) {}
00525 bool const_item() const { return 0; }
00526 const char *func_name() const { return "sysdate"; }
00527 void store_now_in_TIME(TIME *now_time);
00528 double val_real();
00529 longlong val_int();
00530 int save_in_field(Field *to, bool no_conversions);
00531 String *val_str(String *str);
00532 void fix_length_and_dec();
00533 bool get_date(TIME *res, uint fuzzy_date);
00534 void update_used_tables()
00535 {
00536 Item_func_now::update_used_tables();
00537 used_tables_cache|= RAND_TABLE_BIT;
00538 }
00539 };

除了 sysdate() ,之外,curdate() 和 curtime() 还能够直接将日期和时间拆分开来:

mysql> select curdate(),curtime();

+------------+-----------+

| curdate() | curtime() |

+------------+-----------+

| 2019-09-05 | 13:37:14 |

+------------+-----------+

1 row in set (0.00 sec)

最后,如果你觉得now()函数就够了,可以在MySQL启动时指定 -sysdate-is-now,sysdate()就会被当成now()的一个同义词,按照同样的行为工作了。

参考:
http://mysql.localhost.net.ar/sources/doxygen/mysql-5.1/item__timefunc_8h-source.html

Posted by eygle at 1:26 PM | Permalink | FAQ (261)

ORA-00600 15711 错误和 ogg goldengate 的集成故障

最近有朋友在 墨天轮 提出一个问题,数据库遇到了 ORA-600 15711 错误。

这个错误是比较少见的,MOS 上相关的BUG只有一个:

Bug 3212516 Select from GV$ views can fail with OERI[15711]

这个BUG是和 RAC 相关的,在查询 GV$ 视图时发生,这个BUG的描述是:

Parallel operations across nodes on GV$ views can fail with 
ORA-600 [15711] particularly if the other node/s are changing
state (up/down/up)

在跨节点查询 GV$ 视图使用并行操作时出现,通常这时候对方节点处于异常状态,例如正在启动或者关闭。

这个BUG对应的数据库版本是 9.2.0.7,在那之后,就再也没有确认的BUG了。

那么我们看看这个新提出来的问题,系统环境是 Oracle 11.2.0.3 的 AIX 平台 RAC 集群版本:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORACLE_HOME = /oracle/product/11gr2
System name: AIX

在跟踪文件的头部展示了错误发生的应用模块,这个错误是由于 OGG 进行数据抽取引起的:

*** MODULE NAME:(OGG-EXTJC1-OCI_META_THREAD) 2019-09-02 21:22:21.965
*** ACTION NAME:() 2019-09-02 21:22:21.965

而错误抛出的SQL同样是查询 GV$instance 视图:

----- Current SQL Statement for this session (sql_id=48k7nky3dkt0d) -----
SELECT TO_CHAR(startup_time, 'YYYY-MM-DD HH24:MI:SS') FROM gv$instance WHERE inst_id = 2

所以这个问题和Bug 3212516是同样的问题,说明错误发生在执行 GV$ 跨实例查询时,对方节点的状态存在问题,也可能是网络存在瞬时抖动,使得SQL出现错误。

Posted by eygle at 9:01 AM | Permalink | Case (163)

August 28, 2019

诊断案例:通过10046跟踪和解决12.2 多租户ORA-600 908错误

原文:https://www.modb.pro/db/6141

在 Oracle 数据库的世界里,通过10046事件跟踪解决未知问题,是 DBA 的重要技能之一。

掌握了Oracle数据库最为重要的跟踪方法,就可以在遇到问题时,快速定位根源。而找到问题根源,距离解决问题也就不远了----不论这些问题是已知的还是未知的。

以下一个案例来自于Oracle Database 12.2的版本,在数据库启动时遇到错误,数据库无法启动,抛出的异常是ORA-00600 908错误,关于这个错误在MOS上也没有说明(在撰文时未有任何已知资料),这属于最早发现的12.2的问题。

[oracle@enmocoredb ~]$ SQLplus / as sysdba

SQL*Plus: Release 12.2.0.0.3 Production on Mon Aug 1 09:59:54 2016

Copyright (c) 1982, 2016, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Database mounted.

ORA-00603: ORACLE server session terminated by fatal error

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00604: error occurred at recursive SQL level 1

ORA-00600: internal error code, arguments: [908], [], [], [], [], [], [], [], [], [], [], []

ORA-07445: exception encountered: core dump [ksupdbsesinc()+866] [SIGSEGV]

[ADDR:0x13650] [PC:0x6170C62] [Address not mapped to object] []

Process ID: 24446

Session ID: 30 Serial number: 42586

进一步的检查告警日志文件,获取后台记录的更详细信息,在这个案例中后台的异常日志和前台抛出的一致,包括跟踪日志,很难获得更明确的判断线索。

2016-08-01T10:02:56.913024+08:00

Errors in file /u01/app/oracle/diag/rdbms/eygle/eygle/trace/eygle_ora_24446.trc:

ORA-00604: error occurred at recursive SQL level 1

ORA-00600: internal error code, arguments: [908], [], [], [], [], [], [], [], [], [], [], []

ORA-07445: exception encountered: core dump [ksupdbsesinc()+866] [SIGSEGV] [ADDR:0x13650] [PC:0x6170C62] [Address not mapped to object] []

Error 604 happened during db open, shutting down database

为了进一步分析这个问题,我们在Open数据库的阶段启用跟踪,以寻找最后出现问题的步骤,这一方法在实践中非常有效。

SQL> startup mount;

ORACLE instance started.

Database mounted.

SQL> alter session set events '10046 trace name context forever,level 12';

Session altered.

SQL> alter database open;

ORA-00600: internal error code, arguments: [908], [], [], [], [], [], [], [],[], [], [], []

现在可以在后台找到这个跟踪文件,通过定位最后出现问题的部分,获得线索。以下一段输出是数据库启动报错前最后执行的一段递归SQL。

=====================

PARSING IN CURSOR #0x7f19251432d8 len=123 dep=1 uid=0 oct=3 lid=0 tim=2423484984490 hv=1601912009 ad='0x6181e130' SQLid='65m6cgpgrqg69'

select /*+ NO_PARALLEL(c) */ c.con_id# from cdb_service$ c where lower(c.name) = lower(:1) or lower(c.name) = lower(:2)

END OF STMT

PARSE #0x7f19251432d8:c=0,e=293,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=2423484984490

BINDS #0x7f19251432d8:

Bind#0

oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00

oacflg=18 fl2=0001 frm=01 csi=852 siz=32 off=0

kxsbbbfp=7f19266bdf70 bln=32 avl=04 flg=05

value="enmo"

Bind#1

oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00

oacflg=18 fl2=0001 frm=01 csi=852 siz=32 off=0

kxsbbbfp=7f19266bdf38 bln=32 avl=04 flg=05

value="enmo"

EXEC #0x7f19251432d8:c=1000,e=594,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=2885951592,tim=2423484985147

FETCH #0x7f19251432d8:c=0,e=24,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,plh=2885951592,tim=2423484985192

STAT #0x7f19251432d8 id=1 cnt=1 pid=0 pos=1 obj=434 op='TABLE ACCESS FULL CDB_SERVICE$ (cr=3 pr=0 pw=0 str=1 time=23 us cost=2 size=16 card=1)'

CLOSE #0x7f19251432d8:c=0,e=41,dep=1,type=0,tim=2423484985251

kswscrs: error service is already defined in pdb 3.

: current pdb id=1

注意最后出现的提示:

kswscrs: error service is already defined in pdb 3,current pdb id=1。

这个提示给了我们一个重要线索,错误出现的原因是服务名已经在PDB 3中被定义和使用,因此出现了冲突。

再来看看最后执行的这个递归SQL,该SQL从cdb_service$表来取得服务名,进行验证。

select /*+ NO_PARALLEL(c) */ c.con_id# from cdb_service$ c where lower(c.name) = lower(:1) or lower(c.name) = lower(:2)

两个绑定变量的输入参数是:value="enmo" 。

找到了这样一个方向,进一步的检查数据库参数,发现在初始化参数中的确设置了一个服务名enmo,根据错误应该是这个服务名和PDB自动注册产生了冲突。

SQL> startup mount;

ORACLE instance started.

Database mounted.

SQL> show parameter service

NAME TYPE VALUE

------------------------------------ ----------- ------------------------

service_names string yhem,eygle,enmo

接下来尝试去掉这个服务名,重新启动数据库,数据库成功启动。

SQL> alter system set service_names='yhem,eygle';

System altered.

SQL> shutdown immediate;

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

Database mounted.

Database opened.

SQL> show parameter service

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

service_names string yhem,eygle

在熟悉了Oracle的跟踪方法之后,就可以据此不断深入理解Oracle数据库的工作原理,在实践中应对各种异常,并直指根源,找到解决方案。

在12c的多租户环境,修改service_names参数应该非常谨慎,对于该参数的修改会直接反映到监听器的动态注册,甚至会覆盖PDB的动态注册,影响服务。以下过程展示这一知识点,在运维工作中尤其应当引起大家的注意和关注。

测试环境的CDB中存在两个PDB,分别是ENMO和YHEM2,同时service_names参数中存在两个服务名设定,分别是 yhem 和 eygle,这样数据库存在了四个服务名。

SQL> col name for a30

SQL> select con_id,dbid,name from v$pdbs;

CON_ID DBID NAME

---------- ---------- ------------------------------

2 612507346 PDB$SEED

3 965292808 ENMO

4 2839503056 YHEM2

SQL> show parameter service_names

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

service_names string yhem,eygle

在监听器中的注册的服务名如下表征(去除了不必要内容)。

[oracle@enmocoredb ~]$ lsnrctl status

LSNRCTL for Linux: Version 12.2.0.0.3 - Production on 03-AUG-2016 11:08:46

Copyright (c) 1991, 2016, Oracle. All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))

STATUS of the LISTENER

------------------------

Services Summary...

Service "enmo" has 1 instance(s).

Instance "eygle", status READY, has 1 handler(s) for this service...

Service "eygle" has 1 instance(s).

Instance "eygle", status READY, has 1 handler(s) for this service...

Service "yhem" has 1 instance(s).

Instance "eygle", status READY, has 1 handler(s) for this service...

Service "yhem2" has 1 instance(s).

Instance "eygle", status READY, has 1 handler(s) for this service...

The command completed successfully

如果通过如下方式修改了参数,去除部分服务名。

SQL> alter system set service_names='yhem';

System altered.

此时的监听状态会随之改变,包括PDB自动注册在内的服务名被一起清除。

[oracle@enmocoredb ~]$ lsnrctl status

LSNRCTL for Linux: Version 12.2.0.0.3 - Production on 03-AUG-2016 11:10:33

Copyright (c) 1991, 2016, Oracle. All rights reserved.

Services Summary...

Service "eygle" has 1 instance(s).

Instance "eygle", status READY, has 1 handler(s) for this service...

Service "yhem" has 1 instance(s).

Instance "eygle", status READY, has 1 handler(s) for this service...

The command completed successfully

如果遇到这种状况,这意味着所有通过服务名访问PDB的请求都会无法获取连接。解决这个问题的方法是,将PDB的服务名重新通过service_names参数进行显示的设置,就可以临时恢复这个问题。

SQL> alter system set service_names='yhem,yhem2,enmo';

SQL> !lsnrctl status

LSNRCTL for Linux: Version 12.2.0.0.3 - Production on 03-AUG-2016 15:19:49

Copyright (c) 1991, 2016, Oracle. All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))

Services Summary...

Service "enmo" has 1 instance(s).

Instance "eygle", status READY, has 1 handler(s) for this service...

Service "eygle" has 1 instance(s).

Instance "eygle", status READY, has 1 handler(s) for this service...

Service "yhem" has 1 instance(s).

Instance "eygle", status READY, has 1 handler(s) for this service...

Service "yhem2" has 1 instance(s).

Instance "eygle", status READY, has 1 handler(s) for this service...

The command completed successfully

但是注意,在12.2的已知问题未作为Bug修复之前,如果带着这个service_names参数设置重启数据库就会遇到前文所说的问题。

Posted by eygle at 4:06 PM | Permalink | Case (163)

August 19, 2019

Gartner 2011-2018 数据库份额排行:阿里巴巴 华为 腾讯异军突起

2019年6月,Gartner 发布了 2011-2018 年数据库市场份额变化图,下图展示了数据库市场翻天覆地的变化。

在这张趋势图上,Oracle稳居第一,Microsoft 位于第二位。

再然后 AWS 异军突起,占据第三位。中国的云厂商成绩同样耀眼,阿里巴巴位列第九,华为位列第11位,腾讯13.

EBy9VVKWkAETTtx.jpeg

云数据库厂商已经成为新时代的宠儿。

Posted by eygle at 9:58 PM | Permalink | OraNews (260)

近期发表

  • MySQL 实践:制定 mysqldump 简单的备份策略 - August 15, 2019
  • MySQL 实践:查询版本号、存储引擎、存储路径等信息 - August 15, 2019
  • 算法:ORA-600 2252和SCN 最大值SCN_WRAP SCN_BASE - August 14, 2019
  • MySQL 实践:清理 binlog 日志的几种方法和常见问题 - August 14, 2019
  • 警告:ORA-00600 2252 错误正在SCN问题下不断爆发 - August 12, 2019
  • 安装 Oracle 时升级 CentOs 6 至 glibc 2.17 - July 29, 2019
  • 《数据安全警示录》一书修订版出版 - July 23, 2019
  • Oracle Database 19c RPM 安装简介 - May 29, 2019
  • 数据安全:校验Oracle安装软件的 SHA码 防范注入 - May 27, 2019
  • 2019最受欢迎数据库:MySQL居首PostgreSQL第二Oracle第八 - April 11, 2019


  • CopyRight © 2004 ~ 2012 eygle.com, All rights reserved.