ITPub博客

最近没有研究什么，先整理整理以前的故障分析报告吧！主要是关于一个latch: ges resource hash list和library cache: mutex X并发的故障。1.分析主机负载情况 根据监控所看当时故障期间主要是CPU耗尽，因此查询当时CPU相关日志：VMSTAT:zzz ***Mon Mar 5 08:36:18   CST 2018procs &nbsp

以下SQL 走了全表扫描，效率下降，而SQL中谓词字段选择性非常低，通过直方图，并从btree转bitmap后性能提供，于是对此过程进行分析。Select Count(*) From pmc.DesignXXXXX t Where 1=1  and OrganId='C00000220'And

  Oracle在11g的版本中已经对可诊断性功能进行了大量改进，而在Oracle 11g版本之前诊断事件的语法的比较有限的，11g的版本中的内核调试和诊断功能已经让我们可以更详细精确地的查看到跟踪和转储诊断信息，在oracle 12c的新版本中，oracle继续对诊断功能进行优化改进，并且提供了更加实用性的功能，以更加方便我们进行故障诊断和处理。一.关于oracle诊断事件的

有个关联查询的sql,需要2秒多，于是进行查看一番：SELECT a.id, a.brand_id, a.series_id, a.product_id, a.material_id, a.custom_category_id, a.price, a.product_url, a.organ_id, ..... FROM pm_brand_xxxx&n

        无意间看到了percona-data-recovery-tool 这个工具，这个工具是用来恢复innodb数据文件中的数据，貌似都建议row_format必须是REDUNDANT或者COMPACT。而在mysql5.7.8以上默认为Dynamic，但其实在此处我在Dynamic下测试是没有问题的。当我们误删除某个表数据时，实际上数还存留在数据

给一个登录触发器不生效问题困扰半天，只在alert日志中记录，原来是有了DBA权限。记录下TRIGGER AFTER LOGON ON DATABASE does not fireLogin as a user with DBA privilegesORA-00604: error occurred at recursive SQL level %sORA-06512: at %sline %sO

将表中clob字段生成txt 文件，发现只要超过32k写入就报错。使用UTL_FILE.PUT的方式循环将buffer写入文件，但发现一旦某个字段超过32K，在刚好超过32k便报出以上ora06512文件写入错误  v_out_filename_full := v_filedir_guid || v_out_fileext; &nbsp

     这是一个原来遇到过，困扰过了我们很多人很久的故障，问题迟迟无法解决的原因是因为概念的模糊。os thread startup 是oracle 等待事件中Concurrency的一个等待，与之相关的解释实际非常少。从种种故障现象及字面意义来理解，在进行并行分配是向os 申请进程启动，而在正常的系统中，该动作是非常快的，在我们高压力的数据库环境下，os存在响应问

Description: *************************************************************************            Running with the following parameters        &n

      最近在测试goldengate 从ORACLE 同步到MYSQL，总是出现某一张表的进程同步会出现异常终止，在开启实时同步之前，已通过ogg初始化将数据迁移到mysql，后开启实时同步，在抽取复制了部分数据后就突然终止，2018-10-27 17:28:15  ERROR   OGG-00768  DYNSQL: P

一、 数据库告警日志09:22分出现报错：Thu Feb 25 09:22:04 2016Errors in file /opt/oracle/app/oracle/diag/rdbms/cspora/cspora10/trace/cspora10_ckpt_165762.trc:ORA-01171: datafile 163 going offline due to error advancin

一个rac只能启动一个节点crs的问题，目前怀疑是多播问题造成。前几日在历史库测试PSU升级，在完成一个节点软件升级后对第二节点GI进行升级时，CRS可以正常成功关闭，之后报出了Error : The opatch Applicable check failed，于是尝试重新启动CRS，但很明显CRS无法正常启动。 通过日志查看，发现CRS-5818:Aborted command &#

INNODB锁说明：锁机制是事务型数据库中为了保证数据的一致完整性的特性；在对MySQL进行性能调优时，往往需要重点考虑锁机制对整个事务的影响。MySQL 5.5 版本后InnoDB存储引擎已是默认存储引擎，这里重点介绍InnoDB存储引擎的锁机制。InnoDB主要使用两种级别的锁机制：行级锁和表级锁。Innodb的行级锁分为两种类型:共享锁和排他锁。而在锁机制的实现过程中为了让行级锁定和表级锁定

fio -filename=/dev/sdc1 -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=1000 -group_reporting -name=mytest1.惠普 1万转的sasi 磁盘，三块盘做raid5[root@localhost ho

ORACLE    同步mysql遇到问题：2018-08-27 10:59:54  WARNING OGG-01004  Aborted grouped transaction on DESIGNXXxx, Database error 1105 ([SQL error 1105]Parameter of prepared statem

Oracle 12c数据库在优化器方面确实做出了很大进步。在Oracle 12c数据库众多特性中，自适应查询优化是较大的功能变化了。它使优化器能够对执行计划进行实时调整。当现有的统计信息不足以产生一个优化的计划，它能够及时的找到导致更佳的统计信息的额外信息。自适应查询优化包括两个方面：自适应计划，它着重于改善一个查询的初次执行；自适应统计信息，它为后续的执行提供了额外的信息。 (自适应查

在对oracle优化器的学习认知过程中，我逐渐发现优化器是Oracle数据库非常神奇的组件，它直接决定着一个数据库产品是否工作是否能高效。优化器为每个SQL语句确定最有效的执行计划。ORACLE 随着每个新版本的发布，优化器都会进化，利用新功能以及新的统计信息来生成更好的执行计划。Oracle 12c数据库在优化器方面确实做出了很大进步。本文将Oracle 12c数据库中优化器和统计相关的新特性进

本文转载自www.cnblogs.com，作者ID：649727360需求：需要将一台linux上的mongodb数据迁移到另外一台linux上例：A迁移到B方案：两个命令即可完成任务：数据的导出：mongoexport数据的导入：mongoimport具体步骤：导出：1.找到A的mongodb的mongoexport所在目录。例如：cd /usr/local/mongodb/bin2.将数据导出

mysql 查询一个分区表，当查询条件存在数据时执行效率OK,当不存在数据时执行不完，一直在sending data,当去掉desc就没问题。换个版本貌似也没问题。mysql> select version();+------------+| version()  |+------------+| 5.7.11-log |+------------+1 row in set (0.

2018-08-09 16:02:01  ERROR   OGG-15051  Java or JNI exception:oracle.goldengate.util.GGException: Error detected handling transaction commit event.查看dirrpt下info logorg.apache.kafka.comm