fix some repos

docs/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/01_emergency_overview.md

@@ -44,7 +44,7 @@ OBServer 的故障排查脑图详见：
 
 这一小节只有手册的内容介绍，没啥干货，有点儿过意不去。那就在最后附送一个 **<font color="red">针对 OceanBase 严重故障（尤其是业务停服场景），进行快速止血恢复的通用方法</font>** ，简单来说就是：切主 -> 隔离 -> 重启 -> 切备集群。
 
-- 如果集群中只有一个租户有问题，那就切这个租户的主（通过 set tenant primary_zone 修改租户的 primary_zone）。
+- 如果集群中只有一个租户有问题，那就切这个租户的主（通过 alter tenant set primary_zone 修改租户的 primary_zone）。
 
 - 如果集群中只有一个节点有问题，那就 stop or isolate 这个节点。
 

docs/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/02_slow_response.md

@@ -99,7 +99,7 @@ weight: 2
 
     2. **<font color="red">multi_level_queue</font>**，表示嵌套请求队列
 
-        - total_size=n，n 表示优先级队列中总共的排队请求数。
+        - total_size=n，n 表示层级队列中总共的排队请求数。
 
         - queue[x]=y，y 表示每个层级子队列中的排队请求数。
 

docs/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/05_network_problem.md

@@ -59,7 +59,7 @@ alter system start server 'xx.xxx.xxx.x:2882';
 - **<font color="red">租户切主，将机房对应的整个 ZONE 进行隔离（[副本隔离](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001573944)）</font>**。
 ```
 -- 租户切主
-ALTER TENANT tenant_name primary_zone='zone1';
+ALTER TENANT tenant_name primary_zone='zone2';
 
 -- 隔离 zone
 ALTER SYSTEM STOP ZONE 'zone1';

docs/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/07_disk_capacity_problem.md

@@ -32,8 +32,8 @@ SELECT b.zone, a.svr_ip, a.svr_port,
         ROUND((a.total_size-a.free_size)/1024/1024/1024,3) used_size_GB,
         ROUND(a.free_size/1024/1024/1024,3) free_size_GB,
         ROUND((a.total_size-a.free_size)/total_size,2)*100 disk_used_percentage
-FROM __all_virtual_disk_stat a
-INNER JOIN __all_server b
+FROM oceanbase.__all_virtual_disk_stat a
+INNER JOIN oceanbase.__all_server b
   ON a.svr_ip=b.svr_ip AND a.svr_port=b.svr_port
 ORDER BY zone
 

docs/user_manual/operation_and_maintenance/zh-CN/operations_and_maintenance/01_version_upgrade_path.md

@@ -24,7 +24,7 @@ weight: 1
 + CE（Community Edition）代表社区版。
 + LTS（Long-Term Support）代表长期支持版，会在这个版本，长期解决稳定性 bug。
 + HF（HotFix）表示只增加了关键 bugfix 的版本，旨在解决个别 “走投无路” 难以绕过的问题。
-+ GA（General Availability）代表稳定版本，是生产环境（即正式使用环境）下安全可靠的，可以广泛部署和用于日常业务操作的版本。在[官网](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001049779)上可以看到 4.3.1 就是一个 GA 版本。
++ GA（General Availability）代表稳定版本，是生产环境（即正式使用环境）下安全可靠的，可以广泛部署和用于日常业务操作的版本。在[官网](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001509391)上可以看到 4.3.1 就是一个 GA 版本。
 
 例如下图中 4.2.1_BP8(LTS) 就表示是 4.2.1 这个版本中进行过 8 次 Bundle Patch 的长期支持版本。
 

docs/user_manual/operation_and_maintenance/zh-CN/operations_and_maintenance/commonly_used_sql/03_tenant_management.md

@@ -468,7 +468,7 @@ FROM
 
 ## 统计租户表数量
 
-查询非 META 租户的表数量：
+查询非 META 租户的表数量（已排除 oceanbase 库和 mysql 库中的一些系统表）：
 
 ```
 SELECT

docs/user_manual/operation_and_maintenance/zh-CN/operations_and_maintenance/commonly_used_sql/04_user_and_privilege_management.md

@@ -124,20 +124,6 @@ ORDER BY
   role;
 ```
 
-## Oracle 模式角色授权情况
-
-```
-SELECT
-  *
-FROM
-  dba_role_privs
-WHERE
-  grantee = 'SYS'
-ORDER BY
-  grantee,
-  granted_role;
-```
-
 ## Oracle 模式系统权限授权情况
 
 ```

docs/user_manual/operation_and_maintenance/zh-CN/operations_and_maintenance/commonly_used_sql/06_merge_management.md

@@ -3,10 +3,10 @@ title: 合并管理
 weight: 6
 ---
 
-`root@sys` 登陆查询，
+本文中在系统租户下查询的内容，均需要通过 `root@sys` 登陆。
 
 ## 系统租户下查询所有租户的合并状态
-
+`root@sys` 登陆查询：
 ```
 SELECT
   tenant_id,
@@ -58,6 +58,7 @@ LIMIT
 ```
 
 ## 查询所有租户的 tablet 转储历史信息
+`root@sys` 登陆查询：
 
 ```
 SELECT
@@ -96,6 +97,7 @@ LIMIT
 
 ## memstore 信息
 
+`root@sys` 登陆查询：
 ```
 SELECT
   /*+ MONITOR_AGENT READ_CONSISTENCY(WEAK) */
@@ -118,6 +120,7 @@ ORDER BY
 
 ## 租户 memstore 信息
 
+`root@sys` 登陆查询：
 ```
 SELECT
   /*+ READ_CONSISTENCY(WEAK),query_timeout(100000000) */
@@ -140,7 +143,7 @@ GROUP BY
 
 ## 查看转储信息
 
-`root@sys` 登陆查询，
+`root@sys` 登陆查询：
 
 ```
 SELECT
@@ -157,7 +160,7 @@ LIMIT
 
 ## 查看每日合并耗时
 
-`root@sys` 登陆查询，
+`root@sys` 登陆查询：
 
 ```
 SELECT

docs/user_manual/operation_and_maintenance/zh-CN/operations_and_maintenance/commonly_used_sql/09_ocp_monitor_ob.md

@@ -1869,54 +1869,6 @@ ORDER BY
   a.svr_port;
 ```
 
-以下为视图查询，但性能较差，
-
-```
-SELECT
-  /*+ READ_CONSISTENCY(WEAK) QUERY_TIMEOUT(50000000) */
-  a.tenant_id,
-  a.svr_ip,
-  a.svr_port,
-  c.object_type,
-  round(SUM(data_size) / 1024 / 1024) AS data_size_mb,
-  round(SUM(required_size) / 1024 / 1024) AS required_size_mb
-FROM
-  cdb_ob_table_locations a
-  JOIN (
-    SELECT
-      tenant_id,
-      tablet_id,
-      svr_ip,
-      svr_port,
-      data_size,
-      required_size
-    FROM
-      cdb_ob_tablet_replicas
-  ) b ON a.tenant_id = b.tenant_id
-   AND a.tenant_id = 1012
---   AND a.database_name = 'ALVIN'
-  AND a.tablet_id = b.tablet_id
-  AND a.svr_ip = b.svr_ip
-  AND a.svr_port = b.svr_port
-  JOIN cdb_objects c ON a.tenant_id = c.con_id
-  AND a.table_id = c.object_id
-  AND c.object_type = 'TABLE'
---   AND c.object_name = 'test'
-GROUP BY
-  a.tenant_id,
-  a.svr_ip,
-  a.svr_port,
-  c.object_type
-ORDER BY
-  a.tenant_id,
-  a.svr_ip,
-  a.svr_port;
-```
-
-目前 内核提供的最准确的内部表是 `__all_virtual_tablet_sstable_macro_info` 。这张表详细的记录了细到分区(tablet) 对应的每个宏块的信息。OCP 倒是可以根据宏块的 idx 去重后得到准确的统计信息（4.x 即使是这张表也没办法去掉小 sstable 的重复） 421 即采用上述方式进行统计。但该表在数据量很大的时候记录非常多，OCP 全量的查询会有性能问题。考虑尝试过滤 svr 查询会极大提升查询性能，但是4.x 的 OB 这张表不在内存中了，而是走磁盘扫描，部分情况会将硬盘 IO 打满，造成稳定性问题。
-
-详见相关 git [PR](https://code.alipay.com/oceanbase-cloud-platform/ocp-all-in-one/pull_requests/10663?tab=diff)。
-
 ```
 SELECT
   a.tenant_id,

docs/user_manual/operation_and_maintenance/zh-CN/operations_and_maintenance/optimizer_statistics/01_operations_and_maintenance.md

@@ -221,7 +221,7 @@ call dbms_stats.gather_table_stats('database_name','table_name', no_invalidate=>
 
 + **步骤四：如果当前租户已经长时间出现大表收集卡住的问题，可以通过 [“快速获取当前租户中统计信息过期或者统计信息缺失的表”](#快速获取当前租户中统计信息过期或者统计信息缺失的表) 中的方式查询当前租户中是否已经存在大量表统计信息缺失或者过期的问题，如果存在则需要在<font color="red">业务低峰期</font>手动重新收集相关表的统计信息（参考《手动统计信息收集命令使用手册》 ）。**
 
-+ **步骤五：以上步骤完成之后，最后一步可以考虑调整自动统计信息收集发起任务的时间，<font color="red">尽量错开业务的高峰期，放到每日合并之后进行</font>。调整自动收集任务时间参考：[调整自动统计信息收集的调度时间](#调整自动统计信息收集的调度时间)**
++ **步骤五：以上步骤完成之后，最后一步可以考虑调整自动统计信息收集发起任务的时间，<font color="red">尽量错开业务的高峰期，放到每日合并之后进行</font>。**
 
 如果上述步骤有不清楚的地方，或者操作过程有异常的问题，请联系 OceanBase 社区论坛值班同学协助排查。
 
@@ -370,7 +370,7 @@ call dbms_stats.set_table_prefs('database_name',
 ```
 
 2. **<font color="red">增加并行度（degree=>xx）</font>**，在业务低峰期可以考虑适当增加并行度，加速统计信息的收集。
-3. 可以使用PARTITION的方式收集统计信息
+3. 可以使用通过分区推导全局的统计信息收集方式。
 
 同时，**<font color="red">不建议直接调整 estimate_percent 这个选项</font>**。默认情况下，直方图收集是采样少量数据后计算的；如果调整了这个配置项，直方图会直接根据这里指定的比例进行采样收集。这反而会大幅度拖慢直方图的收集，同时基础统计信息收集也没有那么准确。
 

docs/user_manual/operation_and_maintenance/zh-CN/operations_and_maintenance/optimizer_statistics/03_command.md

@@ -14,7 +14,7 @@ OceanBase 4.x 之前版本的统计信息收集主要依靠每日合并过程中
 本文将结合一些实际应用场景针对性的推荐一些手动统计信息收集的命令。
 
 ## 表级统计信息收集
-如果需要显示收集某个表的统计信息，当前主要提供了两种方式进行统计信息：**<font color="red">DBMS_STATS 系统包和 ANALYZE 命令行</font>**。不同版本的差异如下：
+如果需要显式收集某个表的统计信息，当前主要提供了两种方式进行统计信息：**<font color="red">DBMS_STATS 系统包和 ANALYZE 命令行</font>**。不同版本的差异如下：
 
 ### 非分区表的统计信息收集
 **<font color="red">当表的数据量和列的个数的乘积不高于 1 千万时</font>**，推荐使用如下命令收集，比如如下 TEST 用户的表 T1 有 10 个列，同时数据量在一百万行时：