ITPub博客

今天最终还是有些小感冒，在家休息，也看了好几集的《黑名单》，也算是给自己放个小假。然后不知不觉就想起最近的一些事情。记得前几天看到微信群里大家发的一张貌似印度人摊饼的小视频，看起来还是蛮有意思，硕大的炉子，印度人坐在地上把薄饼直接摊在旁边的炉子上，翻翻转转倒也是自如。但是我看了以后，还真没有觉得有...

最近有朋友在微信公众号后台留言提了一个问题，问题如下：执行计划中，并列的两条操作比如并列的两条table access full，上层没有关联操作比如hash join，这是什么意思？但是两张表在sql中是有等值连接的，为什么执行计划没有提现连接方式呢？然后他过了一会附了一张操作截图。这个问题一下子看起来就比较清晰...

  白天时不时闪过一些年头，虽然现在离家很远，扫墓什么的不现实了，但是有什么亲人可以在我内心寄托深深的思念，我内心非常怀念的还是我的爷爷，说是爷爷，其实应该叫外公，没学会太多礼数，结果为了顺口爷爷奶奶一起通叫了。我和爷爷可能交流会少一些，在我印象中身体那是好的惊人，80多岁的时候还可以骑着自行车去...

关于数据库的启停，以前一直认为是最简单，最没有技术含量的任务，但是接手的环境越多，越来越证明我最初的想法是错误的。数据库的启停是一个敏感操作，重启一定是有着特定的原因和需求。而且这个过程中存在这太多的可能性，很可能在同一会话窗口中，停掉数据库再次启动就会报错；很可能硬件扩容，也会导致数据库实例无法...

之前写过一篇 物化视图刷新结合ADG的尝试，想必绝大多数的朋友看完再没有深究，其实也有些朋友做了建议，让我尝试prebuilt来做。这种数据迁移方式用的比较少，但是个人感觉还是很不错的。如果迁移的表不是很多，这种迁移方式还是非常强大的。如果一个表非常大，我目前的设想就是通过ADG备库来把数据首先同步到统计库中，然...

最近积累了几个问题，我就凑在一起做一个统一的答复，微信后台的留言回复超过24小时就无法回复了，有时候看到的时候已经过了时间点了，实在抱歉。有时候有些朋友是通过qq或者微信来问我问题，有时候运气好能够马上定位，感觉非常侥幸。今天回答5个小问题。第一个问题是在昨天晚上准备睡觉前，一个微信好友的提问。说自己...

今天抽空看了很多业内人士的博客，感慨良多，看着这些博客，可以从他们的日志内容中看到那些对于技术孜孜不倦的分享精神，对于一些小小的技术改进他们都会在博客里面做很细致的评论。有些博客着实让人佩服，光是看哪些分析的层面就让人叹为观止，能够静下心来看完肯定不虚此行。我是带着猎人的心态来看待很多的文章的，都是...

最近碰到一件事情很感慨，简单说说。有下面的三个数据库实例，都是在开发测试中使用，一台服务器上有业务1+业务2，另外一台服务器上有业务1+业务2.当然为什么会有这种重合，对于DBA来说也实在无从得知。从数据整合的角度来看，服务器1上的业务2数据库目前的负载很低，而且和业务1的交互比较多，本来拆分的库现在要考虑整...

     最近碰到了一个比较奇怪的数据库连接问题。问题的起因是做一个数据整合的时候，把服务器B的防火墙信息都拷贝到了服务器A，迁移的过程都很顺利，是一套开发测试环境，迁移完成之后，从应用的反馈来说都没有发现问题，过了几天有个开发的同事找到我说，她现在连接数据库的时候总是有超时的错误。之...

对于数据整合式迁移，基本就是小霸王的二合一，四合一，八合一这样的节奏，把几个尽可能相关业务的数据库中的数据整合到一个库里。彼此还是独立的schema，倒也是相安无事。在这种整合式迁移中，比较让人纠结的部分就是性能不是排第一位，而是迁移前的准备比较琐碎。如果环境中有大量的db link，那就好像蜘蛛网一般，每个...

对昨天提出的问题做了一个简单的分析和排查，也算是有了一个交代，上一篇文章在 dg broker校验失败的一个奇怪问题 http://blog.itpub.net/23718752/viewspace-2064499/我查看了最近的日志，发现在半个月以前有一行日志引起了我的注意。Thu Mar 03 17:32:12 2016ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE...

前几天碰到一个看起来有些奇怪的例子，今天抽空把分析过程整理了一下。有一主一备的一套测试环境，之前环境在我手里，交给另外一个同事之后，重新搭建了dataguard，我检查了一圈，发现都没有问题，然后过了一个星期的样子，无意中再次查看的时候，发现这个备库竟然在dg broker中的状态是disable，当然我也不能看到这个现象...

11g中的ADG特性本身已经非常有特色，促使很多对于10g中不太灵便的备库升级到11g，对于DBA是一大福利，那么还有一个福利就是snapshot standby了。在平时的数据更新操作中，DBA可以做好sql审核，如果对于复杂的，繁多的变更，如果有些变更有一定的依赖，数据变化情况比较大，评估有难度，很多问题单纯在测试环境还发现不了，...

   今天喝了点咖啡，突然发现不光没精神起来，反而头晕脑胀，完全不在状态，好吧，一天的日子又过去了。虽然处理了几个遗留问题，但是还是容我说一说今天的一些感受，就是目前感受到的隐隐的危机意识，莫名其妙的，自己有了一种深深的危机感，也许这也是好事吧。    都说时过境迁  三十年河...

    最近开发提了几个需求，需要把几个线上的分布式的表整合到统计系统中方便统计，看来分久必合，合久必分，当时的分开考虑，肯定没有想到以后会整合起来，这可对我们是一些额外的工作，这个时候增量数据的问题就摆在我们眼前，当然目前已经基本抛弃了根据日期来增量同步数据，因为会有dml的数据不准确，当...

今天看到一个报警信息，大体是CPU使用异常。ZABBIX-监控系统: ------------------------------------报警内容: CPU utilization is too high------------------------------------报警级别: PROBLEM------------------------------------监控项目: CPU idle time：55.17 % ------------------------------------...

最近碰到了一个oracle bug，但是我感觉还是有些运气的成分，虽然错误日志和bug描述吻合，版本也完全对应，现在有几个问题在我脑海中翻腾，就是这个问题是不是一个特例，是不是一些额外的原因导致的，于是我翻出了日志重新来看。这是一个一主两备的环境，一个本地灾备，一个异地灾备，数据库版本是10.2.0.4.0，单实例数据...

   开发同学前几天给我提了一个数据查询的需求，大体是查询某个表的数据，然后把查询结果以csv的形式提供给他们，一般来说这种定制查询，开发的同学都会提供好语句，DBA同学只需要简单执行即可。   每次看到语句，我都要简单评估一下，今天的语句看起来非常简单，需要在一个历史库中进行数据查取，从...

今天对之前描述的问题一条insert语句导致的性能问题分析（一) 进行了进一步的补充。有一条insert语句的主要性能瓶颈在于insert子句中的查询语句，查询中的主要资源消耗在于对两个表进行了多次关联语句主要的结构如下：insert into xxxxx   (select * from TEST_vip_new minus select * from TEST_vip_new_bak&nbsp...

系统中有这样一条报警信息，看似比较简单，但是引起了我的注意，主要原因是因为这是一个10gR2的备库，备库如果出现这样的问题，看起来似乎是在归档删除上存在一些问题。[DB监控系统]_ora_test_s2_yangjr@10.127.2.133_报警ZABBIX-监控系统: ------------------------------------报警内容: Free disk space is less tha...