多租户架构，之前还在做运维的时期接触也不多。遇到多租户问题，第一反应是有些发虚的。 但实际很多问题很简单，也容易解决。本文就是一个例子。 问题：RAC节点2打开所有PDB时，报错ORA-30013。 SQL> alter pluggable database all open; alter plug
之前认为缺失的temp文件在开库时会自动创建，但其实也有不能自动创建的场景，alert会有类似如下提示： 2023-05-11T20:35:35.974983+08:00 AWR(6):*********************************************************
python自产调试工具pdb的使用 介绍 调试打印在写代码的时候不可避免 项目越大，调试可能花的时间会越多 print调试可能是最早用的，一段时间内你都会习惯这种方式 一旦成了老鸟，你应该会去用IDE的debugger，功能非常强大，效率就比print上了一个台阶 当然python像其他语言一样，
# 关于内存配置相关内核参数的再学习 ## 摘要 ``` 上周一台192G内存的跑着重型拆分微服务的服务器宕机了. 服务器上面还有一套30个pdb的Oracle数据库. 实际原因是因为内存耗尽. 导致机器无响应. 控制台没有任何反馈. 没办法的情况下进行了重启操作. 当时没有进行彻查. 今天有同事反
环境： Oracle 19.16 多租户架构 经常会在网上看到有人写exists和in的效率区别，其实在新版本的数据库中，是不存在这个问题的，优化器会自己判断选择最优的执行计划。 为了直观的说明，我在PDB中构造如下测试用例： vi 1.sql select count(*) from v$acti
环境： Oracle 19c ADG（主库：单实例；备库：RAC） 1.主库新建测试文件 2.主库创建测试表 3.查询表对应数据文件信息 4.模拟数据文件物理坏块 5.查询对应测试表 6.进一步查询日志信息 7.确认当前参数设置 1.主库新建测试文件 主库在AWR的PDB中做测试，为了不影响其他测试
回忆起来也是有些年没亲自动手搭建ADG了，今天正好有个机会重温，客户环境是19.16，恍惚记得上一次搭ADG还是在11.2.0.4的时代，时光荏苒啊。 正好看下19c的ADG和11g的ADG在部署方面有啥不同？ 主备库都是RAC架构，数据库是CDB架构，包含有4个PDB，整个搭建过程还是遇到很多小问
技术人当遇到具体问题，能给出的各种解决方案，有一种类型叫做workaround，翻译过来通常为“应变方法”、“变通方法”； 其实这种方式通常是没有找到根本的解决方案，但是为了快速恢复业务而采用的一种巧妙规避/跳过的方式。 举个具体的例子：我有测试需求要在主库创建一个新的PDB： 1.创建新的PDB
