ITPub博客

将表中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 &#

 MYSQL 连接登录过程分析在较新MYSQL版本中，默认没有开启线程池的功能，每个客户连接在服务器进程中都拥有自己的线程。当客户端（应用）连接到MySQL服务器时，服务器要对其进行认证（Authenticate），认证方式基于用户名、原始主机信息和口令。登录mysql 可以通过Unix socket与TCP两种方式登陆，Unix socket是实现进程间通信的一种方式，mysql支持利

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

今天我分享下简单总结导致oracle数据库主机CPU sys%高的一些原因。在日常的数据库运维中，操作系统CPU 使用率一直是我们衡量系统负载的一个比较贴切的指标，例如USER%可以更好的反馈数据库对CPU的使用情况，进而我们再次去数据库中找出导致CPU消耗高的源头，wa%可以反馈IO等待消耗的CPU时间百分比，当wa的值高时，可以说明IO等待比较严重。然而，当CPU SYS%异常增高的时候，我们

    心底无限次怂恿自己赶紧放弃，尽快结束当前的工作。多少次的后悔才能换来今生的无怨无悔，近30岁，IT男，依然活得那样的幼稚。还好我会焦虑，中年危机什么时候会到来？    扎身oracle这么多年，发现自己学得只是冰山一角，总是学了又忘，忘了又学。这让我重复性的投入所有的时间，到头来发现，那些光鲜的人，说自己懂得这

1.分析hanganalyze日志：Chains most likely to have caused   the hang:《《《最终阻塞源都是由于resmgr:cpu quantum引起。 [a] Chain 1 Signature: 'resmgr:cpu quantum'

       在Oracle Database 12c中多租户架构模式无疑是所有新特性中最大的卖点，在多租户模式中把一个单一的多租户容器数据库（CDB:Cantainer Database）挂载很多的可插拔数据库（PDB：Pluggable Database）使用，对PDB的不了解，也给日常的工作造成了许多的困扰。一、关闭PDB时遇到的尴尬  ...

  1. ora event 出现大量的library cache:mutex X，且除此等待之外，其他等待较少或没有。   2.通过查询v$session中librarycache: mutex X等待会话的p1值。    Select p1,count(*) from v$session whereevent=’ library cache ：mutex X’ group by p1 order by 2 asc;   ...