Migrate oracle to openGauss/oceanbase/达梦/kingbase: md5 function
在十年前简单测试过oracle 9i 的加密解密用法之dbms_obfuscation_toolkit(二),其中有md5单向加密, 最近在oracle迁移到opengauss项目中用到了md5, 这里简单记录替换方案,在pg或og中直接就有md5 function. 在mysql及Mysql系的产品和ocenabse, 达梦一样存在该函数md5。
提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
在十年前简单测试过oracle 9i 的加密解密用法之dbms_obfuscation_toolkit(二),其中有md5单向加密, 最近在oracle迁移到opengauss项目中用到了md5, 这里简单记录替换方案,在pg或og中直接就有md5 function. 在mysql及Mysql系的产品和ocenabse, 达梦一样存在该函数md5。
很久以前记录过一篇 Oracle Estimate of the duration of a rollback operation (估算rollback事务回滚剩余时间) ,oracle的大事务cancel或kill后的回滚操作,rollback所花费的时间通常比原来的操作还要长,而且在回滚完成前有可能会堵塞其它事务,在PostgreSQL中因为没有使用undo而是多版本,所以忽略rollback的时间,这是PG的强项,但是在MySQL中和oracle一样同样存在回滚问题,这里简单记录如何估算MySQL中的事务回滚时间。
最近,我注意到一位朋友在处理一个以G字开头的MySQL系国产数据库时遇到了一些问题。具体来说,该数据库占用了超过1TB的临时文件,导致文件系统告警,之前kill session并且未能释放。这是由于在杀掉dbproxy上的session后,db node上的session仍然存在。这样的情况可能是非原生分布式数据库的一个风险点,因为每个data node都是一个独立的MySQL实例。最终,我们通过登录到data node并手动kill session解决了问题。我在另一款国产MySQL系分布式数据库GoldenDB上进行了类似的模拟测试,仅记录处理方法。
在MySQL 5.6或从5.6 升级到8.0后有可能会遇到ERROR 1071 (42000):Specified key was too long; max key length is 767 bytes 报错,提示是遇到了索引KEY的最大上限767 字节。在本文中,我将解释此错误发生的原因以及如何解决它。
上周,Percona 发布了一篇警告博客,提醒用户<不要升级到 MySQL 8.0.37 之后的任何版本>。然而,现在访问 MySQL 官方下载页面,依然可以在主推的下拉列表中看到这些版本。
Percona 在文章中提到,Jean-François Gagné 在 bug.mysql.com 上报告了一个编号为 #115517 的 bug。不幸的是,这个 bug 目前处于私密状态。简而言之,如果您创建大量表(例如 10000 个),MySQL 守护进程在重新启动时会崩溃。当然,也有人认为这是危言耸听,因为单个数据库实例中有超过1万张表的用户可能不足0.0000001%。
Oracle 数据库在在线维护操作方面引入了大量特性,旨在实现日常维护和升级时无需停机。相比之下,MySQL 在这方面的表现稍逊一筹。作为 Oracle 的 DBA 是一件很幸福的事情,因为日常的分区维护、发现性能问题时的紧急创建索引等操作都可以在线完成。而 MySQL 虽然也宣称支持 DDL,但这是真的吗?
我们有一个 GoldenDB 的客户要求以后所有的 DDL 操作只能在停所有业务的情况下执行。对于拥有大量数据库实例且需要频繁进行 DDL 维护的情况,请问你能提供多少停机时间?
数据库存放着组织拥有的最重要的资产之一——数据。保持数据安全和不受破坏是关键任务。对于大多数应用程序来说,停机比数据丢失或损坏更痛苦。DBA的核心职责包括数据库的备份恢复,到了关键时刻非常考验方案的有效性。在MySQL开源数据库也存在一些备份工具,但存在一些差异,备份应根据恢复需求进行规划, 这里简单整理。
The maximum size of large objects (LOBs) in Oracle, PostgreSQL, and MySQL varies depending on the type of LOB and the database system. Here are the details for each database:
MySQL事务隔离级别默认的Repeatable Reade 下有Gap Lock问题,在更低的隔离级别下,如读已提交(Read Committed)或读未提交(Read Uncommitted),Gap Lock不会被使用,在READ-COMMITTED下同样存在类似“Gap Lock”的问题,如果Oracle 数据库向基于MySQL innodb的数据库迁移后,不知是否会出现原有应用经常行锁等待的现象,等待innodb_lock_wait_timeout参数配置的时间后报错, 而oracle lock是在行头(row header)上,MySQL这种导致锁定记录增加的现象,让从事oracle DBA转型的无法理解
前几日一客户问我在oracle执行unix_timestamp函数报错,心想这不是MySQL的函数吗?难道oracle引入了?找了一圈到oracle 23ai也没有自带该函数,可以自定义函数实现, 在去年的一个oracle迁移到PostgreSQL系数据库里,有套业务库大量使用epochs做为datetime,这里简单记录在oracle, mysql ,postgresql中如何做unix epoch到datetime的转换.
最近一客户的应用日志随机会出现一些数据库源访问错误,中间件使用Caucho的连接池,数据库为MySQL 5.7主从,前端有HAproxy, 应用server多个,报错也不是持续性,再次重试可能会就正常,错误日志DataAccessException: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago.
Oracle数据库有dataguard主从,MySQL有主从或MGR,Goldengate同步支持从前两种数据库做数据抽取,但是在主从切换以后需要在Goldengate做相应的修改。这里记录一下MySQL因master 需要停机维护时,OGG主动切换到slave的方法。
事务隔离级别是数据库事务处理的基础,ACID 中的 “I”,即 Isolation,指的就是事务的隔离性。ANSI/ISO SQL 标准定义了4 种事务隔离级别,对于相同的事务,采用不同的隔离级别分别有不同的结果。这些隔离级别是根据3 个“现象”定义的,
之前曾经在《oracle add column xx default value 增强(二)》记录过,在日常运维中增加column是常见的操作,对于大表增加列时是否会导致回写表还是只修改数据字典影响DDL的执行时间和停机窗口长短。之前也在《“alter table ” modify column in Oracle、MySQL、PostGreSQL(数据库比较系列十三)》记录修改column时不同库的表现, 这里简单记录测试一下当前主流的几个库对于add column的现象。
前几天看到有OB用户留言,提到OceanBase很可能是出于对他们需求的考虑,而应用中以前对ORACLE报错的依赖。这表明现在数据库厂家在满足各种甲方要求时也颇为无奈,在应用的兼容性上做了种种让步。就对于会话1事务中,会话2 select for update nowait相同的报错场景,我简单测试一下在其它国产库上是否还不如Oceanbase. 为了方便横向对比,这里我再简单的附上ORACLE 与OB的报错。
在关系数据库中两表关联在oracle中使用IN( subquery)的语法很常见, 但kevin发现在MySQL中subquery使用MAX聚合参数时,会导致主查询Full scan而无法使用索引范围扫描, 当遇到大表时可能性能下降明显 ,测试发现有的库使用子查询做为驱动表,有的是使用filter从主查询过滤。下面简单测试。
在关系数据库中常见的一种需求统计表的记录的最大值或最小值,SQL中使用max min,为了最佳效率通常希望可以在列上创建索引,减少表段的IO量,如果可以可以使用更佳的执行计划如直接访问索引的头和尾(btree index的有序结构),减少index 块的访问,我们对比一下几款数据库在该方面的能力。
国产库在承接Oracle替换方面做了大量的兼容性,如果仅实现了语法兼容,没有相同的语义,这恐怕比不兼容还糟糕,比如原来的oracle的应用迁移到国产库后执行不报错,但却有可能和oracle得到完全不一样的结果。今天我们以万里开源的GreatDB中的sysdate为例, 对最近同事遇到这个案例简单分享。
MySQL架构中经常会遇到和keepalived、HAProxy中间件的组合,解决MySQL的高可用与负载均衡的需求, 但是会给数据库配置带来复杂性。如果没有把这些组件与MySQL级联配置,可能会出现一些意向不到的问题,了解HaProxy就变的重要,近期一个客户在这样的环境做压力测试时,MySQL数据库的max_connections最大链接数已调整到10000, 但一应用反馈链接报错,从数据库上看链接最大也就在2000左右,并且MySQL日志未出现报错,
在企业级运维中,应用程序用户和维护用户通常不建议复用,分别能过权限控制给维护人员修改应用对象的权限, 但是对于存储过程在MySQL中授权相对较麻烦,没有像oracle数据库中的alter any procedure的系统权限。 比如当user1修改user2创建的存储过程时,在DDL中带有“DEFINER=”其他用户时会报错如下:
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or SET_USER_ID privilege(s) for this operation