dba任意-CSDN博客

原创 4.mysql 双1

N:在提交事务时，log thread 将 binlog_cache 中的数据写入操作系统缓冲,每N次写磁盘,调用操作系统 fsync 刷写IO缓存。2:在提交事务时，log thread 将 log buffer 中的数据写入操作系统缓冲,每秒调用操作系统 fsync 刷写IO缓存。1:在提交事务时，log thread 将 log buffer 中的数据写入操作系统缓冲,并调用操作系统 fsync 刷写IO缓存。1 每个事务提交，把binlog刷到硬盘（最安全、最慢）

2023-08-03 14:07:07 82

原创 3.mysql 两阶段提交

如果在写入binlog后立马崩溃，在恢复时，由redo log中的XID可以找到对应的binlog，这个时候直接提交即可。在这样的机制下，两阶段提交能在崩溃恢复时，能够对提交中断的事务进行补偿，来确保redo log与binlog的数据一致性。如果在写入redo log之前崩溃，那么此时redo log与binlog中都没有，是一致的情况，崩溃也无所谓。在主节点重启后，主节点利用redo log进行恢复，就会相对于从节点多出来一条数据，造成主从数据不一致。写入redo log时，总的来说，在崩溃恢复后，

2023-08-03 14:03:11 62

原创 2.mysql存储结构

若将innodb_file_per_table设置为on，则每个表将独立地产生一个表空间文件，以ibd结尾，数据、索引、表的内部数据字典信息都将保存在这个单独的表空间文件中。段(segment)：表空间是由各个段组成的，常见的段有数据段、索引段、回滚段等，段是一个逻辑的概念。表空间(table space)：系统表空间、独占表空间、通用表空间、临时表空间、Undo 表空间。表结构定义文件以frm结尾，这个是与存储引擎无关的，任何存储引擎的表结构定义文件都一样，为.frm文件。

2023-08-03 11:59:40 51

原创 9.ORACLE 定期清理SNIPED的过期会话存储过程

ORACLE 定期清理SNIPED的过期会话存储过程。#创建JOB每天执行存储过程。

2023-08-03 10:45:21 140

原创 sql优化，生产真实案例7

执行1500万次，执行计划如下，对TBLMITEMCCLASS2MITEM全表扫描，cost为181。造成多对多的关联，其实count的值并不对，原本应该count为0，缺少此条件导致count部位0。建议修改为如下，由于对于具体数值无要求，改为取rownum=1，再count，即可判断是否为0。而且根据package中的内容，这个sql也仅用于判断是否为0，不考虑具体数值。造成全表扫描的原因是把两列进行拼接，导致无法用上索引。并且根据业务反馈，原有sql其实还缺少关联条件。

2023-08-03 10:26:46 31

原创 sql优化，生产真实案例6

当前执行计划全表扫描，cost为9000多。仅用于判断是否大于0，对于具体数字无要求。执行计划的cost为5，检索索引。执行次数十几万，每次0.46秒。查看该package中的逻辑。

2023-08-03 09:59:00 35

原创 sql优化，生产真实案例5

修改参数类型后，执行速度依然没有改善，原因应该是该sql中is null or 这种语法太多，导致执行计划不正确，这种情况以前在其他程序里也出现过。而如果将package中sql查询的那段SQL代码复制出来，代入查询条件却不慢，仅仅是执行存储过程慢，收集sql查询到的表的统计信息也没有作用。对于PLSQL中的执行计划，分析时需要通过10046这种跟踪才能准确找的出来，后续遇到此类问题时可以作为参考。查看文本文件内容，其中下图中的执行计划显示fetch了200多万行。生产库查询存储过程执行慢。

2023-08-03 09:14:17 31

原创 4.生产数据库 db file sequential read 过高造成的性能问题

两个执行计划中都没有发现大表做为驱动表的现象，但是都共同有范围扫描集簇因子过高的索引的问题，第一个SQL中索引CSS_INVADJUST_D_PK2为表CSS_INVADJUST_D字段CID_ITEM、CID_ORG的组合索引，此索引的集簇影子已经非常高，说明CID_ITEM的值在表中数据块的存放非常分散，使得数据库通过索引再读出表中其它数据时要读取更多的数据块。上图SQL中，排名靠前的两个SQL是类似的，排名靠后的三个SQL也是类似的，所以各抓取了两个SQL的执行计划进行分析。

2023-08-03 08:59:44 271 1

原创 3.oracle对某张表的delete记录进行审计

----------------------后续维护，若需要------------------------------生产数据库发现数据表PROD.PROD_TRACKING_NO的数据被无故删除，需要对该张表的delete记录进行审计。4、查询添加了细粒度的对象。----停用审计策略。----删除审计策略。

2023-08-03 08:57:51 280

原创 sql优化，生产真实案例4

高频执行sql 6wgswwwgrm66a 索引优化1、单表查询，查看执行计划，索引 WTDOCUMENT$COMPOSITE5 返回2523行记录，而最终只返回2行记录，索引选择性不好2、查看where条件相关列的数据分布,重建索引。

2023-08-03 08:57:07 45

原创 8.数据库无法登陆，提示archiver error

5、查看alert历史日志，分析为什么archive归档要写到flash_recovery_area，发现由于LOG_ARCHIVE_DEST_1配置格式不正确。3、查看flash_recovery_area参数和archive参数配置，FLA空间为4G，查看该目录确已用完，archive归档日志写入到FLA。6、修改log_archive_dest参数设置，切换日志，archivelog恢复到归档目录，然后添加归档日志清理脚本。2、查看分区空间适用情况，空间并没用完。

2023-08-02 15:27:51 126

原创 7.DNS解析失败,oracle 数据库无法连接,listener重启hang住

问题：为何配置了先通过/etc/hosts解析主机名再寻找DNS，但无法解析（或解析很慢）主机名导致数据监听hang住？查看nsswitch.conf配置文件，配置的的确是先通过/etc/hosts文件解析主机名，再通过/etc/resolv.conf寻找DNS解析。1.1) 查看dns和host配置（/etc/host.conf /etc/resolv.conf /etc/hosts）解决： 1、移走 /etc/resolv.conf 配置文件让数据库无法走DNS解析后恢复。1.在备库重现故障现象。

2023-08-02 15:06:01 603

原创 6.分区表坏块导致统计信息收集失败进而影响sql执行

查看表pdms_testdata_2 和 pdms_testdata_3的统计信息 dba_tab_partitions 和 dba_tables，发现表的全局统计信息缺失。后来收集统计信息时但凡扫描到该block，就会报错，导致表的全局统计信息收集失败，进而影响了CBO选择正确的索引。解决方式：考虑到历史分区的数据已超过保留期限，truncate掉有坏块的表分区，重新收集统计信息即可。查看每天的收集统计信息作业 ----------正常。1、尝试收集表的全局统计信息，但是报错。

2023-08-02 14:57:55 97

原创 sql优化，生产真实案例3

优化表MP_CHAT_READED_COUNT的索引，建立（chatid,fromuserid）列的组合索引。对比libary cache中该sql对应的child cursor的平均执行时间和逻辑读。对比该sql截止目前的所有child_cursor的平均执行时间。2、查看执行效率最差的子cursor的child_number。待优化SQL_ID : 7frm2t109ra7a。3、查看该child_number的绑定变量值。5、查看效率最差的子cursor的执行计划。

2023-08-02 14:37:07 30

原创 sql优化，生产真实案例2

物化视图统计信息陈旧导致job 执行时间过长

2023-08-02 14:26:04 34

原创 sql优化，生产真实案例1

3、获取sql_text，手动执行，收集执行计划，发现执行时间和逻辑读主要消耗在对 BARCODE 列的索引扫描 PK_TBLWHOUTSTORAGE_DETAIL,扫描方式为 INDEX SKIP SCAN。查看top sql，sql_id: 51gg2h8q0t65r 执行次数和消耗cpu较多，优化索引解决。6、重新执行sql，发现执行时间降为 0.01s，逻辑读降为34 ，优化完成。2小时内执行12368次，平均执行1.2s，平均逻辑读 67087。2、查看sql执行计划。

2023-08-02 11:57:30 44

原创 2.oracle数据库无法建立新的连接

数据库无法建立新的连接，已连接进程运行正常，使用sqlplus登录报错 Connected to an idle instance查看监控，从20180125 3：20左右就没办法连接03：19分 W003 空间管理工作器进程down了，J000进程down了2.查看trace日志 pro_db_w003_39912.trc 无发现，02:53后就没有日志了。

2023-08-02 11:42:10 226

原创 5.备份脚本crontab不执行问题分析

在crontab中的备份脚本备份4个用户数据，突然发现每天只备份了2个，另外2个没有备份。bi_expdp.sh（脚本先清理之前的dmp文件，然后执行4条expdp命令导出用户数据）手动执行一切正常，但放到crontab中执行只生成前2个dmp文件。分析：1、尝试调换bi_expdp.sh 中的expdp命令顺序，也只是执行前两条expdp（或者1条），说明与具体某条expdp命令无关。感觉上执行了两分钟之后脚本就自动退出了。

2023-08-02 11:35:36 224