ITPub博客

首先我们模拟写入1000万数据。图1这个由于我存储过程中写了一些运算，所以以每秒不到5000条的速度写入，这个性能未达到最佳。                                      &nbs

      有人向我提问：oracle 的select count(*) from table 不走索引，mysql（版本>=5.7） select count(*) from table是自动走索引的，是这样吗？因为提问题的人查过MySQL的count(*)是做过优化的。要回答这个问题，还是用实验来说明。在Oracle 19C中，我们建立一个表，并且写入100

      有一天，一个开发找到我说。他的这个select 任意列 在查出数据的情况下 点击图1的这个按钮，数据逐步加载，然后就会出图2的报错。                                &

很多人喜欢把字段默认设置为空，然后用空去判断逻辑。比如select * from t where xx is null.其实这种做法有较大的问题。我们例举一下：如图1                                &nbsp

    2013年一次偶然的机会参加DTCC，在会上看到国内顶尖高手的演讲。这里其实要感谢ITPUB每年的DTCC和SACC我是一直参加的。没有这么多年的参会学习，就没有现在。   当时在大会上看到云和恩墨的一众大神盖国强、侯圣文、李轶楠、张乐弈、杨廷琨、李真旭等等，介绍的时候都是Oracle的ACE和ACED。关于什么是ACE请看我之前的链接。https:

    我有个“歧视”，就是开发写的视图基本都是有问题的。这来自于我多年的实际工作。视图是数据库的一个工具，但是绝大部分开发不是从数据库角度出发来写的。所以一般来说写的并不会让数据库很舒服，甚至是痛苦。    今天有一个开发拿SQL找到我，我一眼看到一个V_XXX。不用问，这就是一个视图，我对开发说你打开它，我看看。我极度怀疑这个写的不合格。打开一看，果然没

    很多场景下，我觉得加索引这个其实都不能算是优化。    多年前听到一个故事说一个DBA去了银行，回来被一个银行里面称之为大神。DBA的同事们说来给我们讲讲你怎么优化的？该DBA说，实在说不出口啊。我仅仅是加了一个索引而已。而已，而已，而已。    我们在工作中有两类最常见：一类是没建立索引，比如我刚才说的。这种连开发都知道应该建立

      我从学习数据库开始就知道，硬解析会有很大问题。我接触的数据库中貌似只有Oracle会涉及到这个。有的时候我自同等环境下（硬件配置和场景）测试下来Oracle会由于其他数据库的数据，我有时候就在想会不会这就是软解析和软软解析带来的效果？      不过十几年工作下来，几乎没有遇到过硬解析带来的问题。但是试问苍天饶过谁。我这就遇到

今天有人让我帮忙看一个系统，检查一下。因为这个系统暂时无人专职维护。我托人拿到后台日志，我看到有个系统的SQL是排名靠前的TOP-SQL，每天执行6000多次，每次12秒。把他找出来一看就是全表。从技术的角度，我们当然可以告诉他，应该加一个过滤条件。然后找到开发，告诉他你看我给你这样的改进建议。开发拿着这个意见回去说评估一下。     下午评估结果出来了，说理论上这样

       刚回到家，有人发我一个问题。莫名其妙啊，创建索引为什么出这个错？还涉及到包和存储过程。干了10几年第一次见。关键是网上是找不到类似的解决方案，什么升级等方案有点坑爹了。还是靠自己吧。那就顺着提示到所谓的schema下看看。结果是这样的，看到左边有个红叉。那就是这个包不能用了。我重新编译一下，不能编译。这时候也有点懵。看来还有连带更深层次的问题。

     有人问我有个SQL原来100ms的现在200毫秒了，为什么？我看了一下，他这个是依托inmemory硬抗的那种SQL。里面这个特性将数据放在内存中处理。这不是一个正式环境，我觉得开发能有此意识是非常不错的。在测试环境发现了问题，避免带病上阵。然后我检查了后台数据库负荷、AWR等等，从AWR中看没有多少inmemory的访问。难道没加载上来吗？查询了一下sel

    以前遇到过一个这样的问题：这个问题不常见，网上也能找到几个说明的帖子。结论就是数据库文件被黑客或者病毒破坏了（来自网上的结论）。遗憾的是我不会处理。从数据库体系上来说Oracle比PG复杂，PG比MySQL复杂。复杂到MySQL我自己觉得我了解的还行，倒是Oracle用了很多年，时至今日只能说不陌生。他太复杂了，我不敢说我非常的精通（只是一般精通）。MySQL单进程多线

     有一次听一某个银行讲他们用Oracle，说到业务连续性，他们说，如果卡死的时候要么重启，要么切换。他们明显是走重启路线的，类似强制关机那种。当时他说了一句，主机宕机了就重启数据库。主机宕机情况下，Oracle从来没有让我失望我。     以上是别人的声音，我回想我自己经历（仅代表个人），似乎也是差不多。只是刚工作时候用Oracl

     有一次大会听运营商和金融行业等都对业务连续性提出了很高的要求。在保证一致性的前提下，尽可能短的减少停机时间。这个压力主要都是在数据库上。在灾难来临时候对数据库进行切换。我们平时说的高可用一般来说都是容灾的，其实对于性能来说不是直接的提升。主从两个数据库采用读写分离来缓解压力，属于间接提升。我还是那句话，提升性能还是靠SQL。当然我也不反对硬件提升来提升性能。

   经常遇到这种场景，select count(*) from t where t.col='XXX'  其实col列就2-5种类型，这种通常来说建立一个索引的效果不好。但是去找开发谈的时候，开发说这就是2B的企业用户场景。一共就2-3家公司，又不是2C的有上万个用户，每个用户看自己的数据。这里每家公司已经是只看自己的数据了，就这样。  &

有时候刚开始设计的时候没考虑到数据归档。数据归档不是简单的导出delete。因为一般我们的数据库都是delete不释放空间。而我们一般数据库遇到空间不足，就不得不面对这个问题。当然也可以做碎片整理的空间回收。我不太喜欢这样，尤其大的表的时候。MySQL一旦超过100G的，在线环境我都不敢去做。Oracle的在线回收我做过20T的表，碎片800G，回收了一次做了55个小时（不停机）我个人觉得最好的方

   最近遇到一个问题看到AWR显示的TOP事件是这样的   resmgr:cpu quantum  这就比较头疼了,CPU处理不过来。拿了一下出问题前半个小时的AWR。看到比较严重的是这样的。  SQL处理一下大概长这个样子：SELECT * FROM （select 若干的sum(SELECT 一个配置&

   Inmemory是Oracle12C开始推出的一个功能。我们一般OLTP数据库中数据是按照行的形式存储的，因为我们新增记录都是insert into，这是一行行的写入。而我们在分析的时候一般都是对一列或者几列聚合统计，count，max，min，avg等等，这些统计的时候对于OLTP数据库其实是一行行的读一次，最后得出的（max和min有索引不会这样）。所以如果一个表列越

     说起OGG大家不陌生。但是OGG的部署全是命令行的，而且查问题也是要用命令行，非常不方便。熟悉这些的人很少。OGG属于CDC的一种，我见过很多CDC工具，目前看下来OGG是问题最少的。当然最好的就是一个数据库，那么连OGG都可以不用了。     在一次OGG的学习过程中偶然知道OGG21C的版本有面向微服务版的，而且是图形化的。

     自己公众号原文：https://mp.weixin.qq.com/s/Qx7_WJ4oNpibOJZ18BlzeQ     说到闪回，熟悉数据库的人都知道。数据库自带闪回的我知道有Oracle，通过一些列工具或者方法做到闪回的有MySQL、PostgreSQL等。     实验开始：为什么要建立一个表空间？因