1 内存基础知识1.1 操作系统内存内存是操作系统中程序使用的重要资源，一般使用以下命令查看系统内存使用情况free -gfree命令可以查看当前系统内存整体情况。如free列的值>min_free_kbytes，则系统中有可用内存，不会出现OOM。top命令可查看系统当前各个进程的内存使用情况。主要查看RES、SHR和%MEM列，RES为进程(实例)当前使用的物理内存量，SHR为进程(实例)当前使用的共享内存量，RES包含SHR。%MEM为进程（实例）当前占系统总内存的百分比。OOM(out of memory)：操作系统OOM指的是操作系统的一种保护机制，在系统无法分配内存时，会让oom-killer程序选择一个占用内存最高的进程，将其kill掉，以保证系统中其他进程能正常执行。在触发OOM后，OS会在/var/log/messages中打印相关信息，一般搜索oom-killer即可，日志中当时的系统中所有进程的内存使用情况，可以用于判断是不是数据库进程导致OOM.如果为数据库进程导致OOM，需分析数据库max_process_memory是否设置合理，适当调小max_process_memory来避免OOM。1.2 数据库进程内存数据库进程中使用内存层次如下：进程级内存：max_process_memory： 单进程所能占用的最大内存语句级内存：query_max_mem: 单语句在单DN上能占用的最大内存算子级内存：work_mem: 单个算子在单DN上能占用的最大内存。 公用内存：1.                   存储引擎使用的缓存（参数shared_buffers（行存）和cstore_buffers（列存））2.                   通信库使用的缓冲区（参数comm_usable_memory）3.                   其他（动态库申请的内存，一般很少，如果模块使用较多，请自行控制）其他内存：DDL语句，优化器、系统表cache等内存上下文管理的内存。 重要概念：内存上下文内存上下文可以简单理解为一个语句在一个实例中执行时，对所使用的动态内存按类型的一个树状结构。例如。Hashjoin语句在访问系统表时，要使用cache context,在创建哈希表时，要创建Hash context。所有动态申请的内存都由内存上下文管理。包括work_mem占用的内存，DDL语句、优化器、系统表cache等。  内存问题常用定位视图：目前，GaussDB 200对外提供诸多系统视图，可以用来辅助内存问题的分析定位，常用视图及用法说明如下表所示。（☆代表常用程度）pv_total_memory_detail ☆☆☆☆☆查询当前实例上整体内存使用状态和信息，可以看到各类型内存使用情况，来对当前实例上内存使用情况做一个概要的判断。select * from pv_total_memory_detail;Memorytype中各类型含义如下： 名称含义max_process_memory   实例可用最大内存阈值。由guc参数max_process_memory控制。process_used_memory  实例当前已使用的内存值，从OS top命令RES列取得。如process_used_memory已经或马上要超过max_process_memory，说明当前内存使用已经超限，或马上就要超限。max_dynamic_memory   实例可使用的最大动态内存dynamic_used_memory  实例当前已使用的动态内存dynamic_peak_memory  实例从启动后到目前为止的动态内存峰值dynamic_used_shrctx  当前已使用的共享内存上下文内存量，也记录在dynamic_used_memory内dynamic_peak_shrctx  共享内存上下文峰值。如减去sctpcomm_peak_memory后超过1G，说明共享内存没有释放，存在泄漏。max_shared_memory    最大共享内存，主要为shared_bubffers。shared_used_memory   实例当前已使用的共享内存，从OS top命令SHR列取得max_cstore_memory    列存buffer可使用的最大内存，由guc参数cstore_buffers控制。cstore_used_memory  实例当前已使用的列存buffer.max_sctpcomm_memory  通信模块可使用的最大内存。sctpcomm_used_memory 通信模块已使用的最大内存sctpcomm_peak_memory 通信模块峰值内存other_used_memory    其他内存占用，为OS  RES-     dynamic_used_memory- shared_used_memory- cstore_used_memory后的值。一般为系统中不受memory context管理的的第三方组件所占用的内存。如果过大，也有可能是内存泄漏。 pv_session_memory_detail ☆☆☆☆☆查看内存上下文级别的内存占用详细信息select * from pv_session_memory_detail order by totalsize desc   limit 100;视图中各字段含义如下：名称类型描述sessidtext线程标识+线程启动时间。使用substr可以将线程号过滤出来，方便和上述其他视图进行关联。sesstypetext线程名称。contextnametext内存上下文名称。levelsmallint当前内存上下文的层级。parenttext父内存上下文名称。totalsizebigint当前内存上下文的内存总数，单位字节。指的是分配给当前内存上下文的内存总数，为freesize+usedsize之和。freesizebigint当前内存上下文中已释放的内存总数，单位字节。是指当前你内存上下文中预留的内存，只有这个内存上下文可以使用，其他线程及其他内存上下文都不能使用，实际还是当前内存上下文中占用的。usedsizebigint当前内存上下文中已使用的内存总数，单位字节。       2 内存问题分类问题原因大类问题原因小类集群参数配置集群参数配置不合理OS配置OS参数配置不合理，主要为min_free_kbytes业务层面业务并发度增加业务SQL计划变化（含有hash、sort、agg等）是否新增业务CN报错SQL是否下推参数优化集群内存相关参数并发控制参数业务优化增加内存集群扩容内存泄漏软件BUG 3 内存问题定位方法及解决措施3.1 基本步骤1 Memory is temporary unavailable问题Step1. 当出现memory is temporary unavailable报错后，首先确认是哪个实例报错，是CN还是DN。Step2. 使用gsql登陆到报错的实例上，查询pv_total_memory_detail, 重点查看一下信息：1.       当前是否还存在内存不足问题。方法为查看process_used_memory和max_process_memory的关系，如已经大于或比较接近，则说明当前内存使用已经或即将超限。如明显小于，则说明占用内存大的语句已经跑完或者被杀掉。当前系统已经恢复。这时可查看对应的peak_memory值，如peak_memory值过高，说明确实曾经出现过内存使用过大。2.       当前是哪个类型的内存过大。最常见的是dynamic_used_memory过大，说明动态申请的内存过大，这类问题可能和客户正在运行的SQL强相关。Step3.如通过step2发现当前内存占用仍过高，则进一步使用pv_session_memory_detail继续分析，看内存占用过高是哪个内存上下文引起的。视图中有线程号信息及内存上下文信息，通过这些信息可以判定是什么语句的什么操作占用了过多内存，进而可以cancel此语句，并给客户提出语句优化建议。常见语句问题为：1.       SQL不下推。如内存问题在CN上出现，很大程度上是因为某个SQL的不下推导致。通过explain确认语句不下推后，将语句进行修改使其下推。2.       中间结果集倾斜。GaussDB 200在进行表关联时，优先使用hash join, 需要对一张表创建哈希表，当哈希表大小超过work_mem限制时，会进行下盘避免内存占用过多，但如果原始表里或中间结果集中在join列上存在大量重复数据，是无法下盘的，必须全部载入内存中进行计算，会造成内存大量占用。如pv_session_memory_detail中占用内存最大的内存上下文为hash context,则大概率是此问题。这时应对客户的表和SQL进行分析，对重复值进行处理后，再进行关联。Step4.如通过上一步没有发现内存占用过高的单个语句，但系统整体内存占用仍过高，则问题原因为参数配置不合理或用户语句并发设置不合理。1.       参数配置不合理。需评估系统关键内存参数是否设置合理。如用户将Poc环境直接转为生产。Poc环境为了追求极致性能，一般内存参数设置比较激进。而生产系统 需要长期稳定运行，内存参数设置应相对保守。此时应调整相关参数。a)         max_process_memory设置过小，导致内存不能充分利用而提前报错。b)        shared_buffer/cstore_buffer设置过大：shared_buffer设大可以增大缓存空间，提高数据读取效率，但如设置过大，会导致语句运行时无法申请到足够的动态内存，导致报错。c)         work_mem/maintainence_work_mem设置过大：在高并发场景下，work_mem设置过大可能导致所有语句的work_mem加起来超过可用动态内存的最大值，从而导致报错。 2.       语句并发设置不合理。此问题与参数配置不合理问题相关。语句并发高，则内存参数配置应较小；反过来说，如内存参数配置较大，则可支撑的语句并发也就相应的要变低。a)         局点上线后，或局点业务量增大后频繁报内存不足，很可能是因为max_active_statements设置过高，高并发的语句加起来后超出了系统可用内存上线，此时如检查第一点中参数都合理后，应将max_active_statements调小，让语句排序进行，避免一起运行时报错。b)        局点新上业务后报内存不足，很可能是因为新业务较为复杂，有多个表join、sort或group by。此时如分析不存在中间结果集倾斜，则需要将并发调小，或将work_mem调小。以上操作都可能导致业务响应时间变长，需要和客户确认。Step5. 如分析时已没有现场，则有3个方法来确认什么语句导致了问题1.       到报错的节点日志中搜索全部memory is temporary unavailable报错，分析可能是哪个语句导致的。2.       重新让客户运行业务，或等下次业务高峰期时进行分析。3.       打开active sql。打开后会将内存相关信息记到系统表中。 附：查看集群配置情况和关键参数（1）集群每个物理节点内存、每个节点dn个数；select sessid, contextname, level,parent,totalsize,freesize,usedsize,  datname,query_id  from pv_session_memory_detail a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid and b.state='active' order by usedsize desc limit 20 ;（2）监控session total memory size占用最多的TOP20 session 。select sessid, sum_total, sum_free,sum_used, query_id, query_start, state, waiting, enqueue,query from (select sessid, sum(totalsize) as sum_total, sum(freesize) as sum_free, sum(usedsize) as sum_used from pv_session_memory_detail group by sessid  order by sum_total desc limit 20 ) a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid;（3）监控session中占用内存最多的context TOP20 session.select sessid, contextname, level,parent, pg_size_pretty(totalsize),pg_size_pretty(freesize),pg_size_pretty(usedsize),  datname,query_id, query  from pv_session_memory_detail a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid  order by totalsize desc limit 20 ;（4）监控当前实例总totalsize memroy大小select pg_size_pretty(sum(totalsize)) from pv_session_memory_detail;（5）监控当前实例总usedsize memroy大小select pg_size_pretty(sum(usedsize)) from pv_session_memory_detail;（6）监控当前实例内存总体使用情况select * from pg_total_memory_detail;（7）监控共享内存实时使用情况select * from pg_shared_memory_detail; 4. 通过打开active sql开关来分析某一时间段并发量和单个sql执行使用的内存信息（如果enable_resource_track和enable_resource_record为off表示该功能关闭）打开方法：gs_guc reload -Z coordinator -Z datanode -N all -I all -c 'enable_resource_track =on' ;gs_guc reload -Z coordinator -Z datanode -N all -I all -c 'enable_resource_record =on' ;Active sql分析使用方法（1）查询2018-11-9峰值内存使用top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,max_peak_memory desc limit 10; （2）查询2018-11-9CPU使用top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,total_cpu_time desc limit 10; （3）查询2018-11-9查询时间最长的top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,duration desc limit 10;（4）查询2018-11-9SQL执行失败，错误信息为” memory is temporarily unavailable”且最大峰值内存超过1G的SQLselect * from pgxc_wlm_session_info where start_time like '%2018-11-1%' and status='aborted' and abort_info like '%memory is temporarily unavailable%' and max_peak_memory >1000 order by max_peak_memory desc;               （5）查询不下推的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' and query_plan like ‘%_REMOTE_TABLE_QUERY_ %’;（6）查询不下盘的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' and warning like ‘%spill%’;2 操作系统OOM问题Step1. 查看OS日志：/var/log/messages,搜索oom-killer,确认额是否为gaussdb进程触发的OOMStep2. 分析数据库内存参数，确认设置是否合理，特别是max_process_memory;##常见案例，见附件，请留下邮箱，我们会将文件发送到您邮箱

GaussDB Kernel ODBC 问题定位指南1         基础知识一个典型的用户应用程序如下： 用户的应用程序，调用的ODBC的API，其实是由驱动管理器提供的，这个驱动管理器在微软上就是odbcad32(.exe/.dll)，在Linux上就是UnixODBC。再由它们来调用ODBC的具体驱动（Gauss、Oracle、TD……）。所以一般问题基本会出在以下几个方面：·         应用加载驱动管理器·         驱动管理器加载驱动·         驱动连接数据库2         问题处理2.1        应用程序加载驱动管理器2.1.1        WindowsWindows由于操作系统实现机制的问题，ODBC属于操作系统组件的一部分，除非操作系统损坏，一般不会出现应用程序加载驱动管理器失败；只会出现驱动管理器加载驱动失败。所以这里不再赘述。2.1.2        LinuxLinux上应用程序加载驱动管理器，是指的应用程序依赖于UnixODBC的相关动态库，启动时要将其加载到自己的进程空间中。加载出现问题多表现为在启动时找不到libodbc.so.x/libodbcinst.so.x等库。解决此问题：1.       首先确认环境中是否安装了UnixODBC。如果安装了，那么至少会有isql/odbcinst等工具可用。例如可使用which isql这样的命令来确定安装路径。相关的lib库一般会在which isql指定的bin目录的同级目录下，将其添加到LD_LIBRARY_PATH中重启应用程序便可。export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH特别注意，此语句只影响当前shell会话中的后续命令，其他会话不受影响，特别是后台启动的进程。如果是后台进程，请与应用程序的开发人员确认其运行环境如果修正。2.       如果确认LD_LIBRARY_PATH已经生效（可以打开/proc/应用程序pid/environ文件确认）,依然无法加载libodbc.so.x/libodbcinst.so.x，那么可能是.1或者.2的库的问题。历史原因，一般的开发环境中，UnixODBC提供的库既可能叫libodbc.so.1也可能叫libodbc.so.2。用户程序可能依赖了.2，但是环境中只有.1；也有可能是存在.2，但是依赖了.1。解决此问题，只需要在UnixODBC的lib目录下，将不存在的版本建立成软链接，保证.1与.2都存在，这样出问题的机率便会小很多。特别注意，这里强烈建议是建立软链接，而不要拷贝物理文件，不然可能出现一个应用程序进程中，加载了两个导出函数完全相同的.so，这样可能会引起一些比较难定位的启动错误，后文中会讲到。2.2        驱动管理器加载驱动 2.2.1        Windows最常见x86与x64架构不同，导致的加载失败；此问题的典型报错为：在指定的 DSN 中，驱动程序和应用程序之间的体系结构不匹配此问题可能的原因：在64位程序中使用了32位驱动，或者相反。在64位系统上：·         C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。·         C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。使用不同架构的应用程序时，请使用不同的驱动管理器；同时安装不同的驱动类型。32位系统上只能跑32位程序，也无法安装64位驱动，所以基本不用区分。如果是64位系统，那么它既支持32位程序，也支持64位程序；如果不能确定应用程序是32还是64，可以使用以下办法：1.       ctrl + shift + esc 打开任务管理器2.       查看进程列表中某进程后边有没有*32的字样（有就是32位，没有就是64位），如下图：2.2.2        Linux2.2.2.1       环境中缺少psqlodbcw.so的库一般这个问题的报错是[UnixODBC][Driver Manager]Can't open lib 'xxx/xxx/psqlodbcw.so' : file not found.可能的原因有：1.       odbcinst.ini中配置的路径不正确，最简单的办法是  ls -l 一下这个报错的文件，看看这个是不是真的存在，同时具有执行权限。2.       依赖的库不存在，此时最简单的办法是ldd 一下这个报错的文件，看看是不是真的缺少库，如果缺少库会出现如下问题：要处理这个问题，需要将unixodbc的安装目录下的lib，添加到LD_LIBRARY_PATH里，例如：export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH同时，在UnixODBC的安装的lib目录下，看看libodbcinst.so.x后边的后缀是.1还是.2。如果是.2，那么请建立一个软链接，链接到.1，便可以解决此问题。如果该目录下只有.1的库，没有.2的库，也建议建立一个.2的软链接，防止应用程序依赖于.2，我们依赖于.1，引起冲突。特别注意，当前会话的LD_LIBRARY_PATH不代表应用程序运行时也是同样的LD_LIBRARY_PATH，必要的时候，与应用程序开发人员对齐。如果是常驻进程，可以通过如下方法获取到当前进程的环境变量：cd /proc/应用程序PIDcat environ打印出来的结果可能比较乱，耐心看一下；如果内容有误，与应用程序开发人员对齐修改方法。2.2.2.2       既有.2又有.1的库，导致重复加载这种勤快的用户比较少见，但是一旦出现，很难定位，典型的报错信息是：Driver's SQLAllocHandle on SQL_HANDLE_DBC failed这种情况这时应用与驱动加载的是不同的物理文件，便会导致两套完全同名的函数列表，同时出现在同一个可见域里（UnixODBC的libodbc.so.*的函数导出列表完全一致），产生冲突，无法加载数据库驱动。解决此问题的办法也比较简单，查看LD_LIBRARY_PATH中的第一个unixodbc的lib目录。在其目录下，缺少.2或.1，建立对应的.2或.1的软链接便可。2.3        连接问题2.3.1        服务器不可达典型报错：connect to server failed: no such file or directory此问题可能的原因：·         配置了错误的/不可达的数据库地址，或者端口请检查数据源配置中的Servername及Port配置项，确认网络是通达的。·         服务器listen不正确如果确认Servername及Port配置正确，请根据资料中listen_addresses参数的配置方法，确保数据库listen了合适的网卡及端口，特别是Servername中指定的网卡地址及LVS的虚拟IP地址。修改完记得重启数据库，使listen生效。·         防火墙及网闸、流控设备请确认防火墙设置，将数据库的通信端口添加到可信端口中。如果有网闸、流控设备，请确认一下相关的设置。此问题一般都是第三方商业产品导致，需要咨询服务/产品提供商相关的策略。2.3.2        SSL配置不正确典型报错1：The password-stored method is not supported.解决办法1：请将数据源配置中的的sslmode调整至allow及以上级别，允许使用SSL连接。典型报错2：Server common name "xxxx" does not match host name "xxxxx"  此问题是由于sslmode中使用了全校验(verify-full)，它不仅会校验证书，还会校验证书所在的域名/机器名是否与证书符合，不符合时将报出此问题。解决办法2：重新让CA机构以新的域名/机器名签发证书；或者将SSLMODE调整至verify-ca选项或其以下级别（具体级别见产品资料中的说明）。2.3.3        使用开源驱动连接问题我们的数据库是支持低版本及开源驱动的（V1R7C10及以后），所以可以放心使用。但是偶尔一些从V1R6C10升级上来的数据库，接受开源驱动连接时，会碰到用户认证算法不支持的问题，典型报错如下：authentication method 10 not supported.此问题机理比较复杂，下面详细展开，先说解决办法：·         请使用管理新账号新建一个数据库的用户，并给予其相关的访问权限，使用新用户连接数据库。·         更改当前业务用户的密码，使用新密码连接数据库。解释一下此问题发生的机理：我们的数据库在连接时，是会让客户端将认证信息发过来的。但是发过来的信息不会是明文密码，这是不安全的；客户端发到数据库的认证信息一般是经过加盐后的密码哈希(md5/sha256算法)，迭代次数也非常多。数据库本身也并不存储用户的明文密码，存储的是一个哈希值（所以密码要是丢了，就真的丢了，只能重置不能找回）。数据库在校验这个密码的时候，是比较哈希的，这就涉及到数据库中存储的哈希是使用的什么算法得到的哈希值，常见的是sha256（高斯自研）及MD5（开源）。V1R7C00及以前，数据库中只存储了SHA256的哈希，升级时我们也无法推导用户原有密码，所以升级后仍然只有SHA256的哈希；但是开源客户端只识别MD5的哈希，这就导致数据库无法认证；数据库也只会让客户端以SHA256的哈希来做认证，这时开源就不识别该认证请求，导致报出如上的错误。在创建用户和修改用户密码时，我们的新版本会同时记录两份哈希，所以后续将会同时支持开源及自研的各个版本。 2.3.4        因数据源配置不正确，导致的连接错误典型报错：Data source name not found, and no default driver specified可能原因：1.       数据源名称书写错误（或含有特殊符号）2.       不同的操作系统用户下，数据源可见性不一样；3.       Linux上的数据源配置文件(odbc.ini)位置不正确解决办法：1.       修正数据源名称2.       Windows下，请在当前用户下打开驱动管理器，查看数据源配置是否正确。请注意在64位系统上使用正确的数据源管理器：C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。3.       Linux下使用odbcinst -j 命令，查看当前环境中配置文件的正确路径，输出一般如下：unixODBC 2.3.0DRIVERS............: /usr/local/etc/odbcinst.ini/odbcinst.iniSYSTEM DATA SOURCES: /usr/local/etc/odbcinst.ini/odbc.iniFILE DATA SOURCES..: /usr/local/etc/odbcinst.ini/ODBCDataSourcesUSER DATA SOURCES..: /usr/local/etc/odbc.iniSQLULEN Size.......: 8SQLLEN Size........: 8SQLSETPOSIROW Size.: 8其中USER DATA SOURCES就是用户数据源，优先生效；SYSTEM DATA SOURCES是系统数据源，整个系统可用。请针对这些文件路径，注意：有时用户数据源的配置文件可能是$(HOME)/.odbc.ini2.3.5        通信协议不匹配问题典型报错：unsupported frontend protocol 3.51: server supports 1.0 to 3.0可能原因：使用了新版本的数据库驱动连接老版本的数据库(V1R6C10)；或者使用了我们的驱动，连接到了开源的数据库上。解决办法：1.       请使用老版本的数据库驱动连接该数据库。我们的数据库中，默认低版本客户端可以连接高版本数据库；使用高版本驱动连接低版本客户端，不在规格约束范围内。这个规格也比较好理解：因为用户一般是对数据库集中管理，升级也是有计划的。但是客户端驱动可能嵌入到业务中的每一个角落，有时甚至是已经发布的装备中，升级相对比较困难。2.       如果是开源服务器：我们的数据库驱动不支持开源数据库，无法连接；请使用开源客户端连接。3         其他常见疑问3.1        与开源的区别？1.       增加了安全性，使用了SHA256算法做认证加密；同时调整密钥哈希加密次数2.       提升了批量性能（V1R7C10 2019-4-30及以后版本）3.        3.2        是否可以增加新API？不可以。还是基础知识里那张图，用户引用的API是由驱动管理器提供的，我们提供的API只可供驱动管理器使用；新增API无法穿过中间层为用户提供服务。3.3        是否支持COPY接口？Copy是PG的特有语法及通信协议;而ODBC是微软提出的通用调用接口，所以无此特殊接口。3.4        Linux上的驱动管理器有哪些？驱动管理器在Linux上并不是操作系统的一部分，它也是由其他开源组织开发的。所以并不是只有UnixODBC一种。但是目前使用最广泛的，其实只有UnixODBC，多数据操作系统安装时基本都已经自带了UnixODBC的某个特定版本；除此之外，还有iODBC等，现在已经慢慢退出市场了。3.5        UnixODBC的版本有限制么？有。我们支持2.3.0及以上版本。3.6        UnixODBC的.1与.2的库有什么区别？没有什么区别。这个与UnixODBC的历史有关，历史上有一段时间提供.1，后来做了一次大升级，动态库版本也跟着升级了，变成了.2。但是一大批存量业务受制无法运行，就又添加了.1的支持。.1与.2其实只是UnixODBC的configure配置的一部分，其函数导出，功能完全一致，不必纠结于此。3.7        可以打印日志么？可以。一般建议打印驱动管理器的日志，此日志比较清晰，定位问题比较快。操作办法：·         Windows上：打开驱动管理器，调整到跟踪页面，确定日志文件路径后，点击开始跟踪便可，如图：·         Linux上：打开odbcinst.ini文件（可使用odbcinst -j 来确定文件路径），添加以下章节：[ODBC]Trace=YesTraceFIle=/tmp/odbc.log         重启业务便可。3.8        查询结果集过大，内存吃不消怎么办？打开UseDclareFetch开关，它将会把查询包装成游标操作。对于不支持Cursor with hold的版本慎用。同时由于使用了服务器端的游标，游标的前后滚操作也会反馈给数据库，通信会有所增加，所以性能会有部分下降；可以通过调整Fetch参数来确定每次数据库向客户端反馈的数据量大小，来降低该性能影响。·         Linux下打开UseDeclareFetch的方法：在数据源配置项中添加：UseDeclareFetch=1Fetch=1000·         Windows下打开UseDeclareFetch的方法：         其中的Cache Size选项，就是Fetch的大小。 ##如需完整附件，请留下您的邮箱，我们会及时发送给您

自2019年5月15日正式发布以来，华为GaussDB数据库受到了业界的广泛关注，成为了具有硬核技术色彩的「网红」之一。 今天，就为大家带来粉丝互动专场，近距离一览GaussDB数据库的「庐山真面目」。先抛十个热点问题解渴，更多想了解的，欢迎在评论区留言哦，小板凳已备好。「有疑就问」，是个好习惯。 GaussDB的命名有什么含义？GaussDB是华为数据库产品品牌名，意在致敬数学家高斯（Gauss）。GaussDB系列数据库产品包括GaussDB OLTP(交易型)数据库和GaussDB OLAP（分析型）数据库，广泛应用于金融、政府、电信等行业，并已经进入核心系统，满足客户对智能时代高并发事务实时处理、海量数据高效分析的需求。 GaussDB有好多名字，傻傻分不清楚，可否介绍一下？华为国产数据仓库一直在演进，产品名称从15年的FI MPPDB，经历FI Libra->GaussDB  200->GaussDB A，再到如今线上部署形态的GaussDB(DWS)（数据仓库服务的简写），服务形态从线下纯软到线上服务，不管怎么变，都是为了打造尖刀产品，创造智能未来。GaussDB系列数据库是自主研发的吗？GaussDB OLTP数据库是华为公司自主研发的分布式数据库，基于华为公司在2007年开始研发并在电信计费领域规模商用的自研内存数据库全面改造，支持x86和华为Kunpeng硬件架构，基于创新性数据库内核，提供高并发事务实时处理能力、两地三中心金融级高可用能力和分布式高扩展能力，用于支撑金融、政府、电信等行业核心关键系统。当前支持单机、主备、分布式等主流部署方式。 GaussDB OLAP数据库（现如今的GaussDB(DWS)）是一款具备分析及混合负载能力的分布式数据库，从2011年开始，基于PostgreSQL 9.2.4的基础上自主研发，支持x86和华为Kunpeng硬件架构，支持行存储与列存储，提供PB(Petabyte)级数据分析能力、多模分析能力和实时处理能力，用于数据仓库、数据集市、实时分析、实时决策和混合负载等场景，广泛应用于金融、政府、电信等行业核心系统。 GaussDB OLAP数据库的发展历程是怎样的？GaussDB OLAP数据库于2011年开始预研，之后基于PostgreSQL 9.2.4进行全面改造，历经8年持续不断研发投入，已经形成了自身的完整内核。GaussDB OLAP已经演进成大规模并行处理的分布式数据库，支持行列混合存储以及线程化，能够支持高达2048节点的集群规模（已经通过信通院的512节点认证）。数据库内核三大引擎中，优化器（含SQL解析和SQL优化）、执行引擎、存储引擎，除了SQL解析部分，其他都已重构。 GaussDB OLAP通过全新构筑分布式执行，MPP通信框架，向量化引擎，编译执行引擎从多维度重构了执行引擎，通过列存及自适应压缩、分布式事务等，全新重构了存储引擎。由于SQL解析器、JDBC、ODBC等是数据库生态的重要组成部分，也是GaussDB OLAP构筑生态策略的一部分，因此在这方面做了大量增强。 除了数据库内核有了翻天覆地的变化之外，在集群管理、高可用和数据库安全方面，GaussDB OLAP数据库也做了极大的增强，同时申请了多项专利。作为企业级分布式数据库产品，GaussDB OLAP数据库还提供了包括运维管理、开发工具、迁移工具、数据复制工具等五大完整工具集。 2014年，华为孵化出Gauss OLAP数据库第一个产品版本（早期也叫做FusionInsight MPPDB或FusionInsight LibrA）。2015年，华为与工商银行一起联合创新，孵化出了包括TPC多流，逻辑集群等多项创新技术。双方从联合创新进入实践和应用，最终在2019年，顺利完成了核心数仓系统GaussDB OLAP数据库对国际顶尖数据库产品的替换和演进。 GaussDB OLAP数据库有哪些特点？GaussDB OLAP数据库主要面向OLAP场景，支持MPP（大规模并行处理）分布式部署方式。产品特点包括： ● 高可用：故障时查询自动重试，同城/异地双集群容灾 ● 高性能：核心企业数据仓库场景下，分析性能持平其他业界主流分析型数据库，基于Kunpeng 920处理器芯片，相对通用同期芯片，TPC-H/TPC-DS性能提升30%，支持GPU异构多维硬件加速(10万路摄像头千亿图像比对秒级响应)● 高扩展：单集群最大支持2048节点，在线扩容，重分布对业务透明● 数据融合：SQL on Anywhere，支持与异构/同构数据源、MRS大数据库互联互通● 计算融合：支持x86/华为Kunpeng CPU、GPU等异构计算芯片的智能调度，实现算力最优● 数据安全：数据透明加密，支持国密算法SM4，行级细粒度权限控制 GaussDB OLAP数据库目前市场使用情况如何？截止2019年5月，华为GaussDB数据库已经应用于全球60个国家及地区，服务于1500多个客户，拥有500多家商业合作伙伴，并广泛应用于金融、运营商、政府、能源、医疗、制造、交通等多个行业。 近日，在中国信息通信研究院和数据中心联盟发起的分布式分析型数据库测试中，华为GaussDB OLAP数据库率先通过512节点集群规模能力评测。与此同时，中国工商银行也完成了采用华为GaussDB OLAP数据库对国外顶级数据仓库产品的完全替代。 目前，华为GaussDB系列数据库产品全球累计发货超过30000套。 GaussDB为何要转云上模式？1）从面临的现实问题来看：混合云是为了解决原销售模式交付的一系列问题。参差不齐不齐的硬件（多个品牌不同系列不同规格）、高达20+操作系统（含补丁版本）、异构组网、多种历史软件版本。由于运行时环境比较复杂，兼容性验证不充分，导致系统故障率高，定位周期较长；同时针对差异化运行时环境，导致安装部署、升级补丁、扩容等交付和运维效率较低，企业用户体验不佳。2）从IT产业趋势来看，从PC时代->互联网时代->移动互联网->智能数据时代，技术架构不断变迁，也在从单机->集群->分布式->云化方向演进，因此公司也在紧跟时代特征进行战略调整，提出一云两翼双引擎战略，当前混合云、大数据、数仓仓库、数据库的策略调整是总体战略调整的一部分；3）华为公有云经过多年的摸索，其标准化交付和运维已经非常成熟，交付、运维、故障处理经验可复制到客户机房。4）基于云架构，华为提供高达60+的数据库、大数据、AI的云服务，企业可基于华为云服务快速构建数据平台，简化运维，实现业务快速上线，当然客户也可以选择不用。 GaussDB上云之后能给客户带来哪些好处？即开即用  ——  省钱、快速您需要支付的费率很低，而且只需为实际消耗的资源付费。此外，您无需前期投入较多固定成本，可以从低规格的数据仓库实例起步，以后随时根据业务情况弹性伸缩所需资源，按需开支。DWS让您能够轻松完成从项目概念到生产部署的整个过程。通过使用 DWS Console，您不需要安装数据仓库软件，也不需要部署数据仓库服务器，就可以在几分钟之内获得高性能、高可能的企业级数据仓库集群。稳定可靠  ——  省事又省心DWS在高可靠的基础设施上运行。DWS是分布式MPP数据仓库，是由多个节点组成的集群数据仓库，所有的软件进程均有主备保证，数据存储节点的数据均有主备保证，能够保证在任意单点物理故障的情况下系统依然能够保证数据可靠、一致，同时还能对外提供服务。DWS还具有可以增强数据仓库可靠性的众多其他功能，包括备份以及恢复等。便捷管理  ——  可视又可控通过使用 DWS Console，您只需点击几下鼠标，可以轻松完成应用程序与数据仓库的连接、数据备份、数据恢复、数据仓库资源和性能监控等运维管理工作。您可以使用 CES Console 来查看数据仓库实例的关键性能指标，包括磁盘使用率、CPU使用率、内存使用率、IOPS、网络输入吞吐量、网络输出吞吐量、活跃SQL数、会话数等。 GaussDB上云之后纯软版本如何支持？纯软版本可持续支持至2023年12月31日（需要升级到8.0）；在2022年6月30日之前，现网已有的GaussDB A 可以继续按原模式进行扩容（需要升级到8.0）； 2022年6月30日前的商务和2023年12月31日前的服务可按意向书保障（需要升级到8.0）。如果想学习华为云数仓GaussDB(DWS) ，有什么渠道？有多种渠道可以学习华为GaussDBOLAP的数据库产品：● 关注“GaussDB DWS”公众号，及时了解GaussDB(DWS)产品及技术动态● 访问华为云GaussDB(DWS)官网获取在线产品资料：https://www.huaweicloud.com/product/dws.html ● GaussDB(DWS)开发者社区提供开发工具、互动社区、开发指南、安全中心等服务：https://bbs.huaweicloud.com/forum/forum-598-1.html  

1. 简介GaussDB 与 DataStage 对接，均依赖ODBC访问GaussDB for DWS本次测试环境为：操作系统：Linux软件版本：DataStage 7.52. 搭建DataStage2.1 软件安装    以下使用root用户：1.     yum install gcc-c++以及compat-libstdc++2.     创建用户组dstage：groupadd dstage3.     创建dstage组的用户dsadm：useradd dsadm –g dstage -m；passwd dsadm4.     运行DataStage Server安装包中的install.sh：./install.sh –admin dsadm5.     安装中一路next即可，注意选择简体中文语言，不然Windows客户端连接时可能出错2.2 DataStage ODBC配置    驱动包：V2R1LinuxODBC32bit_DataStage.tar.gz（RHEL4.7为ODBC32RHEL47DS75.tar.gz）    使用dsadm用户执行：1.     将psqlodbcw.so和libpq.so复制到/home/dsadm/Ascential/DataStage/branded_odbc/lib2.     在/home/dsadm/Ascential/DataStage/branded_odbc/lib下执行(RHEL4.7下，若有/usr/lib/ libodbcinst.so.1可以不用此步骤)       cp libodbcinst.so libodbcinst.so.13.     编辑/home/dsadm/Ascential/DataStage/DSEngine/.odbc.ini文件，增加以下内容（可参考odbcini.gaussdb.example文件）                    [GaussDB]                    Driver=/home/dsadm/Ascential/DataStage/branded_odbc/lib/psqlodbcw.so                    Setup=/home/dsadm/Ascential/DataStage/branded_odbc/lib/psqlodbcw.so                    DriverUnicodeType=1                    Description=GaussDB via ODBC                    Servername=数据库IP                    Port=数据库端口                    Database=数据库名                    Username=用户名                    Password=密码                    Sslmode=allow                    ReadOnly=no      在.odbc.ini文件开头的[ODBC Data Sources]下增加                       GaussDB=GaussDB via ODBC4.     编辑/home/dsadm/Ascential/DataStage/Projects/project名/uvodbc.config文件，增加：                <GaussDB>                DBMSTYPE = ODBC2.3 应用侧ODBC配置配置数据源    将Gauss MPPDB提供的ODBC DRIVER（psqlodbcw.so）配置到数据源中便可使用。配置数据源需要配置odbc.ini和odbcinst.ini两个文件（在编译安装unixODBC过程中生成且默认放在/usr/local/etc目录下），并在服务器端进行配置。前提条件   获取unixODBC源码包。以unixODBC-2.2.1版本为例，执行如下命令安装unixODBC。默认安装到/usr/local目录下。                tar zxvf unixODBC-2.2.1.tar.gz                cd unixODBC-2.2.1                ./configure                make                make install      odbcinst.ini           odbcinst.ini是配置ODBC驱动的文件。           odbcinst.ini 文件配置参数            odbc.ini            odbc.ini是配置数据源的文件。            odbc.ini 文件配置参数              服务器端配置步骤1 将install/data目录下postgresql.conf文件中的listen打开。    例：listen_addresses = '*'步骤2 在上述data目录下pg_hba.conf文件中增加认证信息。   例：host all all xxx.xxx.xxx.xxx/32 sha256步骤3 设置环境变量        export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH        export ODBCSYSINI=/usr/local/etc        export ODBCINI=/usr/local/etc----结束测试数据源配置执行isql -v gaussdb(数据源名称)命令。输入 "l" 如果显示如下信息，表明配置正确。        +---------------------------------------+        | Connected! |        | |        | sql-statement |        | help [tablename] |        | quit |        | |        +---------------------------------------+        SQL> 若显示ERROR信息，则表明配置错误。请检查上述配置是否正确。3. DataStage 简单使用                Windows下的DataStage Client安装一路next即可。1.     打开DataStage Designer，使用创建的dsadm用户连接DataStage服务器。                        2.     创建server job。                         3.     创建输入数据源ODBC_Input和输出数据源ODBC_OUTPUT                                               4.     添加Transformer                                                5.     建立连接关系                                                 6.     导入元数据，并建立表映射                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        7.     运行job                                                                                                                                                                             Link绿色表示成功1.     数据从test复制到了test2                    

一、摘要项目交付中可能会遇到同时包含核心交易（OLTP）和报表分析（OLAP）的混合业务场景，其中报表分析类业务复杂度高，消耗大量系统资源，但实时性要求较低，而核心交易类业务并发较大，多为简单事务处理，对实时性要求高。当系统处于业务高峰时，报表分析类业务并发操作会加剧系统负载，且长时间占用资源无法释放，最终可能导致整体性能裂化，实时性要求较高的核心交易类业务因资源争抢而无法得到响应，从而影响客户整体体验。资源管控的目的是基于业务场景和可用资源，进行合理的资源与并发度管控，以保障数据库可以在高负载场景下正常运行，不会因为资源争抢和耗尽出现系统卡死，提升系统整体吞吐量。二、场景分析如上图所示，业务场景主要分为核心交易（OLTP）和报表分析（OLAP）两大类，其中报表服务的优先级相对较低，在合理的情况下优先保障业务系统的正常运行。业务系统中运行的SQL分为简单SQL和复杂SQL，大量复杂SQL的并发执行会导致数据库服务器资源争抢，简单SQL的大量并发对服务器不构成持续压力，短时间内可执行完成，不会造成业务堆积。其中报表服务中运行的SQL以复杂SQL居多，整体业务逻辑相对复杂，在数据库层面需要分别对核心交易和报表服务进行合理的资源管控，以保障业务系统正常运行。三、方案规划(一) 静态资源池规划静态资源池可以控制数据库能使用服务器资源的上限，由于服务器操作系统运行也需要消耗一定的资源，因此预留一定的服务器资源来保障操作系统的正常运行。推荐静态资源池配置：数据库分配93% CPU资源和70% 内存资源。这样可以保证服务器能够正常响应系统请求。静态资源池分配93% CPU资源和70% 内存资源。(二) 交易用户和报表用户分离报表分析类业务的优先级和实时性相对较低，但是复杂度更高，为有效进行资源管控，将报表分析和核心交易业务进行数据库用户分离，例如核心交易业务使用数据库用户budget_config_user，报表分析业务使用数据库用户report_user。针对交易用户和报表用户分别进行CPU资源和并发数控制以保障数据库稳定运行。结合报表分析业务的负载调研、日常监控和测试验证，20并发以内的复杂报表SQL不会引起服务器资源争抢，不会引起业务系统卡慢，因此配置报表用户最多使用20%的CPU资源。结合核心交易业务的的负载调研、日常监控和测试验证，50并发以内的复杂SQL不会对系统造成持续压力，整体CPU负载小于60%。交易用户分配60%的CPU配额和50并发。报表用户分配20%的CPU限额和20并发。其中CPU配额是指占用CPU时间片的百分比。若分配给某个用户的CPU配额资源未使用，系统会自动将这些资源共享给其他用户。CPU限额是指用户可以使用的CPU核数的百分比。系统会将百分比换算成具体的核数供用户使用，且用户可使用的CPU限额资源不超过通过百分比换算的核数范围。(三) 并发管控阈值设置资源管控的并发控制是基于SQL的cost值（SQL执行代价）来评估，结合客户场景、硬件配置和SQL测试分析，当SQL的cost值小于1000时，SQL并发对服务器不构成持续压力，短时间内可执行完成，不会造成业务堆积。当SQL的cost值大于1000时，大量并发会导致服务器资源争抢，引起系统卡慢。因此将受控SQL的cost的临界值设置为1000。当SQL的cost值大于1000时受资源管控的并发度控制，当SQL的cost值小于1000时不受资源管控的并发度控制。区分SQL复杂和简单的cost值设置为1000四、实施方案(一) 配置静态资源池登录运维管理页面，配置静态服务池，设置cpu为93%，内存为70%(二)  数据库用户分离创建交易用户（budget_config_user）和报表用户（report_user）。(三)  配置cgroup使用omm用户登录数据服务器，执行如下命令设置CPU配额：source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile gs_ssh -c "gs_cgroup -c -S class1 -s   60" gs_ssh -c "gs_cgroup -c -S class1 -G wg1 -g   99" gs_ssh -c "gs_cgroup -c -S class2 -s 20   " gs_ssh -c "gs_cgroup -u -S class2 -s 20   --fixed" gs_ssh -c "gs_cgroup -c -S class2 -G wg2 -g   99 "(四) 创建资源池并绑定cgroup使用omm用户登录数据库服务器，执行如下命令设置并发管控：source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile gSQL -d postgres -p 25308 -c "create   resource pool rp1 with   (mem_percent=0,active_statements=50,control_group='class1:wg1');” gSQL -d postgres -p 25308 -c "create   resource pool rp2 with (mem_percent=0,active_statements=20,control_group='class2:wg2');"(五) 用户绑定资源池使用omm用户登录数据库服务器，执行如下命令将用户绑定资源池：source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile gSQL -d postgres -p 25308 -c "alter user budget_config_user   resource pool 'rp1';" gSQL -d postgres -p 25308 -c "alter user report_user resource   pool 'rp2';"(六) 修改数据库参数并重启生效使用omm用户登录数据库服务器，执行如下命令修改数据库参数：source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile gs_guc reload -Z coordinator -Z datanode -N all   -I all -c "parctl_min_cost=1000" gs_guc set -Z coordinator -Z datanode -N all -I   all -c "enable_dynamic_workload=off" cm_ctl stop cm_ctl start五、资源管控测试验证(一) 测试SQL样例select count(1) from p#fasp_t_glctrl122299 a,p#fasp_t_glctrl122299   b;打印执行计划如下，cost值大于1000，已按方案设置资源管控的并发控制阈值cost为1000：(二) 交易用户并发验证使用交易用户budget_config_user使用测试SQL样例（cost值大于1000）启动100并发测试使用budget_config_user进行100并发样例SQL验证，当并发数达到50时管控，超过50并发后剩余SQL在管道内排队等待执行。(三)  报表用户并发验证使用报表用户report_user使用测试SQL样例（cost值大于1000）启动100并发测试使用report_user进行100并发样例SQL验证，当并发数达到20时管控，超过20并发后剩余SQL在管道内排队，等待执行。(四)  报表用户和交易用户同时并发验证分别使用交易用户budget_config_user和报表用户report_user使用测试SQL样例（cost值大于1000）分别启动100并发测试使用budget_config_user和report_user分别进行100并发样例SQL验证，交易用户并发50受控，报表用户并发20受控。(五) 报表用户限额CPU验证使用报表用户report_user使用测试SQL样例（cost值大于1000）启动100并发测试CPU限额设置20%，使用report_user进行100并发样例SQL验证，CPU使用达到20%时进行资源管控。CPU限额设置30%，使用report_user进行100并发样例SQL验证，CPU使用达到30%时进行资源管控。(六) 交易用户配额CPU验证使用交易用户budget_config_user使用测试SQL样例（cost值大于1000）启动100并发测试在配额60%CPU的情况下，CPU使用可以超过60%，不进行CPU强制限制（这点与限额不同），业务高峰时可以根据业务情况弹性扩展。转载自：华为云开发者论坛

数据库在使用的过程中，经常会出现cn或dn实例重启的情况，有些是用户自己kill，有些就是代码bug导致的实例重启，代码bug导致的core问题需要core文件才能进一步定位根因，GaussDB 的bbox生成的core文件在一些情况下无法解析，所以该文档介绍下如何配置OS的core配置1.在集群内OMS主节点（之所以在主oms节点，是为了第2步使用集群的分发和执行指令，如果节点数较少，或者第2步没有集群执行脚本，可以单独在集群内所有数据节点上单独创建core.sh脚本）的/tmp目录下新建core.sh文件内容如下：sed -i '/^.*hard.*core.*$/d' /etc/security/limits.confsed -i '/^.*soft.*core.*$/d' /etc/security/limits.confecho "* soft core unlimited" >> /etc/security/limits.confecho "* hard core unlimited" >> /etc/security/limits.confecho "core" > /proc/sys/kernel/core_patternsed -i '/^kernel.core_pattern.*$/d' /etc/sysctl.confecho "kernel.core_pattern=core" >> /etc/sysctl.confecho "0" > /proc/sys/kernel/core_uses_pid/sbin/sysctl -p2.在新集群OMS主节点用root执行如下命令（该方法使用集群脚本，一次在所有的节点上设置，也可以手动在每个节点运行core.sh脚本）dos2unix /tmp/core.shcd /opt/FusionInsight_SetupTool/preinstall/tools/cluster./clusterscp.sh put /tmp/core.sh /tmp/./clustercmd.sh "sh /tmp/core.sh"3.查看是否配置成功1) ps -ef|grep master,找到主DN（备DN，需要把master改为slave）的进程号2) cd /proc/进程号。3) view limits（查看 core file size是否是unlimited）4) cat /proc/sys/kernel/core_pattern（查看该配置文件是否配置的是core）5）cat /etc/security/limits.conf | grep core是否存在soft core unlimited与hard core unlimited6）cat /proc/sys/kernel/core_uses_pid是否为07）cat /etc/sysctl.conf | grep core_pattern是否为kernel.core_pattern=core4.kill om_monitor并重启集群，切换到omm用户下，source环境变量，执行如下操作gs_ssh -c "killall -u omm om_monitor"等待3分钟，等待om_monitor全部启动，后执行如下指令重启集群生效cm_ctl stopcm_ctl start5.验证是否成功kill -11 备DN进程号，会在数据库的数据目录（/srv/BigData/mppdb/data1/master1）下生成core文件

GaussDB(DWS)实践系列-数据仓库自动化清理功能实现 摘要：定期清理数据库中垃圾数据、更新统计信息可以提升系统整体运行效率。本文旨在对3种常用的清理和收集命令进行讲解，并汇总整理自动化清理脚本。（1）vacuum介绍：VACUUM回收表或B-Tree索引中已经删除的行所占据的存储空间。在一般的数据库操作里，那些已经DELETE的行并没有从它们所属的表中物理删除，在完成VACUUM之前它们仍然存在。因此有必要周期地运行VACUUM，特别是在经常更新的表上。 VACUUM FULL通常要比单纯的VACUUM收缩更多的表尺寸，但是需要耗时更多。如果导入过程中，进行了大量的更新或删除行时，会产生大量的磁盘页面碎片，从而逐渐降低查询的效率。应运行VACUUM FULL命令将磁盘页面碎片恢复并交还操作系统，然后运行ANALYZE命令更新统计信息。 （2）analyze介绍：在数据库中，统计信息是规划器生成计划的源数据。没有收集统计信息或者统计信息陈旧往往会造成执行计划严重劣化，从而导致性能问题。analyze命令可收集与数据库中表内容相关的统计信息，统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据，以生成最有效的执行计划。建议在执行了大批量插入/删除操作后，例行对表或全库执行ANALYZE语句更新统计信息。 （3）reindex介绍：REINDEX功能描述为表中的数据重建索引。VACUUM FULL通常要比单纯的VACUUM收缩更多的表尺寸，但是FULL选项并不清理索引，所以推荐周期性的运行REINDEX命令。在以下几种情况下需要使用REINDEX重建索引：1、索引崩溃，并且不再包含有效的数据。2、索引变得“臃肿”，包含大量的空页或接近空页。3、为索引更改了存储参数（例如填充因子），并且希望这个更改完全生效。  自动化清理脚本如下：#!/bin/bash PGPORT=25308parallel=20 source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile function do_vaccumm_full_systable{     TABLELIST=" '\"'|| nspname || '\".\"' || relname   || '\";' FROM pg_class c    INNER JOIN   pg_namespace n ON c.relnamespace = n.oid    WHERE   c.oid < 16384 AND relkind = 'r'    AND   reloptions::text NOT LIKE '%internal_mask%'";     echo   "********Start Vacuum Full Systable For Database "$1`date   "+%Y-%m-%d %H:%M:%S"`    gsql -p   $PGPORT -d $1 -tc "SELECT 'VACUUM FULL ' || $TABLELIST" | gsql -p   $PGPORT -d $1    gsql -p   $PGPORT -d $1 -tc "SELECT 'REINDEX    table ' || $TABLELIST" | gsql -p $PGPORT -d $1    gsql -p   $PGPORT -d $1 -tc "SELECT 'ANALYZE ' || $TABLELIST" | gsql -p   $PGPORT -d $1} function do_vaccumm_full_udt{     TABLELIST=" '\"'|| nspname || '\".\"' || relname   || '\";' FROM pg_class c    INNER JOIN   pg_namespace n ON c.relnamespace = n.oid    WHERE   c.oid >=16384 AND relkind = 'r'    AND   reloptions::text NOT LIKE '%internal_mask%'";     echo   "********Start Vacuum Full User-Define Table For Database "$1`date   "+%Y-%m-%d %H:%M:%S"`    echo   "\parallel on "$parallel > /dev/shm/vacuum_full_list    gsql -p   $PGPORT -d $1 -tc "SELECT 'VACUUM FULL ' || $TABLELIST"  >> /dev/shm/vacuum_full_list    echo   "\parallel off" >> /dev/shm/vacuum_full_list    gsql -p   $PGPORT -d $1 -f /dev/shm/vacuum_full_list     echo   "********Start Reinex User-Define Table For Database "$1`date   "+%Y-%m-%d %H:%M:%S"`    echo   "\parallel on "$parallel > /dev/shm/reindex_list    gsql -p   $PGPORT -d $1 -tc "SELECT 'REINDEX TABLE ' || $TABLELIST"  >> /dev/shm/reindex_list    echo   "\parallel off" >> /dev/shm/reindex_list    gsql -p   $PGPORT -d $1 -f /dev/shm/reindex_list     echo   "********Start Analyze User-Define Table For Database "$1`date   "+%Y-%m-%d %H:%M:%S"`    echo   "\parallel on "$parallel > /dev/shm/analyze_list    gsql -p   $PGPORT -d $1 -tc "SELECT 'ANALYZE ' || $TABLELIST"  >> /dev/shm/analyze_list    echo   "\parallel off" >> /dev/shm/analyze_list    gsql -p   $PGPORT -d $1 -f /dev/shm/analyze_list} function do_vaccumm_full{      do_vaccumm_full_systable $1      do_vaccumm_full_udt $1} function main{      do_vaccumm_full  gn_province_cz      do_vaccumm_full  gn_shb_cz} main @  博客链接：https://bbs.huaweicloud.com/blogs/175440 华为云社区论坛链接：https://bbs.huaweicloud.com/forum/forum-598-1.html 

表1中描述了在GaussDB A操作与维护阶段，进行日常操作时应注意的禁用操作。表1 禁用操作类别操作风险严禁JDBCServer主备节点频繁倒换频繁主备倒换将导致业务中断严禁修改节点主机名主机名修改后会导致该主机上相关实例和上层组件无法正常提供服务，且无法修复严禁修改数据目录下文件名，权限，内容不能修改，不能删除内容导致DN实例出现严重错误，并且无法修复严禁删除数据库系统表或系统表数据删除系统表将导致无法正常进行业务操作表2中描述了在GaussDB A操作与维护阶段，进行日常操作时应注意的高危操作。表2 高危操作操作分类操作名称操作风险风险等级规避措施重大操作观察项目Manager修改OMS密码该操作会重启OMS各进程，影响集群的管理维护★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常导入证书该操作会重启OMS进程和整个集群，影响集群的管理维护和业务★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常升级该操作会重启Manager和整个集群，影响集群的管理维护和业务分配集群管理权限的用户，需要严格管控，以防范可能的安全风险★★★修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常补丁该操作会重启Manager和整个集群，影响集群的管理维护和业务分配集群管理权限的用户，需要严格管控，以防范可能的安全风险★★★修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常恢复OMS该操作会重启Manager和整个集群，影响集群的管理维护和业务★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常修改IP该操作会重启Manager和整个集群，影响集群的管理维护和业务★★★修改时确保同一时间无其它管理维护操作，且修改的IP填写正确无误观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常修改日志级别如果修改为DEBUG，会导致Manager运行速度明显降低★★修改前确认操作的必要性，并及时修改回默认设定无更换控制节点该操作会导致部署在该节点上的服务中断，且当该节点同时为管理节点时，更换节点会导致重启OMS各进程，影响集群的管理维护★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常 更换管理节点该操作会导致部署在该节点上的服务中断，会导致重启OMS各进程，影响集群的管理维护★★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常重启下层服务时，如果勾选同时重启上层服务该操作会导致上层服务业务中断，影响集群的管理维护和业务★★★★操作前确认操作的必要性，操作时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常修改OLDAP端口修改该参数时，会重启LdapServer和Kerberos服务和其关联的所有服务，会影响业务运行  ★★★★★操作前确认操作的必要性，操作时确保同一时间无其它管理维护操作无重装主机该操作会对指定主机上的软件进行重新安装，并可能因清理数据目录造成数据丢失★★★操作前请确认重新安装的必要性，并谨慎选择清理数据选项观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常重装实例该操作会对指定主机上的实例进行重新安装，并可能因清理数据目录造成数据丢失★★★操作前请确认重新安装的必要性，并谨慎选择清理数据选项观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常重启服务重启过程中会中断服务，如果勾选同时重启上层服务会导致依赖该服务的上层服务中断★★★操作前确认重启的必要性观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常系统下电、上电非标准化下电、上电操作，会导致系统再次上电后，集群启动异常，如Ldap数据不同步、controller启动失败等★★★请参考系统上下电进行标准的系统下电、上电操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常KrbServer 修改KrbServer的参数“KADMIN_PORT”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无修改KrbServer的参数“kdc_ports”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无修改KrbServer的参数“KPASSWD_PORT”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无修改KrbServer的参数“default_realm”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无配置跨集群互信该操作会重启KrbServer服务和其关联的所有服务，影响集群的管理维护和业务★★★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常LdapServer修改LdapServer的参数“LDAP_SERVER_PORT”修改该参数后，若没有及时重启LdapServer服务和其关联的所有服务，会导致集群内部LdapClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启LdapServer服务和其关联的所有服务无修改LdapServer的参数“LDAP_EXTERNAL_IP”修改该参数后，若没有及时重启LdapServer服务和其关联的所有服务，会导致集群内部LdapClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启LdapServer服务和其关联的所有服务无恢复LdapServer数据该操作会重启Manager和整个集群，影响集群的管理维护和业务★★★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作 观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常 更换LdapServer所在节点该操作会导致部署在该节点上的服务中断，且当该节点为管理节点时，更换节点会导致重启OMS各进程，影响集群的管理维护★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常 修改LdapServer密码修改密码需要重启LdapServer和Kerberos服务，影响集群的管理维护和业务 ★★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作 无节点重启导致LdapServer数据损坏如果未停止LdapServer服务，直接重启LdapServer所在节点，可能导致LdapServer数据损坏★★★★★使用LdapServer备份数据进行恢复无数据库不能直接在配置文件中手动修改端口号。导致数据库启动不了或者连接不上。▲▲▲▲▲尽量使用工具修改，不要手动操作。无。不能随意修改“pg_hba.conf”配置文件中的内容。导致客户端连接不上。▲▲▲▲▲严格根据产品手册操作。无。不能手动修改“pg_xlog”的内容。导致数据库无法启动，数据不一致。▲▲▲▲▲尽量使用工具修改，不要手动操作。无。

集群启停问题定位指南1      集群启停基本原理1.1      起停依赖关系描述及图示FIM：集群管理界面，用户可以从FIM界面上下发启动和停止集群操作； cron：系统服务，每一分钟定时查看om_monitor服务是否拉起，如果没有拉起，则拉起；om_monitor：常驻系统，用于拉起cm_agent；cm_agent：起停 cn、dn、gtm、cm_server，以及在停止时，当cn、dn、gtm、cm_server停止后，cm_agent自退出。      1.2      日志路径组件名日志路径FIM/var/log/Bigdata/mpp/scriptlog/prestart.log/var/log/Bigdata/mpp/scriptlog/start.log以上日志每个数据节点上均存在gs_om/var/log/Bigdata/mpp/omm/om/gs_om-   YYYY-MM-DD_hhmmss.log以上日志每个数据节点上均存在om_monitor/var/log/Bigdata/mpp/omm/cm/cm_agent/om_monitor-YYYY-MM-DD_hhmmss.log以上日志每个数据节点上均存在cm_agent/var/log/Bigdata/mpp/omm/cm/cm_agent/cm_agent-YYYY-MM-DD_hhmmss.log/var/log/Bigdata/mpp/omm/cm/cm_agent/system_call-YYYY-MM-DD_hhmmss.log以上日志每个数据节点上均存在cm_server/var/log/Bigdata/mpp/omm/cm/cm_agent/cm_server-YYYY-MM-DD_hhmmss.log以上日志仅在主备cm_server节点上均存在1.3      集群实例角色状态信息表实例角色状态DN   build 状态和GTM 同步状态CMSPrimary(主)Standby(备)Pending(待仲裁状态，等待仲裁为主或者备)DownCNNormal(正常)Deleteing(正在删除)Deleted(已经删除)DownDNPrimary(主)Standby(备)Dummy_standby(从备)Pending(待仲裁状态，等待仲裁为主或者备)DownNormal(正常)Starting(正在启动)Need   repair(待处理状态)Waiting   Promoting(等待升主)Promoting(备机升主中)Demoting(主机降备中)Building(备机正在build)Build   failed(备机build失败)Manual   stop(手动停止)Disk   damaged(磁盘故障)Port   used(端口占用)Unknown(状态未知)Connecting(DN主备连接)Disconnect(DN主备未连接)Walsegmen   removed(DN日志分叉) GTMPrimary(主)Standby(备)Pending(待仲裁状态，等待仲裁为主或者备)DownConnection   OK(主备连接OK)Connection   bad(主备连接有问题)Starting(正在启动)Manual   stop(手动停止)Disk   damaged(磁盘故障)Port   used(端口占用)Unknown(状态未知)Sync(同步模式)Async(非同步模式)Most   available(最大可用模式)2      启动集群常见问题分类3      集群启停问题定位方法及解决措施使用命令cm_ctl query -Cv查看集群状态，根据状态进入不同分支场景进行排查处理。3.1      整节点未启动Step1. 使用命令cm_ctl query -Cv查看集群状态信息确认整节点未启动的主机名；Step2. omm用户登录对应节点，查看om_monitor进程是否存在，如果om_monitor进程不存在，则可能原因是omm用户定时任务异常、omm用户密码超期、cgroup挂载异常，可通过分析om_monitor日志、omm用户定时任务、omm用户密码超期时间等方式进行进一步分析；Step3. 如果节点上om_monitor进程存在，cm_agent进程不存在，则可能原因是FIM界面启动命令未成功下发到后台、python版本过高或其它原因导致om_monitor未能启动cm_agent，可通过检查启停标志文件、节点上python版本、om_monitor日志等方式进一步分析。部分实例未启动，查看具体的实例问题，逐步分析。一般启动问题为DN、CN、GTM等实例启动失败，或者无法选主。这种情况，需要结合日志分析。通常有磁盘故障、端口占用、环境变量冲突等情况。3.2      节点内部分实例未启动Step1. 使用命令cm_ctl query -Cv查看集群状态信息确认未启动的实例及所在节点主机名；Step2. omm用户登录对应节点，查看cn/dn/gtm/cm_server实例进程是否存在，如果进程不存在，则可能原因是端口被占、lvs虚拟ip丢失、cn/dn的postgresql.conf配置文件的listen_address参数存在无效ip、进程listen端口号对应锁文件残留、cn/dn配置文件中存在无效GUC参数、系统信号量参数配置过小、存在多个cm_agent进程、路径无权限、磁盘满、数据目录权限异常等，需要结合日志具体分析；Step3.如果cn/dn/gtm/cm_server进程存在,但状态为down或者unknown，则可能原因是当前节点与主cm_server节点网络不通、cm_server无主、节点上存在子网卡等；Step4.如果cn/dn/gtm/cm_server进程存在,但状态为pengding，则说明可能是在做redo，可通过查看堆栈来确认。3.3      节点实例未停止Step1. 首先使用如下命令找到未正常停止的实例：gs_ssh -c 'ps -ef|grep /opt/huawei/Bigdata/mppdb/core/bin/ | grep -v grep'Step2.1 实例未被停止分为两种情况，一种是实例收到停止信号，但是无法停止，这种现象主要体现在CN、DN正在执行业务，无法停止。当CN、DN无法停止的时候，需要搜集CN、DN堆栈，用于定位问题；Step2.2 第二种是执行停止的命令异常，此时请查看cma日志，手动拆解停止的shell命令，查看那些命令异常，一般为pstree命令异常。当pstree命令等shell命令异常时，分为两种情况：1）系统不存在该命令，请安装该命令，或者查看环境变量是否正确；2）系统pstree结果不符合预期，请更新该命令版本。4      集群启停问题常见案例4.1      整节点未启动，om_monitor进程不存在问题现象：启动集群时整节点未启动，对应节点上om_monitor进程不存在定位过程：omm用户登录到到未启动的节点，使用以下命令确认om_monitor进程不存在：ps –eaf | grep om_monitor4.1.1        Om_monitor定时任务未挂载场景描述：使用如下命令查看启动om_monitor的定时任务是否挂载到cron服务上，如果未挂载上，则是安装失败或定时任务被删除。通过 crontab服务可以看到如下命令，代表om_monitor服务挂载成功。crontal -l解决方法：参照正常节点将om_monitor定时任务服务添加到omm用户的定时任务中。4.1.2        Omm用户密码超期场景描述：使用如下命令检查是否设置了omm用户密码超期时间且密码已过期，如果密码超期会导致omm用户定时任务无权限查看，进而导致无法拉起om_monitor进程。chage -l omm解决方法：使用如下命令将omm用户密码超期时间设置为永不过期chage -M 99999 omm4.2      整节点未启动，cm_agent进程不存在问题现象：整节点未启动，om_monitor进程存在，但cm_agent进程不存在定位过程：omm用户登录到未启动的节点，使用以下命令确认cm_agent进程不存在：ps –eaf | grep cm_agent4.2.1        启停标志文件存在场景描述：检查om_monitor日志中是否有如下格式的日志打印，如果有说明cgroup未挂载成功，导致CMA拉起异常can't get the *cgroup*解决方法：重新挂载cgroup。4.2.2        启停标志文件存在场景描述：检查bin目录下启停标志文件是否存在，如果存在说明FIM界面启动命令未下发到后端ll /opt/huawei/Bigdata/mppdb/core/bin/cluster_manual_start解决方法：1、  删除此文件即可从后台自动拉起该节点实例；2、  FIM界面启动命令未下发到内核原因可排查分析该节点上如下两个日志文件中的报错信息来确认/var/log/Bigdata/mpp/scriptlog/prestart.log/var/log/Bigdata/mpp/scriptlog/start.log4.2.3        Python版本过高场景描述：检查节点上python版本为3.x，与数据库默认的2.7不符，FIM界面启动时start.log日志中有如下报错，则说明是python版本过高导致启动异常解决方法：与现场人员确认是否手动升级过python版本或安装了多个版本的python，并让现场人员将节点上默认python版本恢复为2.7版本。4.2.4          环境变量文件为空场景描述：检查/opt/huawei/Bigdata/mppdb/.mppdbgs_profile环境变量文件为空，则说明环境变量文件为空导致FIM界面启动命令未下发到内核         解决方法：从正常节点拷贝一份过来即可。4.2.5        启停标志文件不存在场景描述：检查bin目录下启停标志文件不存在，说明是其它原因导致om_monitor未能启动cm_agent解决方法：收集节点上om_monitor和cm_agent日志进一步分析。4.3      节点内部分实例未启动，cn/dn/gtm/cm_server进程不存在问题现象：节点内部分实例未启动，未启动的cn/dn/gtm/cm_server实例进程不存在定位过程：omm用户登录到实例未启动的节点，使用以下命令确认相应实例进程不存在：ps –eaf | grep gaussdbps –eaf | grep gs_gtmps –eaf | grep cm_server4.3.1        信号量不足导致cn/dn启动异常场景描述： 检查对应cn/dn实例的pg_log日志，如果有如下报错，则说明是信号量不足导致cn/dn启动异常解决方法：1、  使用root用户执行如下命令可以将节点上os参数配置为预期值；/opt/huawei/Bigdata/mppdb/wisequery/script/gs_checkos -i B1 --detail2、建议使用巡检工具对集群进行全面巡检和整改。4.3.2        postgresql.conf配置文件存在无效GUC参数场景描述：检查对应节点上cm_agent和systemcall日志中如果有如下报错，则说明cn/dn的postgresql.conf配置文件中存在无效参数配置/var/log/Bigdata/mpp/omm/cm/cm_agent/cm_agent-YYYY-MM-DD_hhmmss-current.log/var/log/Bigdata/mpp/omm/cm/cm_agent/system_call-YYYY-MM-DD_hhmmss-current.log解决方法：删除postgresql.conf配置文件中无效参数即可。4.3.3        端口号被占场景描述：检查对应节点上cm_agent和systemcall日志中如果有如下报错，则说明cn/dn/cm_server/gtm的端口号被占/var/log/Bigdata/mpp/omm/cm/cm_agent/cm_agent-YYYY-MM-DD_hhmmss-current.log/var/log/Bigdata/mpp/omm/cm/cm_agent/system_call-YYYY-MM-DD_hhmmss-current.log Port 25308 is used, run 'netstat -anop|grep 25308' or 'lsof -i:25308'(need root) to see who is using this port.解决方法：1、  使用如下命令找到占用端口的进程netstat -anop|grep portlsof -i:port （root执行）2、  kill -9清理掉占用端口的进程，然后重新启动。4.3.4        Lvs虚拟ip未挂载场景描述：cn的listen_addresses参数中配置了lvs虚拟ip，但cn节点上lvs虚拟ip未正常挂载，则也会导致cn启动不了检查cn实例listen_addresses配置命令：cat /srv/BigData/mppdb/data1/coordinator/postgresql.conf|grep listen_addresses查看节点上ip信息命令：/sbin/ifconfig解决方法：使用如下命令重新挂载lvs虚拟ipsh /etc/init.d/gs_vip start4.3.5          进程listen端口号锁文件残留场景描述：机器异常掉电重启等情况下可能会导致进程listen端口号锁文件残留，这样当重新启动时会因锁文件已存在而无法启动。检查锁文件命令：ls -la  /opt/huawei/Bigdata/mppdb/mppdb_tmp检查查出来的锁文件产生时间是否是在启动时间之前，如果是则说明是之前残留的。解决方法：将残留的锁文件删除。4.3.6        Cn/dn的listen_addresses中存在无效ip场景描述：cn/dn的postgresql.conf配置文件的listen_addresses参数存在无效ip时会导致cn/dn无法正常启动，system_call日志中会有如下报错：FATAL:  could not create listen socket for "100.185.180.62"/var/log/Bigdata/mpp/omm/cm/cm_agent/system_call-YYYY-MM-DD_hhmmss-current.log检查cn实例listen_addresses配置命令：cat /srv/BigData/mppdb/data1/coordinator/postgresql.conf|grep listen_addresses解决方法：将listen_addresses参数中的无效ip删除。4.3.7        数据目录无权限场景描述：cn/dn/gtm/cm_server的数据目录权限预期是700，当权限不足时cm_agent日志中会有如下报错：data path disc writable test failed, /srv/BigData/mppdb/data3/slave1解决方法：根据报错提示修复cn/dn/gtm/cm_server数据目录的权限。4.3.8        磁盘满场景描述：节点上数据盘、日志盘等满均会导致cn/dn/gtm/cm_server进程启动异常。磁盘使用率检查命令：df -lh解决方法：清理释放磁盘空间，消除磁盘满。4.4      节点内部分实例未启动，查看状态CN、DN、GTM实例状态为down或者unknown启动集群失败，后台查看集群状态，发现CN、DN、GTM实例显示down或者unknown。4.4.1        当前节点与主cm_server节点网络不通场景描述：当节点与主cm_server节点网络不通时，当前节点cm_agent无法将实例状态上报给cm_server，导致实例状态显示为down或unknown。检查当前节点与主cm_server节点网络命令：在当前节点上ping 主cm_server节点ip，如果不能ping通则说明网络异常。解决方法：联系网络侧人员解决网络问题。4.4.2        Cm_server无主场景描述：当集群中两个cm_server实例均为pending状态，没有选出主时，无法对DN状态进行仲裁，导致DN状态均显示为down或unknown。检查当前集群cm_server状态命令：cm_ctl query -vCd|grep cm_server 解决方法：收集主备cm_server日志并联系研发人员处理。4.4.3        节点上存在多个om_monitor进程场景描述：当节点上存在多个om_monitor进程时，会导致cm_agent进程反复被杀，无法持续向cm_server上报实例状态，进而导致节点上实例状态显示为down或unknown。检查当前节点om_monitor个数命令：ps -ef|grep om_monitor|grep -v grep 解决方法：kill掉当前所有om_monitor进程待起自动重新拉起。 

【验证场景】创建表course：DROP TABLE IF EXISTS course;CREATE TABLE course (  student_id int,  course varchar(20));插入数据：INSERT INTO course VALUES ('1', '标题');INSERT INTO course VALUES ('2', '标题');INSERT INTO course VALUES ('3', '标题');创建表student：DROP TABLE IF EXISTS student;CREATE TABLE student (  id int,  name varchar(20));插入数据：INSERT INTO student VALUES ('1', 'lily');INSERT INTO student VALUES ('2', 'lucy');INSERT INTO student VALUES ('3', 'nacy');INSERT INTO student VALUES ('4', 'hanmeimei'); 执行查询语句1：select name from course;执行查询语句2：select * from student where name in (select  name from course); 【问题描述】name字段在内表中不存在,但是在外表中存在，子查询中有个不存在的列，不报错。【问题分析】分别在GaussDB  for dws ，postgresql  ，mysql  中验证此场景1.         dws中验证如下创建测试表及插入数据：\d+查看表结构执行SQL1：执行SQL2： 2.         Postgresql  中验证如下Postgresql 版本：10.11创建测试表及插入数据：\d+查看表结构执行SQL1：执行SQL2： 3.         mysql  中验证如下mysql 版本：5.5.40创建测试表及插入数据：DROP TABLE IF EXISTS `course`;CREATE TABLE `course` (  `student_id` int(11),  `course` varchar(20)) ENGINE=MyISAM DEFAULT CHARSET=utf8; INSERT INTO `course` VALUES ('1', '标题');INSERT INTO `course` VALUES ('2', '标题');INSERT INTO `course` VALUES ('3', '标题'); DROP TABLE IF EXISTS `student`;CREATE TABLE `student` (  `id` int(11),  `name` varchar(20)) ENGINE=MyISAM DEFAULT CHARSET=utf8; INSERT INTO `student` VALUES ('1',      'lily');INSERT INTO `student` VALUES ('2',      'lucy');INSERT INTO `student` VALUES ('3',      'nacy');INSERT INTO `student` VALUES ('4',      'hanmeimei'); 查看表数据执行SQL2：  【结论】1．dws  postgresql mysql中具有相同的执行结果。2.   在计算子查询时，它开始在本地查找以解析列名。如果失败免责转到外部范围，直到找到具有该名称的列或失败为止。即一般规则是语句中的列名由FROM 子句中引用的表隐式地限定在同一级别。如果子查询的FROM 子句中引用的表中不存在列，则由外部查询的FROM 子句中引用的表隐式地限定列。

问题现象执行创建OBS外表的SQL语句时，返回OBS错误信息，提示访问被拒绝“Access Denied”。原因分析l 创建OBS外表语句中的访问密钥AK和SK错误，会出现如下所示的错误信息：ERROR:  Fail to connect OBS in node:cn_5001 with error code: AccessDeniedl 账户OBS权限不足，对OBS桶没有读、写权限，会出现如下所示的错误信息：dn_6001_6002: Datanode 'dn_6001_6002' fail to read OBS object bucket:'obs-bucket-name' key:'xxx/xxx/xxx.csv' with OBS error code:AccessDenied message: Access Denied默认情况下，您不具备访问其他账号的OBS数据的权限，此外，IAM用户（相当于子用户）也不具备访问其所属账号的OBS数据的权限。处理方法l 创建OBS外表语句中的访问密钥AK和SK错误请获取正确的访问密钥AK和SK，写入创建OBS外表的SQL语句中。获取访问密钥的步骤如下：a. 登录DWS管理控制台。b. 将鼠标移至右上角的用户名，单击“我的凭证”。c. 进入“我的凭证”后，在左侧导航树单击“访问密钥”。在访问密钥页面，可以查看已有的访问密钥ID（即AK）。d. 如果要同时获取AK和SK，单击“新增访问密钥”创建并下载访问密钥。l 账户OBS权限不足，对OBS桶没有读、写权限您必须给指定的用户授予所需的OBS访问权限：− 通过OBS外表导入数据到DWS时，执行导入操作的用户必须具备数据源文件所在的OBS桶和对象的读取权限。− 通过OBS外表导出数据时，执行导出操作的用户必须具备数据导出路径所在的OBS桶和对象的读取和写入权限。//认证用的ak和sk硬编码到代码中或者明文存储都有很大的安全风险，建议在配置文件或者环境变量中密文存放，使用时解密，确保安全

GaussDB(for MySQL)数据库在写入性能上，在业界同类产品中是最好的，这主要得益于GaussDB(for MySQL)在MySQL内核方面的诸多优化。其中有一项从“送快递”得来灵感的优化——事务异步提交，值得我们分析。背景我们先来看看MySQL 8.0的事务提交的大致流程图1 MySQL 8.0事务执行流程以上流程，是MySQL8.0对WAL原则的一种实现，这个流程意味着，任何一个事务的提交，一定要完成write buffer和flush to disk流程。然而那么这个流程中，有一个问题：每个服务器的CPU是有限的，服务器能处理的Thread也是有上限的，那么当我们的业务的并发数量，远远大于我们服务器能并行处理的数量时，那么后来的事务，只能等待前面的事务提交后才能被处理。在这之前，他们什么也做不了。因此，在大并发场景下，如何进一步提升线程的使用率，是大并发事物写入的一个关键。灵感来源于生活一个优化，并不是凭空想象出来的，有时候，往往来源于现实生活。下面，我们先来看看我们身边，和事务提交流程非常类似的一个例子：快递。现在的快递配送，一般一个快递员会负责一片区域，快递刚开始兴起时，数量不多，那么一个快递员基本上可以在规定时间内完成配送。图2 过去的快递配送但是，随着快递数量越来越多，一个快递员要在一个小区配送很长的时间，才能到下一个小区，常常导致了快递员无法准时的配送。在这个问题的催动下，随后，一个新的行业开始出现 – 快递驿站。图3 现在的快递配送快递的优化原理接下来，让我们来看下，快递驿站究竟解决了什么问题。快递的配送过程中，最耗时的，不是装货，不是卸货，而是电话和等待。配送一个小区的时间，取决于这个最后一个来取快递的人的时间，在最后一个人取完快递钱，快递员除了打电话，做不了其他任何事情（也没有办法通知下一个小区的人，因为最后一个人来取得时间是无法确定的）。那么这个等待的时间，对于快递员来说，就是一种浪费。快递驿站可以很大程度解决这个问题，快递员到了以后，只需要将快递卸货，即可前往下一个小区，剩下的事情，就可以由驿站的人员来完成，大大提升了快递员的配送效率。分析回过头来，我们看看数据库，如果把Transaction线程看做快递员，存储上的文件看做取快递的人，那么我们会发现两者有非常大的相似性。那么我们可以像快递配送优化那样去优化事务的处理流程吗？答案是可以的。图4 事务处理和快读配送非常类似根据快递驿站的优化原理，我们知道，快递驿站帮快递员免去了等待客户取货的时间，那么事务处理过程中，有没有等待的过程呢？答案是有的，存储的IO就是一个较长的等待。数据库使用经验丰富的开发人员来都知道，等待redo日志写入存储的磁盘IO性能，很大程度上决定了数据库的写入性能。对于现代数据库来说，尤其对于GaussDB(for MySQL)这样计算于存储分离的数据库，存储的IO耗时，在事务处理的总耗时中，占据了不小的比例，虽然有log buffer的合并写入，提升并发情况下的整体吞吐，但是如果在等待IO的这段时间中，这些线程能够去做别的事情（例如处理等待中的其他事务）。那么将会有进一步的性能提升。GaussDB(for MySQL)的优化既然找到了等待的点，那么我们就可以像快递配送的优化方法，为数据库，也创造一个“快递驿站”，让“快递驿站”来做等待的事情，而事务线程就可以去处理其他等待中的事务，让CPU不会“闲下来”。图5 GaussDB(for MySQL)的“快递驿站”如图5所示，GaussDB(for MySQL)当redo日志的flush to disk动作完成后，即可进行事务提交，但是此时并不应答客户端，而是直接处理下一个事务。同时使用少量”post comit worker线程”，来批量等待日志写入完成（等待的过程其实并不占用CPU），并应答客户端，这就可以让“等待”和“下一个事务的处理”并行化，让CPU“闲不下来”。实际测试图6 Sysbench write only 模型下写入性能测试根据实际测试，在标准的sysbench写入模型下，没有使用Post Commit时，极限性能是35万QPS左右，而使用Post commit后，可以到大42万以上的QPS，提升了20%的写入性能。

给大家推荐一个GaussDB在线题库，不过与考试没有直接关系，可以测试下技能掌握程度，测试完会有打分。GaussDB T 数据库入门测试 https://www.modb.pro/exam/11

给大家推荐一个GaussDB在线题库，不过与HCIP考试没有直接关系，可以测试下技能掌握程度，测试完会有打分。GaussDB T 数据库入门测试 https://www.modb.pro/exam/11?hw

2020年3月5日，墨天轮社区开展的直播课程——《从安装入手学习GaussDB T - 恩墨学院名师精品课》已顺利结束，本文整理了在直播活动过程中同学们和演讲老师的精彩问答，希望能对大家的学习有所帮助。问：课件 PPT 哪里可以下载呢？答：课件《从GaussDB T的安装来学习高斯数据库1.0》下载地址：https://www.modb.pro/doc/2454?hw问：有GaussDB T安装包吗？答：目前华为没有正式发布，暂时还无法公开下载。问：安装GaussDB对内存有什么要求吗？答：官方推荐每个数据库实例需8G内存。每个实例最小需218M问：如果搭建sharding两条虚拟机可以吗？我只有8G的内存。答：单机可以装上，但是没有太大意义；最少3台，一般4台为好。问：GaussDB支持国产其他芯片吗？？答：华为TaiShan服务器 鲲鹏920芯片问：GaussDB可以命令行安装么？答：目前数据库使用命令行安装问：这个gaussDBT 跟GaussDB_200_6.5.1_RHEL.tar.gz 和FusionInsight_MPPDBMonitor_6.5.1_RHEL.tar.gz 有啥不一样？答：GaussDB T （OLTP） - 前身是GaussDB 100，华为公司自主研发的分布式数据库，基于华为公司在2007年开始研发并在电信计费领域规模商用的自研内存数据库全面改造，支持x86和华为Kunpeng硬件架构，基于创新性数据库内核。GaussDB A （OLAP） - 前身是GaussDB 200，一款具备分析及混合负载能力的分布式数据库，从2011年开始，基于PostgreSQL 9.2.4的基础上自主研发，支持x86和华为Kunpeng硬件架构，支持行存储与列存储，提供PB(Petabyte)级数据分析能力、多模分析能力和实时处理能力，用于数据仓库、数据集市、实时分析、实时决策和混合负载等场景。问：bashrc 是gaussDB特定的吗？ 可以自己创建bash_profile答：操作系统的问：GaussDB有没有基于日志的实时解析的工具，类似logminer的？答：log/oper日志就记录了对数据库的操作语句问：高斯有认证吗？如何收费？答：有的，参考 https://e.huawei.com/cn/talent/#/admin/productDetails?certifiedProductId=217&authenticationLevel=CTYPE_CARE_HCIP&technicalField=PSC&version=1.0问：有没有银行核心在高斯上跑的案例？是用的分布式的吗？答：有的，招行问：怎么能加到GaussDB的群?答：可以加QQ群：640663596观看课程视频：https://www.modb.pro/course/42