当varchar和Nvarchar关联
Nvarchar数据类型比较特殊有开发人员反馈,两个字段关联,一个是varchar、另外一个是Nvarchar,会有性能问题吗?这个问题其实不能说一定有。通过实验来说明吧。具体实验-表结构A表的VAR列、NVAR列和B表的NVAR列和M列有索引B表的VAR列索引不可见(或者说没有索引)类型转换VAR列有索引,但是是字符型,给了一个数值。函数转换了,全表扫描在执行计划中也看到了TO_NUMBER(“
故障是试金石:从一次Oracle宕机看成熟IT系统的韧性
先说感叹,成熟的产品就是出问题都让人放心上个月有一次有人反馈低代码平台不能用。一看是低代码的应用停了。这个怎么停了?是只有他停了吗?再去看看应用连接的数据库也停了。那么就启动数据库吧。启动以后看看日志,之前发生什么问题了。结果从日志上看到从7月23的13点后就没有日志了。然后就是7月28下午15点的启动。按说不应该啊,一般遇到问题导致异常关闭,应该有错误信号和日志。但是这里明显没有。仔细想来想去,
In-memory不要全加载怎么做?
In-memory这个功能都有十多年了大家都知道alter table t INMEMORY,这一个命令就让Oracle数据库实现了行列混存。没什么特别的点。但是最近我遇到了一个问题,就是需要部分列加载有些问题深耕一下会发现不一样的为什么要深耕一下?是因为我要加载部分列。为什么不全部加载?那是因为内存有限。一个表中仅仅有2-3个字段需要聚合。全部加载浪费内存。全部加载会很大吗?会的,当你见过一个表
44岁遇见NDBC42届:我的数据库人生下半场,从工程师到学术新兵的觉醒
机缘巧合十几年前第一次知道CCF还是从韩锋老师那里的自我介绍知道他是CCF的成员。了解到这个机构是非常专业的学术机构。那时候就觉得CCF高大上,也非常难以加入。经过多年在数据库行业的工作,也慢慢成长了。这次也是在和华师大原副校长周傲英教授的日常交流中,提及问我有没有兴趣加入?我个人当时是非常激动的,这是我一直以来的愿望。现场参会本次大会在长春,当我踏入第42届NDBC(中国数据库学术会议)会场时,
Oracle MCP本地部署测试
中国区ACE群中看到了这个很快有人写出了中文版教程这里感谢葛云杰和刘鹏程两位指出我的疑惑我基于之前的教程还是踩坑了,这里写一下(毕竟每个人还是环境不一样)下载路径(中文)https://www.oracle.com/cn/database/sqldeveloper/technologies/sqlcl/download/界面如下当然要求要安装JDK8.我看了我是23,应该满足了。[oracle@o
数据库解耦,代码复用?还是数据库复用,代码解耦?
这个也是我看了有些行业的有感而发背景涉及微服务和中台。都是我个人观点,不代表对错我们说一下20年前,那时候我觉得类似工商银行和中国移动这些的业务量远比我们现在的绝大多数非互联网公司业务体量要大吧?那时候也没有微服务、没有中台更加没有Hadoop。业务也能有条不紊的进行。那时候是大型机、小型机和IOE架构等。微服务其实不一定要分库但是的确如果在都在一个数据库那还做什么微服务?其实有不少企业和场景不适
降本增哈哈哈哈哈
声明和一位好友共创的不知道大家有没有这种体会,有些我们使用了很久的软件。慢慢的不那么好用了。比如笔记软件搜索找不到自己的东西,比如聊天软件有这种那种的bug,再比如有些软件觉得不是退化了,就是傻了。升级以后还不如多年前好用。曾经有人告诉我,一个经验丰富的专家的薪资可能是N。而一个刚毕业没有经验的薪资可能是N/10。那么在一个不是技术掌握绝对话语权的企业中。决策者就是觉得,用N/10的人替代N的人。
写在金仓发布会之后
上周开会这周才写这是因为最近安排的太满了,上周金仓会议后又接着信通院的会议。每天连吃饭都安排的很满,我是第一次出去参会忙的一天衣服都没洗。发布会提到经过大家多年的认知已经对此有了认知了。我这里想说的,非互联网场景,就是想把复杂的应用结构做到应用侧可能都做不到。不少场景还真是必须在数据库中做。这已经不是开发成本问题,而是可行性的问题了。复杂SQL的原因–需求复杂–设计复杂–场景复杂传统行业的业务场景
一次意想不到的ADG中断
背景很特殊非我所负责的范围。别人求助我有一套Oracle数据库的ADG中断了。这个背景是十几年前这个Oracle数据库的高可用采用了阵列复制的存储层解决方案。这个方案虽然也能做容灾,但是不是Oracle官方的解决方案。这个技术完全依赖底层存储复制技术,其原理是主数据的磁盘变化,同步到灾备磁盘上进行文件块的改写来实现。这种技术其实可以用到很多数据库上。因为这根本不是数据库技术。(这点涉及到现在的问题
我说点不一样的参会感受
今天的图片可能有点多,也有缝合的迹象,但是也有我自己的观点早些时候被邀请作为大会出品人以及演讲嘉宾和圆桌嘉宾非常荣幸。原计划两天圆桌讨论我就一天,而实际上我过于热情,举办方让我参加了两天的。为此还录制了一段祝福视频在大会主会场循环播放今年的PG生态大会,是我参加历次中最大规模的。这个规模堪比DTCC的主场规模。众所周知PG的有一个特点就是不像Oracle、MySQL、Mongodb、Redis、E
哪个领域数据库最难替换?
今天说的要有点争议了,我个人认为不一定是金融领域。数据库最难的一定是金融级,但是场景严苛和替换难未必是一回事数据库最严苛的是金融领域金融场景最严苛是毋庸置疑的。不能错,不能丢,不能慢。人行监管下同城双活都是最低要求。两地三中心,三地五中心都有。金融用的人也多,所以业务量大,几乎都是7X24小时的。在这种场景下单机数据库可能受到一定挑战。大型机、小型机、以及exadata这样的硬件结合数据库自身的高
还是要感谢一下Oracle
上周写了国产数据库的今天谈谈Oracle感谢Oracle从一毕业让我安装Oracle,我连Oracle是什么都不知道。到如今吃数据库这碗饭,真心的感谢Oracle带我进来。而从Oracle上学到的技术,用在其他数据库上基本都能用。有差异的只要学习差异就行。复用性还是非常高的。安全大约5年前,2020年4月10日Oracle通过公安部“信息安全技术 网络安全等级保护基本要求”(以下简称“等保2.0”
以下几个国产数据库都还可以
我曾经陆续接触了一些国产数据库都是主动找到我希望我可以对产品、技术、文档、生态等诸多方面给出建议,甚至是批评的。这点感受非常好。我也愉快的接受了。当然部分也授予了我一定的荣誉,也有的马上就有一些荣誉。与之形成对比的事国内也有不少厂家,你是不可以去说一点负评价的。要么删除文章、要么启动法律程序等。这类也不会去找业内同行去提意见从而改进自己。以下按姓氏笔画排名(英文字母)cantian:华为开源,存储
TiDB的闪回
经历过Oracle的闪回都觉得这是一个救命的功能MySQL数据库要想实现这个功能,需要做很多人工的操作。很多数据库都可以利用日志、实时备份、延迟复制等各种组合拳解决Drop table的问题。这就使得类似闪回的功能非常人性化了Oracle的闪回这里不介绍了能找过过去一定时间内的数据或者drop的表。看看TiDB的闪回mysql> select * from xxg limit 10;±—±-
闪回还能导致OGG同步失败
本身这两个其实没有关联性事情的起因是由于一个误操作,本来update where id=xxxx,结果where没带变成了全表更新,且提交了。但凡出现这种情况,操作人员一旦意识到了,不慌是不可能的。得知数据库是Oracle,那么还有机会。create table bak as select * from of timestamp to_timestamp (‘2015040216’,‘yyyymm
OceanBase 桌面版
OceanBase分布式起家现在也做集中式场景之前有过单机版现如今已经开始有桌面版了在这个安装过程中我发现了底层逻辑,原来是安装过程中先安装了一个类似虚拟机的东西。(而且官方把这个做到exe的安装包中去了,这个就很好。省的用户自己安装了。)具体信息可以从下图中的说明可以看到。于是就解释了为什么有这个Windows下的桌面版。原来和Java一样的思路,用一个JVM来跨平台。安装顺利,启动不顺这个问题
为什么有些用户还要RAC架构
RAC解释RAC一词最早出现是在Oracle上。它是real application cluster的缩写,译为“实时应用集群”。就是Oracle9i开始有的一种高可用架构。架构简图大致如下:其实多年前我在接触RAC之前看到的是其他技术的集群,也类似这样。我当时年少无知的其实不以为然(在多个场合我都承认过自己的无知)。我说这就像一个人长出来两个头,砍掉一个是不影响。但是如果身子坏了呢?的确如果共享
一次Oracle的非正常关闭
数据库自己会关闭吗?从现象来说Oracle MySQL Redis等都会出现进程意外停止的情况。而这些停止都是非人为正常关闭或者暴力关闭(abort或者kill 进程)一次测试环境的非关闭一般遇到这种情况先看一下错误日志吧。2025-06-01T06:26:06.352576+08:00PMON (ospid: ): terminating the instance due to ORA erro
低谷才是出成绩
有些朋友说我现在是高光,其实不然之所以有这样的误解,是我个人的简历上是不断增加名誉。这点属实,看看我的词条:https://www.modb.pro/wiki/4245的确如此。但是其实也有误会。事情可以反过来看。因为,如果做技术的在企业内至关重要。那么极有可能一天到晚大会小会都涉及。一刻都走不开,甚至是没有什么休息日的。因为我之前有几年就是这么过来的。塞翁失马就是例子。有时候一件好事反过来一看就
TiDB加索引阻塞的解决
起因在测试环境中反应如图所示,加索引执行了几千秒没有成功。运维人员加了一个索引,又加了一个索引,后面又执行了一个加字段的动作通过admin show ddl的命令看到了最早的加索引命令。(后面的都被堵塞着,没机会执行,也就是推断DDL这个是串行动作)在执行admin show ddl jobs命令看到历史上最新的10个命令以及现在最新的状态。实在不理解为什么这个加索引会卡主而加字段顺利通过只能说加