OceanBase
负载均衡策略
基本概念
zone
observer
分区副本
资源分配
租户
数据隔离
创建租户
多副本一致性协议
paxos协议
自动选举主副本
自动负载均衡 自动打散到多台机器
通过redo同步数据
RootService总控服务（RS） 资源分配及调度：分区及副本管理、动态负载均衡、扩容/缩容等。
扩、缩容
集群
租户
异地多活 结合业务特点设置Primary_zone
内存管理
系统架构
内存
提速
专业术语：MemTable
存储
持久化
log
data
专业术语：SSTable
内存管理机制
双索引结构：B+树索引以及哈希索引
B+树索引能够更好地支持范围查找
哈希索引是针对单行查找的一种优化。
Undo流程
存放历史事务数据
MemTable在内存中维护了历史版本的事务，历史每一行将事务针对该行的操作按照时间顺序组织成行操作链，新事务提交时
会往行操作链尾部追加新的行操作。
管理历史事务数据
如果行操作链保存的历史事务过多，将影响读取性能，此时需要触发compaction操作，融合这些历史事务以
生成新的行操作链。
如：某一行有3个行操作:{(c1, 1), (c2, ‘a’)}，{(c1, 2), (c3, true)} 以 及 {(c1, 3), (c2,
“b”)}，那么，融合后新的行操作链只有1个行操作 :{(c1, 3), (c2, “b”), (c3, true)}。
Compaction操作并不会删除老的行操作链，新的行操作链还会有一个反向指针指向老的行操作链。
需要对其进行压缩和垃圾回收，目前的策略是，读操作时，当链表的长度大于18时，写操作时，当链表的长度大于6时会触
发。
读取历史事务数据
如果要读取更老的历史快照，只需要顺着内存中的反向指针往前回溯即可，相当于在内存中执行数据库Undo操作。
读操作会有一个snapshot version，只能读取小于该版本的数据，而且是小于该版本的最大版本。
内存结构
一个集群由多个zone构成，而一个zone中又有多个observer构成。
一个集群的内存也就是所有observer的内存的总和。
observer内存
参数：
memory_limit_percentage
memory_limit（优先级高）
sys 500共享内存
参数：
system_memory
系统内部内存
system(sys 500)
租户总内存
大小：observer内存-共享内存
sys租户
非sys租户（业务租户）
每个租户内存
MemStore
参数：
memstore_limit_percentage
不可动态伸缩的内存
作用：保存DML产生的增量数据
默认值为50，即占用租户内存的50%。
KVCache
SSTable的热数据，提高查询速度
大小可动态伸缩，会被其它各种Cache挤占。
https://www.oceanbase.com/docs/oceanbase-database/oceanbase-database/V2.2.30/memory-
management-within-a-tenant
总结梳理
问题
ERROR 4030 (HY000): OB-4030:Over tenant memory limits
判断MemStore是否超过上限
gv$memstore
查看TOTAL_GB是否已经达到MEM_LIMIT_GB，即已经将
MemStore全部写满。
如MemStore内存未超限，判断是MemStore之外的哪个module占用内存空间最
高
内存模块超限的判断标准：__all_virtual_memory_info的sum(hold) > 租户
min_memory - 租户memstore
除去MemStore和KVCache，查看使用超过一定大小（比如10GB）的内存模块 内存持续在涨，可能有内存泄漏
500租户内存超限
500租户的内存使用量没有被v$memory和gv$memory统计，需要单独查询__all_virtual_memory_info表
判断标准：sum(hold)>system_memory
allocate memory报错 通常是达到内存上限或系统内存耗尽
常见内存问题：https://www.oceanbase.com/docs/oceanbase-database/oceanbase-database/V2.2.77/common-memory-problems
租户内存超限异常处理：https://www.oceanbase.com/docs/oceanbase-database/oceanbase-database/V2.2.77/tenant-memory-limit-exceeding-
exception-handling
数据字典
v$memstore
__all_virtual_memory_info
操作系统内存
存储管理
LSM Tree 技术
LSM Tree（The Log-Structured Merge-Tree）简介
数据更新先记录在MemStore中的MemTable里，然后再
合并（Merge）到底层的SSTable里；
SSTable和MemTable之间可以有多级中间数据且也
按“key-value”有序存储
按照“key-value”有序存储在SSTABLE
SSTABLE
按主键或隐含列（不可见）
以2M的宏块(Macro block)来存储，每个宏块又分为多个微块（Micro block)，
IO最小单位是微块。避免读放大
宏块可以合并和分裂。
合并
最简单的LSM Tree只有C0层（MemTable）和C1层（SSTable）。
通过Major Freeze实现大版本的合并。由于在合并的过程中为了保证数据的一致性，就需要在合并
的过程中暂停正在被合并的数据上的事务，这对性能来说是会有影响的，OceanBase对合并操作进
行了细化，分为增量合并，轮转合并和全量合并。
转储
解决问题：
为了解决2层LSM Tree合并时引发的问题（资源消耗大，内存释放速度慢等），引
入了“转储”机制：
将MemTable数据做小版本冻结（Minor Freeze）后写到磁盘上单独的转储文件
里，不与SSTable数据做合并；
数据被分为基线数据（SSTable）和增量数据（MemTable）两部分，基线数据被保存在磁盘中，当需要读取的时候会被
加载到数据库的缓存中，当数据被不断插入（或者修改时）在内存中缓存增量数据，当增量数据达到一定阈值时，就把增
量数据刷新到磁盘上，当磁盘上的增量数据达到一定阈值时再把磁盘上的增量数据和基线数据进行合并
和传统数据库比较
OceanBase是一个准内存数据库的架构，存储又采用LSM Tree的架构，可以有效解决随机写和写放大的问题。
读写分离，把传统数据库的多频次的、每次都是小数据量的check point变成不频繁的、每次都是大数据量的check point。
合并策略
OB合并触发方式
定时合并 （自动合并） alter system set major_freeze_duty_time='02:00'
MemStore使用率达到阈值自动合并（自动合并）
当租户的 MemStore内存使用率达到freeze_trigger_percentage参
数的值， 并且转储的次数已经达到了
major_compact_trigger/minor_freeze_times参数的值，会自动触
发合并：
通过查询(g)v$memstore视图来查看各租户的memstore内存使用情
况。
可以修改以下参数的值来影响触发合并的时机：
alter system set freeze_trigger_percentage = 40;
alter system set major_compact_trigger = 100；
手动合并
可以在"root@sys"用户下，通过以下命令发起手动合并（忽略当前
MemStore的使用率）：
alter system major freeze；
合并发起以后，可以在"oceanbase"数据库里用以下命令查看合并状态：
select * from __all_zone; 或者 select * from __all_zone where name
= 'merge_status';
轮转合并
作用 由于正在合并的ZONE上没有Leader，避免了合并对在线服务带来的性能影响。
开关 通过参数enable_merge_by_turn开启或者关闭轮转合并。
合并方式
以ZONE为单位轮转合并，只有一个ZONE合并完成后才开始下一个ZONE的合并；合并整体
时间变长。
某一个ZONE的合并开始之前，会将这个ZONE上的Leader服务切换到其它ZONE；切换动作
对长事务有影响。
OB 每日合并策略
重要参数：
可通过以下参数控制每日合并的策略：
enable_manual_merge: 是否开启手动合并（默认值False）；（禁用自动合并）
enable_merge_by_turn: 是否开启自动轮转合并（默认值True）；
zone_merge_order: 指定自动轮转合并的合并顺序（默认值NULL）；
解释：
手动合并：通过alter system的命令指定zone开始合并；
自动非轮转合并：所有zone一起进行合并；不做切主操作，不受合并并发度的限制；
自动智能轮转合并：RS按照一定策略依次调度起每个zone开始合并，直到所有zone都
合并完成；
自动指定顺序的轮转合并：用户指定合并的顺序，RS根据这个顺序依次调度起zone进
行合并；
zone_merge_concurrency： 每日合并的并发度；
合并超时及空间警告
zone_merge_timeout定义超时阈值；默认值为'3h'（3个小时）
data_disk_usage_limit_percentage定义数据盘空间使用阈值，默认值90
合并控制
合并线程数 merge_thread_count
SSTable中保留的数据合并版本个数 max_kept_major_version_number控制，默认值为2
合并状态查看
__all_rootservice_event_history表
__all_zone表
转储策略
转储
解决问题
为了解决合并操作引发的一系列问题资源消耗高，对在线业务性能影响较大。
单个租户MemStore使用率高会触发集群级合并，其它租户成为受害者。
合并耗时长，MemStore内存释放不及时，容易造成MemStore满而数据写入失败的情况。
转储的副作用
数据层级增多，查询链路变长，查询性能下降。
冗余数据增多，占用更多磁盘空间。
租户级，不影响其它租户
参数
major_compact_trigger /minor_freeze_times 控制两次合并之间的转储次数，达到此次数则自动触发合并（Major Freeze）。
minor_merge_concurrency 并发做转储的分区个数；单个分区暂时不支持拆分转储，分区表可加快速度。
适用场景
批处理、大量数据导入等场景，写MemStore的速度很快，需要MemStore内存尽快释放。
业务峰值交易量大，写入MemStore的数据很多，但又不想在峰值时段触发合并（Major
Freeze），希望能将合并延后
手动触发转储
ALTER SYSTEM MINOR FREEZE
[{TENANT[=] (‘tt1' [, 'tt2'...]) | PARTITION_ID [=] 'partidx%partcount@tableid‘}]
[SERVER [=] ('ip:port' [, 'ip:port'...])];
可以通过命令为指定租户、指定observer、指定分区做转储。只和上一次转储的数据做合
并，不和SSTable的数据做合并。
查看转储的记录
MemStore使用率达到freeze_trigger_percentage而触发的租户级转储，在__all_server_event_history表中查询：
手工发起的转储，在__all_rootservice_event_history表中可以查到具体的选项：
SQL引擎高级技术
sql请求执行流程
传统数据库
parse
语法解析
语义解析
execute
fetch
OB
parse 语法解析
快速参数化
plan cache
resolver 语义解析
transformer
逻辑改写
基于规则+代价
Optimizer 优化器
Code Generator 代码生成器
executor 执行器
DML
语句的类型
insert
delete
update
merge
一致性校验
约束检查
类型转换 column_convert
锁管理
只有行锁
不支持脏读
DDL
RS执行
自动完成全局统一的schema变更，无需用户在多节点间做schema一致性检查。
无表锁
transformer：查询改写
sql优化总体思路
单表访问 主要调整索引
多表访问 连接顺序
基于规刚
基于代价 只有or展开
执行计划
本地，远程，分布式
Explain不会真正执行给定的SQL
实时执行计划
(g)v$plan_cache_plan_stat虚拟表查询到plan_id
(g)v$plan_cache_plan_explain 查询时必须指定ip、port、tenant_id、plan_id这四列的值
plan cache：执行计划缓存
plan cache 避免SQL硬解析
淘汰机制
自动淘汰
plan_cache_evict_interval（parameter）：检查执行计划是否需要淘汰的间隔时间。
ob_plan_cache_percentage（variable）：计划缓存可使用内存占租户内存的百分比
（最多可使用内存为：租户内存上限 * ob_plan_cache_percentage/100）。
ob_plan_cache_evict_high_percentage （variable） ：计划缓存使用率（百分比）达
到多少时，触发计划缓存的淘汰。
ob_plan_cache_evict_low_percentage （variable） ：计划缓存使用率（百分比）达
到多少时，停止计划缓存的淘汰。
手动淘汰
alter system flush plan cache;
支持按租户、server删除计划缓存，或者全部删除缓存：
alter system flush plan cache [tenant_list] [global]；
执行计划缓存的刷新 执行计划因各种原因失效
SQL中涉及的表的SCHEMA进行变更
SQL中涉及的表的统计信息被更新时
使用控制
系统变量控制 ob_enable_plan_cache
Hint控制
SQL调优
SQL调优方法
体系结构
内存
存储
数据访问的层级问题
删除标记不只在内存中会有在转储，SSTable中依然会有此问题
当合并之后，查询效率会比较高
分布式架构 多表访问或数据切主，都可能导致远程计划或分布式执行计划
物理设计
传统数据库：对不同的表空间设置不同的存储格式
OB中主要是/DATA/1这块盘
逻辑对象
单表
create table，其实也是做分区的，为自动分区，只不过对于用户来说已
经屏蔽掉。不能和应用特征结合。
分布式并行：主要在OLAP中，而不是在OLTP。因为OLTP中并发度
非常高。希望让一条SQL占用大多资源。将一条SQL的任务拆成多
个子任务并行执行。
索引
多表
索引
连接
分区
目的和传统数据库类似的
和业务特征结合起来
分布式带来的特性
多机扩展，把多台机器利用起来
单机上分区数建议不超过3万，考虑到PAXOS组同步副本状态。
注意不同模式，兼容语法就和哪个模式一样
一级分区
key与hash分区是在mysql租户里特有的。Oracle中没有这个区别。
range分区 目前只有range分区可以任意删除。
注：一般一级分区不会太复杂，因为不好add/drop。
二级分区用于查询条件比较多场景。一级分区最主要的作用是用于维护，add/drop分区。所以一般是把
常用的需求加到二级分区中。
索引
传统数据库ORACLE中索引的实现方式：Btree索引，存放rowid
主表与二级索引（索引表）
主表 也是个索引组织的表，key为主键或隐藏列
二级索引
特点：包含rowkey（主键字段或隐藏列）
为什么要回到rowkey所在的主表？ 因为没有rowid，定位位置
为什么OB中不使用rowid？ 因为总是要合并位置总是会发生变化
意味着扫描两个索引
索引表 把索引当成对象来看，称为索引表
优化方面
路径选择
get: 等值
scan 范围扫描
示例：t2上创建索引t2_c2，并且c1为主表的主键列
select c2 from t2
select c2 ,c1 from t2
order by c1
优化器
剪枝
规则
代价
连接顺序 左深树：有一定的搜索空间，并发不是很高
创建高效索引
建索引过程中是不锁表的，只是命令本身的会话被堵塞住，其它会话是不会被堵塞的。
创建索引
等值 查询时条件中只要包含前导列，无关顺序都可以使用索引 （ABC) where B= and C不能使用索引，因为索引结构中的顺序无法使用
范围
A> AND B> AND C<
只能走A的索引，所以在索引扫描范围上一样
B与C可以减少回表的条数
局部索引与全局索引
基本概念 主表，主键，索引表
局部索引：本地索引 每个索引只能看到自己分区的数据，每个分区互不知道
全局索引
对于索引来说看到的是所有分区的数据
索引的数据和分区的数据是分别独立的
全局索引也是可以分区的，这里主要看业务：如索引分区中利用身份号来分
区，而分区表利用用户id，所以索引的分区规则和用户的分区规则不一样。
所以会有数据的交叉。
分布式挑战
全局索引的挑战：表很大所以分区，表大意味着索引也很大，如果表分成8个
分区，索引没有分区的话就会太大，所以索引最好也分区，但是全局分区索引
与表分区数据有可能分布到不同的机器上，要保证全局的数据一致性问题。
MVCC
局部索引的缺点
无法保证全局唯一性，是针对本地分区的，只能保障这个分区的唯一性，无法保
障全局的唯一性。
如果不加分区键的查询，需要查询所有的分区，查询是比较消耗性能的
能不能创建本地唯一的索引？加上分区键
全局索引 是能够保证唯一性的
Hint
mysql中-c是使用注释，hint其实就是注释
parallel是和ORACLE里兼容的。
Oracle中hint中可能会生效，可能不生效。但是在OB中是一定会生效的。
如果OB中hint语法对，就会生效。可以通过EXPAIN校验有没有hint的信息，如
果没有就是语法写错了。
https://www.oceanbase.com/docs/oceanbase-database/oceanbase-
database/V3.2.1/hint-overview
SQL性能监控
sql_audit
OB写的每一条SQL都会写到SQL_AUDIT中，只在内存中写，没有redo,不落
盘。只是一块内存。内存的大小是固定的。如果满了，会从头覆盖写。
开关
sql_audit
alter system set enable_sql_audit = true/false;
内存大小
sql_audit 内存上限。默认内存上限为3G
alter system set sql_audit_memory_limit = '3G';
sql trace需要在执行SQL之前打开，然后执行SQL，再show查看。对应用调优有限。
plan_cache
OB 分布式事务高级技术
全局快照及分布式一致性读
隔离级别
mvcc
传统数据库的实现方式
分布式面临的挑战
解决方案
硬件
GPS
原子钟
服务
GTS
经过实测，单个GTS服务能够在1秒钟内响应2百万次申请时间戳（即版本号）的
请求，因此只要租户内的QPS不超过2百万，就不会遇到GTS的性能瓶颈，实际业
务则很难触及这个上限
集群中的每一个“租户”都有一个单独的GTS服务。这样做不但使GTS服务的管
理更加灵活（以租户为单位），而且也将集群内的版本号请求分流到了多个GTS
服务中，大大减少了因单点服务导致性能瓶颈的可能。
比如网络抖动了10秒钟，会不会影响版本号的全局一致性，并进而影响外部一致
性
C I:事务的一致性与隔离性
A：事务的原子性
两阶段提交
协调者不写日志，变成了一个无持久化状态的状态机
事务的状态由参与者的持久化状态决定
所有参与者都prepare成功即认为事务进入提交状态，立即返回客户端commit
每个参与者都需要持久化参与者列表，方便异常恢复时构建协调者状态机，推进事务状态
参与者增加clear阶段，标记事务状态机是否终止
参与者宕机
协调者宕机
OBProxy
简介
应用
一个OBProxy来接受来自应用的请求，并转发给OBServer，然后OBServer
将数据返回给OBProxy，OBProxy将数据转发给应用客户端
作为OceanBase的高性能且易于运维的反向代理服务器，具有防连接闪断、
OBServer宕机或升级不影响客户端正常请求、兼容所有MySQL客户端、支
持热升级和多集群功能
核心功能（路由）
简单SqlParser
轻量的sql解析，判断出客户端的sql请求所涉及的表的主副本在
哪台机器上，将请求路由至主副本所在的机器上
LDC路由
主要对于读写分离的场景，根据observer和obproxy配置的region
（区域）和LDC（逻辑机房），将请求发送给本地的副本
读写分离部署
对于读写分离的场景，OBProxy会把请求优先发送到本地的只读
副本
黑名单
OBProxy在路由过程中，如果发现OBServer不可用，则把该server加入
到黑名单
核心功能（连接管理）
在observer宕机/升级/重启时，客户端与OBProxy的连接不会断开，OBProxy可以迅速切换
到正常的server上，对应用透明
OBProxy支持用户通过同一个OBProxy访问多个OceanBase集群
Server session对于每个client session独占
同一个client session对应server session状态保持相同(session变量同步)
OBProxy与OB集群（OBServer）保持长连接，客户端一般通过连接池的方式连接到OBProxy
部署方式
集中部署
Obproxy集中部署的方式主要用于外部上云，方便外部用户使用Mysql协议访问OceanBase。外部用户
使用的Mysql客户端种类繁多，Obproxy需要解决可能遇到的各种Mysql兼容问题。
多个Obproxy进程之间不需要通讯，单个Obproxy无状态，即使宕机重启也不会导致数据一致性问题，
所以Obproxy实现平滑热升级和宕机快速重启便可以基本满足HA的需求。
客户端部署
将Obproxy作为客户端部署在应用的虚拟机上
好处：
可以减少一次网络开销，能节省0.2ms~1ms的响应延时。Obproxy转
发request/response时内部总耗时大约30us左右
管理：
通过OCP管理
Obproxy周期性向OCP汇报状态和统计信息，OCP实时监控各个Obproxy的运行状态，通过OCP可以对Obproxy进
行批量热升级和配置更新。同时在应用的虚拟机上部署了一个守护进程，如果发现Obproxy宕机，会立即重启
Obproxy，尽量减少由于Obproxy宕机导致的服务不可用时间。
两种启动模式
测试模式 无需依赖 ConfigServer
生产模式
依赖 ConfigServer
ConfigServer是OCP平台提供的OB集群物理入口管理服务
OB集群的RSList信息，使obproxy能为多个OB集群同时提供服务
访问集群方式
通过proxy访问OceanBase服务时， 还需要指定集群名, 格式有四种：
username@tenantname#clustername, 如root@trade#xxbank
clustername:tenantname:username, 如xxbank:trade:root
clustername-tenantname-username, 如xxbank-trade-root
clustername.tenantname.username, 如xxbank.trade.root
路由策略
LDC
Region：地域信息，通常代表一个城市，包含一个或多个IDC，每个IDC部署一个或多个
zone。一个OB集群可以包含若干个Region，每个Region包含若干个IDC，每个IDC部署
若干个zone
proxy中的idc要和OBServer的idc对应，而且在扩容时，要注意安装时的region要一样，后
续安装完之后可以改。Zone对应region的指定。
配置
集群
OBProxy
主要路由策略
强一致性读 写主
弱一致性读
策略
主备均衡路由策略（默认） 按照:本地常态 -> 同城常态 -> 本地合并 -> 同城合并 -> 异地常态 -->异地合并
备优先读策略
读写分离策略
配置
系统变量
hint
使用限制
使用与运维
启动
ObProxy无状态，即使宕机重启也不会导致数据一致性，所以ObProxy在部署时都带有一个
守护进程，周期性检查Obproxy的健康程度，一旦发现宕机就立即重启ObProxy
配置项
修改
登陆到每台proxy机器上修改
alter proxyconfig
查看 show proxyconfig like '';
前两种配置信息会在本地生产一个配置文件，默认保存在proxy运行目录的etc目录下，文件名为
obproxy_config.bin，第三种配置信息仅保存在proxy内存中。
如果用户使用alter proxyconfig内部命令,则会更新本地配置文件obproxy_config.bin
参数
xflush日志主要是给监控统计信息, syslog是OBProxy自身运行信息
observer_query_timeout_delta：关系到网络断开连接，到认为Observer不可用的delta时间
可以举例：网络不可用的时候，OB多久自动切主
log_cleanup_interval：清理OBProxy自身应用日志的间隔时间
运维与监控
用户权限
用户分类
系统租户
一般租户
用户操作
创建，删除，修改，授权，撤销权限等
查看用户：show grants for username
用户格式
obproxy时要使用完整的格式，加上集群名，因为obproxy是可以连接多个集群的。
2881：不需要指定集群名，因为已经连接到特定集群了
2882：observer内部通信
2883：需要指定集群名，因为obproxy是可以连接多个集群的。
权限
等级管理
全局级别
适用于所有的数据库。使用
GRANT ALL ON *.*授予全局权限。
库级别
适用于一个给定数据库中的所有目标。使用GRANT ALL ON db_name.*授予数
据库权限
表级别
表权限适用于一个给定表中的所有列。使用GRANT ALL ON
db_name.tbl_name授予表权限
角色 权限的集合
日志查询
Observer日志
/home/admin/oceanbase/log
了解OceanBase的启动和运行状态
observer机器本身的
rs的
election选举日志，如果有宕掉的，需要选举的时候才会用。
有一堆，也就是归档了的
observer日志清理
enable_syslog_recycle
max_syslog_file_count
syslog_io_bandwidth_limit日志限流不建议调整。不建议调大，会影响性能。代码中输出多少日志。相
当于传统数据库中开trace，打印非常多的信息。但是目前OB的日志中已经是为示足够的信息了。
事务/存储日志
/data/log1/集群名
Clog
类似于redo，需要持久化的信息全部记录
基本和业务量成正比（查询除外）
由/data/log1这块盘的大小决定clog占用的大小。一般认
为自己独占
传统数据库一般会定义文件个数和大小
clog会大于数据，因为有头尾的信息，事务信息。
clog不能随意删，但是因为空间循环使用，所以可以删除一些老的。
ilog
记录着分区相关的索引信息
根据log_id来辅助快速扫描clog
不会很大
slog
类似于ilog记录一些管理，操作类信息
不会很大
https://www.modb.pro/db/125989
日志级别
查看 show parameters like 'syslog_level'
修改 alter system set
error：OB中是严重错误，一般是已经出现故障
warn: 几乎用户看到的报错看warn.大部分的报错都是看这个
格式：Y0-0为trace_id
.wf记录的是warning以上的，很少，也很小
observer.log.20161230230235020为日志切换时间，根据时间要会判断找哪个日志
4000以内的直接看MYSQL的错误代码及可。
日常运维
时钟同步
集群内的时钟偏差为100ms，越小越好
如果时钟偏差不是很小集群会出问题
zone
基本内容
__all_zone
ALTER SYSTEM {START|STOP|FORCE STOP} ZONE [Zone_Name];
leader服务stop
leader服务start
observer
基本内容
ip:port
__all_server | __all_server_event_history
__all_server以server级别记录转储信息。手工触发的转
储不会存在这里，这里需要rs调度所以记录在RS中。
如果是合并，那么是rootservice的数据字典
alter system start | stop server ‘192.168.100.1:2882’
leader服务stop
leader服务start
操作系统进程的启、停
避免补副本，将offline时间设置长一点
自动恢复之后，不需要设置，自动加入集群。
再次启动之后需要做类似传统数据库的crash恢复
容量不足
内存
存储
数据库监控
gv$与all_virtual
gv$视图是抽象出来的，可以在业务租户下查看
all_virtual表是用的最多的，只能在sys下查看
assigned：表示已分配的资源很多OB中只有cpu和内存两个资源是有意义的。
all_virtual_memory_info来看memstore,kvcache以外的模块
gv$memstore:主要目的看active与total的比，关注什么时候会触发合并
__all_virtual_disk_stat:total为存储总空间，free的为空闲的。
__all_virtual_meta_table主要记录每个对象（分区）的信息。每个对象包括主分
区，副本分区。负载均衡信息可以在这张表中查看。可以统计所有对象在每台机
器中的空间占用。只是sstable的数据不含memtable.
底层表__all_virtual_sql_audit对应视图gv$sql_audit：只是一段内存，不做底层持
久化。能够记录在OB中操作的每条SQL。svr_ip代表的是scheduler,也就是发起
SQL的机器。
outline部分注意加-C选项。
常见异常处理
灾难恢复
truncate:相当于drop,create表的id会变，这样plan cache中的执行计划失败
业务租户来执行purge recyclebin
闪回查询能不能看到数据也和undo_retention有关系，不建议设置特别大
作 者 ： @ 梦 尘 君 | 来 自 ： 知 犀 思 维 导 图
of 1
25墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
1
2
Vastbase数据库管理v2.2build15.pdf
3
清华大学第八弹：文科生零基础AI编程：快速提升想象力和实操能力.pdf
4
利用Docker来运行MySQLv2.pdf
5
（浙江大学）DeepSeek：智能时代的全面到来和人机协作的新常态.pdf
6
达梦数据库 DM8数据守护集群安装部署_手动切换.pdf
7
达梦数据库DM8读写分离集群安装部署_手动切换.pdf
8
控制器-replicaset.docx
9
Packt Publishing PostgreSQL Server Programming 2nd (2020).pdf
10
redis安装和配置方法.docx
文档被以下合辑收录
相关文档
评论