为解决配置项、变量、视图之前的信息模糊、缺少示例等问题，文档团队正在进行配置项、变量、视图专项优化，这里提供几个典型例子想征询下大家的意见和建议，看看目前的内容是否已经能满足大家的诉求。
当前专项优化的内容主要为对配置项、变量、视图文档结构规范化，补充更详细的权限、约束说明，更新更详细的参数或字段介绍，补充更清晰的示例。具体如下：
-
版本标识强化。
-
新增单独的版本说明区块，版本信息更明确。
-
补充不同版本之间的区别。
-
新增功能适用性描述，确保文档的可用性。
-
权限描述清晰化。
- 新增独立的“权限要求”二级标题，清晰描述权限要求。
- 提供标准 SQL 查询接口与系统视图双重访问途径，提升运维透明度，降低沟通成本，提高文档的易用性。
-
参数说明标准化。
-
参数类型进行字段整改。
-
数值描述补齐单位说明。
-
补充关键值的具体含义。
-
示例详细规范化。
- 丰富简单 SQL 语句示例为 Shell 环境下的完整命令，更符合实际使用场景，提高文档的易操作性。
-
知识体系网络化。
- 新增相关文档链接，形成配置参数与功能模块相结合的知识图谱。
针对以上优化内容，提供以下几个已优化内容给大家参考下。
您的宝贵意见对进一步提高文档质量有着巨大的帮助！！！
请大家尽情反馈对这部分内容的使用意见和建议～～～
14 个赞
希望能把超时时间那里的系统变量和配置项都好好介绍一下~
看用户发的问答帖，发现大家在遇到超时问题之后，基本都是尝试性地逐个调大自己知道的几个超时时间，但是 OceanBase 里的超时时间很多，下面列出冰山一角。
obclient [test]> show global variables like '%timeout%';
+---------------------+------------------+
| Variable_name | Value |
+---------------------+------------------+
| connect_timeout | 10 |
| interactive_timeout | 28800 |
| lock_wait_timeout | 31536000 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| ob_pl_block_timeout | 3216672000000000 |
| ob_query_timeout | 10000000 |
| ob_trx_idle_timeout | 86400000000 |
| ob_trx_lock_timeout | -1 |
| ob_trx_timeout | 86400000000 |
| wait_timeout | 28800 |
+---------------------+------------------+
11 rows in set (0.064 sec)
obclient [test]> show parameters like '%timeout%';
+-------+----------+--------------+----------+-----------------------------------------------+-----------+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------+---------+---------+-------------------+---------------+-----------+
| zone | svr_type | svr_ip | svr_port | name | data_type | value | info | section | scope | source | edit_level | default_value | isdefault |
+-------+----------+--------------+----------+-----------------------------------------------+-----------+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------+---------+---------+-------------------+---------------+-----------+
| zone1 | observer | 11.158.31.20 | 22602 | sys_bkgd_migration_change_member_list_timeout | NULL | 20s | the timeout for migration change member list retry. The default value is 20s. Range: [0s,24h] | OBSERVER | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE | 20s | 1 |
| zone1 | observer | 11.158.31.20 | 22602 | location_cache_refresh_sql_timeout | NULL | 1s | The timeout used for refreshing location cache by SQL. Range: [1ms, +∞) | LOCATION_CACHE | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE | 1s | 1 |
| zone1 | observer | 11.158.31.20 | 22602 | location_cache_refresh_rpc_timeout | NULL | 500ms | The timeout used for refreshing location cache by RPC. Range: [1ms, +∞) | LOCATION_CACHE | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE | 500ms | 1 |
| zone1 | observer | 11.158.31.20 | 22602 | rpc_timeout | NULL | 2s | the time during which a RPC request is permitted to execute before it is terminated | RPC | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE | 2s | 1 |
| zone1 | observer | 11.158.31.20 | 22602 | balancer_task_timeout | NULL | 20m | the time to execute the load-balancing task before it is terminated. Range: [1s, +∞) | LOAD_BALANCE | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE | 20m | 1 |
| zone1 | observer | 11.158.31.20 | 22602 | dead_socket_detection_timeout | NULL | 3s | specify a tcp_user_timeout for RFC5482. A zero value makes the option disabled, Range: [0, 2h] | OBSERVER | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE | 3s | 1 |
| zone1 | observer | 11.158.31.20 | 22602 | debug_sync_timeout | NULL | 0 | Enable the debug sync facility and optionally specify a default wait timeout in micro seconds. A zero value keeps the facility disabled, Range: [0, +∞] | OBSERVER | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE | 0 | 1 |
| zone1 | observer | 11.158.31.20 | 22602 | internal_sql_execute_timeout | NULL | 30s | the number of microseconds an internal DML request is permitted to execute before it is terminated. Range: [1000us, 1h] | OBSERVER | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE | 30s | 1 |
| zone1 | observer | 11.158.31.20 | 22602 | arbitration_timeout | NULL | 5s | The timeout before automatically degrading when arbitration member exists. Range: [3s,+∞] | TRANS | TENANT | DEFAULT | DYNAMIC_EFFECTIVE | 5s | 1 |
| zone1 | observer | 11.158.31.20 | 22602 | ob_query_switch_leader_retry_timeout | NULL | 0ms | max time spend on retry caused by leader swith or network disconnectionRange: [0ms, +∞) | OBSERVER | TENANT | DEFAULT | DYNAMIC_EFFECTIVE | 0ms | 1 |
| zone1 | observer | 11.158.31.20 | 22602 | standby_db_fetch_log_rpc_timeout | NULL | 15s | The threshold for detecting the RPC timeout for the standby tenant to fetch log from the log restore source tenant. When the rpc timeout, the log transport service switches to another server of the log restore source tenant to fetch logs. Range: [2s, +∞) | LOGSERVICE | TENANT | DEFAULT | DYNAMIC_EFFECTIVE | 15s | 1 |
+-------+----------+--------------+----------+-----------------------------------------------+-----------+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------+---------+---------+-------------------+---------------+-----------+
11 rows in set (0.104 sec)
而且如果遇到了 SQL 超时，想知道这条 SQL 到底受到了哪个超时时间的限制，看报错日志好像也看不出来，因为无论由于什么超时报错，错误码好像都是 4012。
可以考虑把 ob_query_timeout 超时报错搞成 40120，ob_trx_timeout 超时报错搞成 40121……这样大家看到错误码后，马上就可以知道要调整哪个超时时间了。
10 个赞
还有以下划线开头的隐藏配置项其实也可以考虑介绍下，例如：_recyclebin_object_purge_frequency、_ob_ddl_timeout 这些，不然社区用户在帖子里问起来，没有文档，暂时都只能让大家自行去翻 OB 源码。
6 个赞
最后再说一个我看到的吧，剩下的就交给社区用户了~
-- SHOW PARAMETERS; -- 展示所有配置项
obclient [test]> SHOW PARAMETERS like 'cpu_quota_concurrency'\G
*************************** 1. row ***************************
zone: zone1
svr_type: observer
svr_ip: 11.158.31.20
svr_port: 22602
name: cpu_quota_concurrency
data_type: NULL
value: 4
info: max allowed concurrency for 1 CPU quota. Range: [1,20]
section: TENANT
scope: TENANT
source: DEFAULT
edit_level: DYNAMIC_EFFECTIVE
1 row in set (0.004 sec)
obclient [test]> SHOW PARAMETERS like 'max_string_print_length'\G
*************************** 1. row ***************************
zone: zone1
svr_type: observer
svr_ip: 11.158.31.20
svr_port: 22602
name: max_string_print_length
data_type: NULL
value: 500
info: truncate very long string when printing to log file. Range:[0,]
section: OBSERVER
scope: CLUSTER
source: DEFAULT
edit_level: DYNAMIC_EFFECTIVE
1 row in set (0.005 sec)
scope 列对应的值为 CLUSTER 表示该配置项的生效范围为整个集群；如果 scope 列对应的值为 TENANT，则表示该配置项的生效范围为当前租户。
查询结果中有一个比较容易和 scope 混淆的 section 列，值可能为：LOAD_BALANCE、DAILY_MERGE、RPC、TRANS、LOCATION_CACHE 等等，甚至可能为 TENANT 或者 OBSERVER（上面的示例就专门展示了这种情况）。这个 section 仅仅是一个 tag，只有标签性质，表示这个配置项和哪个模块相关，不代表配置项的生效范围，需要让大家注意将 scope 和 section 列的含义区分开！
尤其是要注意类似于 TENANT 或者 OBSERVER 这种 tag，估计是 OB 研发同学在写标签的时候实在不知道相应的配置项该归为哪个模块更合适了，就直接偷懒把标签打成了 TENANT 或者 OBSERVER，但这个标签并不代表对当前 tenant 或者当前 session 直连的某个 OBServer 生效。
10 个赞
可以增加设置变量与设置参数等相关系统优化的应用举例
7 个赞
1、使用场景方面，建议结合实际业务场景举例
2、权限说明描述，建议补充授权SQL示例
6 个赞
luya
#17
积分兑换建议降一半兑换 599兑换obca 1499兑换obcp
3 个赞
哈哈，在介绍变量和参数的时候，加上set xxx 和 alter system set xxx 的示例是吧？这个好像确实可以有~
其实可以再多加一个如何查询这个变量和参数的值的示例~
4 个赞
