ANBOB™

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:

OceanBase Database也同oracle一样支持partition table，但存在一些注意事项，甚至和oracle存在一些差异。分布式数据库的数据打散方式并不相同， 分布数据基于组规则到不同的物理区，在Oceanbase中以 Partition粒度分布到不同的OB SERVER节点，Oracle mode 的OceanBase Database可以创建65536个分区partition，也可以创建subpartition, Table的分区列又叫分区键( partitioning key), 分区键必须是PK和UK的子集或者是说主键唯一键必须包含分区键。

在数据库中分析系统中的锁等待非常重要， 在oracle中有大量的脚本，在Postgresql中也需要积累一些工具， 可以快速分析锁等待， 这里推荐几个好用的脚本。

Oracle dataguard redo传输网络带宽不足通常如standby同步时延增加，数据库层还会有哪些表现吗？当standby 同步延时较大故障时， 故障排除最重要的阶段是正确识别问题的性质，例如能够判断问题是否与网络本身、DataGuard、Oracle 数据库（主数据库或备用数据库）或其他数据库有关。尽管 Oracle 提供了非常强大的工具，但这并不是一件容易的事。

在oracle RAC 环境中节点的信息配置文件有些记录在gpnp profile，如asm_diskstring, 当修改其中的参数时需要在节点间同步，在root.sh时也需要校验，CSS守护进程在启动期间使用GPNP profile来发现 voting files(参数“DiscoveryString”)。发现字符串的不正确值将阻止CSS守护进程(最终阻止整个CRS堆栈)启动。相关的服务有gpnp.bin\mdns.bin。 如果因为一些原因无法push到远程节点时会提示如下错误，
ORA-29783:GPnP Attribute SET Failed With Error [CLSGPNP_NOT_FOUND]

在oracle中A库直接远程访问B库常见的有dblink, 在postgresql中有postgres_fdw和外部表，在opengauss系中同样有postgres_fdw、oracle_fdw(for Oracle)、mysql_fdw(for MySQL)， 在EDB中postgres_fdw、oci_dblink(for Oracle)。但是发现对于opengauss到远程 opengauss的使用dblink访问时(有oracle应用迁移而来)， 在oracle中常用的select * from t1@dblink1访问时，提示 remote table ‘t1’ does not exist, 即使创建user mapping时使用的t1表schema用户。如果应用中存在原oracle语法需要调整，影响postgresql和opengauss, 简单记录opengauss中的问题。

Oracle Active Data Guard 是 Data Guard 框架中的一个选项，允许在从主数据库对物理备用数据库应用更改时以只读方式打开该数据库。Oracle Data Guard在某些情况下可能无法使用Active Data Guard（ADG）特性。最近一个客户oracle 11g dataguard在open read only 然后再启用mrp应用日志变更时数据库自动变为mount状态，说明ADG功能无法使用，db alert中并无任何报错，这里也整理几个ADG无法使用的情况

最近在跟客户沟通时，发现有些数据库厂家对外宣称，具备从oracle数据库迁移到目标国产库时，从源库到目标异构数据库真实负载重演能力，于是花了点时间研究一下，该功能原本在Oracle叫做ORACLE REAL APPLICATION TESTING （RAT）或其中的子Database replay, 相比另一功能SPA,是能重演生产库的真实业务到测试环境，国产库厂家是怎么做的呢？是真的可以RAT? 有没有什么风险呢？ 这里简单描述。

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 11.2.0.1 环境从 Windows 平台迁移到 Oracle 11.2.0.4 RAC on Linux 平台。当前数据库大小为 3TB，基于数据量和停机时间的考虑，因为 Windows 和 Linux x86 同为小字节序，并且 Oracle 支持这两个异构平台之间的 Data Guard（Physical Standby），我们最终决定采用 Oracle Data Guard 的方案。在此过程中，需要注意的是由于数据字典是从原单实例同步的，可能会忽视当前 RAC 库缺少 RAC 组件的问题。此外，还需确认时区是否需要进行升级。

在业务租户内存结构中有个内存区叫做memstore, 主要用于保存数据库增量数据,对应MemTable属性，众所周知OB是基于LSM-tree存储引擎，数据分为磁盘上的静态数据（SSTable）、内存的增量数据（MEMTable）、以及记录事务的日志. 内存中的数据需要制定一些策略，控制从内存刷到磁盘，如同oracle的checkpoint, 在OB中叫做转储, 转储可能会产生I/O的较大影响，当然不希望业务高峰期做转储操作，这样就需要对MEMSTOR使用做监控

oracle 11.2.0.4 RAC 安装在OEL7没想到还能出这么多问题，几年前做过总结《RHEL7（Linux7）安装Oracle 11g R2(11.2.0.4) RAC 问题小结》，这次使用的是某软件的自动化安装部署，遇到了新的问题，root.sh时oc4j无法启动，虽然大部分情况该资源并不影响数据库的使用，甚至应对某些安全扫描的风险端口还需要停掉该服务，但这里是希望找到报错原因，使用crsctl stat res -t查看资源状态ora.oc4j ONLINE OFFLINE STARTING 状态

在PostgreSQL数据库中，与硬件基础环境依赖相关的参数，默认配置通常不适合生产环境。正如 PostgreSQL wiki 页面所述，默认配置的选择是为了在各种可能缺乏大量资源的设备上更容易地安装数据库。Oracle数据库也存在类似的问题，因此在内存相关的参数上基于Advisor框架推出了ASMM和AMM自动管理，但大部分参数如优化器相关的，仍然是针对通用场景设计的。当然，也有大量的Oracle DBA基于自己的经验整理出了一些最佳实践参数。相较之下，PostgreSQL的参数数量远少于Oracle。下面整理了几个基础的数据库调优参数。

在早期接触 Oracle 12c 的生产环境时，我在数据库警告日志（db alert log）中发现了“WARNING: too many parse errors, count=NNNNN SQL hash=0x****”的警告信息。Oracle 通过这种方式提示我们，应用中有一些解析失败的无效 SQL 正在耗费系统资源。Oracle 建议根据这些 SQL 文本和错误信息来修正 SQL。然而，某些应用或 DBA 可能会对这些警告视而不见，尤其是从 12c 前版本升级上来的用户，更是觉得可以安全地忽略这些警告。 几年前，我记录过一个客户在 Oracle 12.2 中遇到的《Oracle 12.2 DB alert show “WARNING: too many parse errors” or “__Oracle_JDBC_internal_ROWID__” in sql》现象。最近，另一个客户也持续遇到解析失败的问题，我发现这绝对不能放任不管，因此做了简单记录。