Leaf-分布式ID生成系统
本文摘录于https://tech.meituan.com/2017/04/21/mt-leaf.html2017年04月21日 作者: 照东 文章链接业务系统对生成全局唯一ID的要求有哪些呢?全局唯一性:不能出现重复的ID号,这是最基本的要求。趋势递增:主键的选择应该尽量使用有序的主键保证写入性能。单调递增:保证下一个ID一定大于上一个ID,例如事务版本号、IM增量消息、排序
ORACLE事务和实例恢复过程梳理
最近与一个前辈讨论起关于oracle实例恢复的问题,其实以前都研究过,无奈近一年没怎么研究原理性东西,基本大部分都忘光了,所以场面极度尴尬,现在只能好好再来梳理实验一把,并且把mysql的实例恢复也梳理一下。从oracle 的一个事务说起:例如当我们发起一个update 语句更改某一行数据,例如更改zabbix.cwdtest 的 table_name='ICOL$' 为'
12c可插拔数据库的几种克隆迁移方法
这是以前的一篇文章,无意间看到,记录到这里吧。12c可插拔数据库的几种克隆迁移方法Oacle多租户环境包含一个容器数据库(CDB)和零个或多个可插拔数据库(PDB),这种让数据库系统扩展也变得非常的灵活,oracle 12c提供了许多种关于多租户模式下数据库的克隆迁移方式,以下对于几种克隆迁移的方式进行实验介绍。一.通过现有PDB直接创建(CREATE PLUGGABLE DATABASE..FR
一个基于django框架的SQL 审核系统二次开发
发现自己最近已经焦头烂额,每天在各种繁杂的事务中脑袋已经混乱不堪了。凌晨5点30分,失眠,把我在搞的一个SQL 审核的项目理一理,准备新版本更新上线后就不管了。我的大脑容量真的有限了。这是一个基于github上https://github.com/hhyo/Archery 的一个依赖Inception平台SQL审核系统,我比较喜欢他基于bootstrap 前端的简洁风格。以下是它所用到的
一个基于django框架的SQL 审核系统二次开发
发现自己最近已经焦头烂额,每天在各种繁杂的事务中脑袋已经混乱不堪了。凌晨5点30分,失眠,把我在搞的一个SQL 审核的项目理一理,准备新版本更新上线后就不管了。我的大脑容量真的有限了。这是一个基于github上https://github.com/hhyo/Archery 的一个依赖Inception平台SQL审核系统,我比较喜欢他基于bootstrap 前端的简洁风格。以下是它所用到的
RAT ORA-15507: cannot start workload replay on instance 1
Data Mining and Real Application Testing optionsSQL> SQL> exec DBMS_WORKLOAD_REPLAY.START_REPLAY();BEGIN DBMS_WORKLOAD_REPLAY.START_REPLAY(); END;*ERROR at line 1:ORA-15507: cannot start wo
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-19909: datafile 1 belongs to an orphan incarnationORA-01110: data file 1: '+DATA/lvdb_yt/datafile/system.434.969694045'Managed Standby Recovery not using Real Time ApplyWed Jun 19 16:37:04
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-19909: datafile 1 belongs to an orphan incarnationORA-01110: data file 1: '+DATA/lvdb_yt/datafile/system.434.969694045'Managed Standby Recovery not using Real Time ApplyWed Jun 19 16:37:04
OGG for kafka op_ts 和current_ts相差较大
"op_type":"U","op_ts":"2019-04-30 07:04:36.844662","current_ts":"2019-04-30T15:07:36.778001","pos":"00000016630241124960"
MONGO 集群 修改linux主机时间后的影响
生产环境是 一主一从一仲裁3分片的集群,现在发现其中一个节点比当前时间大了好几天,后使用NTP将时间往回调整副本集上。 原来时间是5月3日,当前是 4月26日,对此进行了调整。[root@cwdtest1 bin]# dateFri May 3 13:20:31 CST 2019 [root@cwdtest1 bin]# ntpdate -u 10.205.34.1
笔记 mongo查询慢日志,创建索引
1.查看mongodb慢日志是否开起use LogDB;db.getProfilingStatus();2.开启慢日志,设置超过100毫秒的操作为慢操作db.setProfilingLevel(1,100); 3.查看慢日志内容db.system.profile.find().sort({$natural:-1})日志,shard3:PRIMARY> db.system.profi
MYSQL order by排序导致效率低小优化
有一个主表left join 同一个小表两次分页语句,因为order by 导致执行时做排序,从执行计划中Using filesort ,以及profile中creating sort index 耗时可以看出。从trace文件可以看出filesort的计算:"join_execution": { &nbs
OGG-01224 error 111:Connection refused - retries exceeded.
OGG-01224 error 111:Connection refused - retries exceeded.目标端进程正常启动,端口开启监听,且没有防火墙限制,但源端p进程一致报出Connection refused错误。2019-01-04 02:25:08 WARNING OGG-01221 Connect failed to 10.101.x.xxx:9902
一个latch: ges resource hash list和library cache: mutex X并发的问题分析案例
最近没有研究什么,先整理整理以前的故障分析报告吧!主要是关于一个latch: ges resource hash list和library cache: mutex X并发的故障。1.分析主机负载情况 根据监控所看当时故障期间主要是CPU耗尽,因此查询当时CPU相关日志:VMSTAT:zzz ***Mon Mar 5 08:36:18 CST 2018procs  
oracle 一个or语句因字段数据分布不均并缺少直方图引起的全表扫描优化分析
以下SQL 走了全表扫描,效率下降,而SQL中谓词字段选择性非常低,通过直方图,并从btree转bitmap后性能提供,于是对此过程进行分析。Select Count(*) From pmc.DesignXXXXX t Where 1=1 and OrganId='C00000220'And
oracle 12c 新增的诊断事件的初步尝试
Oracle在11g的版本中已经对可诊断性功能进行了大量改进,而在Oracle 11g版本之前诊断事件的语法的比较有限的,11g的版本中的内核调试和诊断功能已经让我们可以更详细精确地的查看到跟踪和转储诊断信息,在oracle 12c的新版本中,oracle继续对诊断功能进行优化改进,并且提供了更加实用性的功能,以更加方便我们进行故障诊断和处理。一.关于oracle诊断事件的
一个left join SQL 简单优化分析
有个关联查询的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恢复ibd数据的工具的一些测试
无意间看到了percona-data-recovery-tool 这个工具,这个工具是用来恢复innodb数据文件中的数据,貌似都建议row_format必须是REDUNDANT或者COMPACT。而在mysql5.7.8以上默认为Dynamic,但其实在此处我在Dynamic下测试是没有问题的。当我们误删除某个表数据时,实际上数还存留在数据
登录触发器不生效,只在alert日志中显示
给一个登录触发器不生效问题困扰半天,只在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
UTL_FILE.PUT写入txt时超过32k报ORA-29285: 文件写入错误
将表中clob字段生成txt 文件,发现只要超过32k写入就报错。使用UTL_FILE.PUT的方式循环将buffer写入文件,但发现一旦某个字段超过32K,在刚好超过32k便报出以上ora06512文件写入错误 v_out_filename_full := v_filedir_guid || v_out_fileext;