MySQL 中的 localhost 和 127.0.0.1 的区别
[toc]
今天看到一篇文章,是测试 MySQL 8.0 修改密码并验证登录的文章。
其中有以下验证
可以看到上面修改的是 root@'localhost'
用户的密码,而下面验证登录的是通过-h127.0.0.1
的方式登录。这很显然是有问题的,是不严谨的,为什么呢,因为在 MySQL 中 localhost 和 127.0.0.1 是有一点区别的。
下面说下我对 MySQL 中的localhost
和 127.0.0.1
区别的理解。
ORACLE 常用脚本
[toc]
等待事件
1 | set lines 200 |
查询会话相关
根据等待事件查会话
1 | set line 199 |
根据用户查会话
1 | set line 199 |
根据SQL_ID查会话
1 | set line 199 |
根据会话ID查会话详情
1 | set line 199 |
查询阻塞会话
1 | set line 199 |
查询会话的对象信息
1 | set line 199 |
ORACLE 23c 初体验
[toc]
Oracle Database 23c 已经 GA 了,Oracle Database 23c: The Next Long Term Support Release
We are pleased to announce that the new version of the world’s most powerful database, Oracle Database 23c, is now Generally Available on OCI Oracle Base Database Service.
安装部署
之前新版本发布之后,初步体验就是安装部署,捣鼓一堆,现在简单了,安装是最简单的了。
1、rpm 安装
2、docker 安装
3、官方提供的 Oracle VM VirtualBox ova 直接导入
rpm 和 ova 暂且不提,本次体验用 docker 安装三部曲。
ORACLE 分区表默认统计信息搜集验证
ORACLE 手工修改统计信息阈值
[toc]
概念描述
Oracle收集失效的统计信息的策略:自上次自动统计信息收集作业完成之后,如果DBA_TAB_MODIFICATIONS
中记录的INSERT
+UPDATE
+DELETE
所影响的行记录之和超过了DBA_TABLES
中目标表记录数的10%
,或者是自上次统计信息收集完成之后目标表执行过truncate
操作,那么 Oracle 会认为目标表的统计信息已经失效,自动统计信息收集作业就会对目标表重新收集统计信息。
但是对于一些超大表,可能数据变化超过10%需要很长时间,这就导致统计信息很长时间搜集一次,可能导致统计信息不是最新,从而产生执行计划不准的情况。
可以通过EXEC dbms_stats.set_table_prefs(ownname => 'MES',tabname => 'METABLEXXX',pname => 'STALE_PERCENT',pvalue => 5);
来修改这个10%
的阈值为5%
ORA-00600: 内部错误代码, 参数: [qkaffsindex5]
[toc]
适用范围
ORA-00600: 内部错误代码, 参数: [qkaffsindex5],存在函数索引,或者desc 索引,ORACLE 12c及以后版本
问题概述
数据库日志报:ORA-00600: 内部错误代码, 参数: [qkaffsindex5]
,详细信息如下:
*** 2023-05-15T13:31:12.142282+08:00
2023-05-15T13:31:12.142272+08:00
Incident 427804 created, dump file: /app/oracle/base/diag/rdbms/p1fspdb/p1fspdb1/incident/incdir_427804/p1fspdb1_ora_48751_i427804.trc
ORA-00600: 内部错误代码, 参数: [qkaffsindex5], [1], [], [], [], [], [], [], [], [], [], []
trc 日志报:
[TOC00000]
Jump to table of contents
Dump continued from file: /app/oracle/base/diag/rdbms/p1fspdb/p1fspdb1/trace/p1fspdb1_ora_48751.trc
[TOC00001]
ORA-00600: 内部错误代码, 参数: [qkaffsindex5], [1], [], [], [], [], [], [], [], [], [], [][TOC00001-END]
[TOC00002]
========= Dump for incident 427804 (ORA 600 [qkaffsindex5]) ========*** 2023-05-15T13:31:12.142778+08:00
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
[TOC00003]
—– Current SQL Statement for this session (sql_id=6bvp8rj1jqtpk) —–
select t.value_index || ‘’ from spc_value_t t
where t.value_index >= 2023051200000000000000000000
and t.value_index < 2023051300000000000000000000
[TOC00003-END]
问题原因
spc_value_t
表上存在 desc 索引,在函数索引、desc 索引的情况下会出现此bug。
本站从 Wordpress 迁移到 Hexo、GitHub、Vercel
本站从 Wordpress 迁移到 Hexo、GitHub、Vercel
ORACLE dbms_schedule JOB 分配机制
ORACLE ADG 备库搭建 log[data]_file_name_convert 参数配置注意事项
[toc]
适用范围
ORACLE ADG 备库搭建过程,log_file_name_convert
参数配置如下,导致无法创建redo log file 。*.log_file_name_convert='+DATA/dbrac/','/u01/app/oracle/oradata/orcldg'
问题概述
ORACLE ADG 备库搭建过程,log_file_name_convert
参数配置如下,导致无法创建redo log file 。*.log_file_name_convert='+DATA/dbrac/','/u01/app/oracle/oradata/orcldg'
具体报错如下: