我们也可以添加 WHERE 子句。下面的例子通过从 "Persons" 表中提取居住在 "Beijing" 的人的信息，创建了一个带有两个列的名为 "Persons_backup" 的表：SELECT LastName,FirstnameINTO Persons_backup FROM PersonsWHERE City='Beijing'SQL SELECT INTO 实例 - 被连接的表从一个以上的表中选取数据也是可以做到的。下面的例子会创建一个名为 "Persons_Order_Backup" 的新表，其中包含了从 Persons 和 Orders 两个表中取得的信息：SELECT Persons.LastName,Orders.OrderNoINTO Persons_Order_BackupFROM PersonsINNER JOIN OrdersON Persons.Id_P=Orders.Id_P

SQL SELECT INTO 语句可用于创建表的备份复件。SELECT INTO 语句SELECT INTO 语句从一个表中选取数据，然后把数据插入另一个表中。SELECT INTO 语句常用于创建表的备份复件或者用于对记录进行存档。SQL SELECT INTO 语法您可以把所有的列插入新表：SELECT * INTO new_table_name [IN externaldatabase]  FROM old_tablename或者只把希望的列插入新表：SELECT column_name(s) INTO new_table_name [IN externaldatabase]  FROM old_tablenameSQL SELECT INTO 实例 - 制作备份复件下面的例子会制作 "Persons" 表的备份复件：SELECT *INTO Persons_backup FROM PersonsIN 子句可用于向另一个数据库中拷贝表：SELECT *INTO Persons IN 'Backup.mdb' FROM Persons如果我们希望拷贝某些域，可以在 SELECT 语句后列出这些域：SELECT LastName,FirstNameINTO Persons_backup FROM Persons

下面我们就分别讲述，虽然说的是Insert语句， 但是Select、Update、Delete语句都是一样的。假如有下述表格：         mytabe         字段1    username     字符串型（姓名）         字段2    age          数字型（年龄）         字段3    birthday      日期型（生日）         字段4    marry        布尔型（是否结婚，结婚为True，未结婚为False）         字段5    leixing       字符串型（类型）         1．     插入字符串型 假如要插入一个名为张红的人，因为是字符串，所以Insert语句中名字两边要加单撇号，如：          strsql=“Insert into mytable(username) values(‘张红')”       如果现在姓名是一个变量thename，则写成         strsql=”Insert into mytable(username) values(‘” & thename & “')”    这里Insert into mytable(username) values(‘是张红前面的部分，thename是字符串变量，') 是张红后面的部分。将thename变量替换成张红，再用&将三段连接起来，就变成了 strsql=“Insert into mytable(username) values(‘张红')”。如果要插入两个字段，如姓名为“张红”，类型为“学生”        strsql=“Insert into mytable(username,leixing) values(‘张红','学生')”        如果现在姓名是一个变量thename，类型也是一个变量thetype，则写成：          strsql=”Insert into mytable(username,leixing) values(‘” & thename & “','” & thetype & “')”       和第一个例子一样，将thename和thetype替换后，再用连接符，就连接成和上面一样的字符串了。         2．     插入数字型      假如插入一个年龄为12的记录，要注意数字不用加单撇号：        strsql=“Insert into mytable(age) values(12)”          如果现在年龄是一个变量theage，则为：        strsql=“Insert into mytable(age) values(“ & theage & “)”         这里Insert into mytable(age) values(是12前面的部分，theage是年龄变量，)是12后面部分。将theage替换，再用&连接符将三部分连接起来，就变为了和上面一样的字符。       3．     插入日期型   日期型和字符串型类似，但是要将单撇号替换为#号。（不过，access数据库中用单撇号也可以）   strsql=“Insert into mytable(birthday) values(#1980-10-1#)”       如果换成日期变量thedate          strsql=“Insert into mytable(birthday) values(#” & thedate & “#)”      4．     插入布尔型  布尔型和数字型类似：只不过只有两个值 True和False，如：          strsql=“Insert into mytable(marry) values(True)”        如果换成布尔变量themarry      strsql=“Insert into mytable(birthday) values(” & themarry& “)”       5．     综合示例       插入一个姓名为张红，年龄为12的记录        strsql=“Insert into mytable(username,age) values(‘张红',12)”        仔细注意上式：因为姓名是字符串，所以张红两边加了单撇号；年龄是数字，所以没有加单撇号。     如果换成字符串变量thename和数字变量theage，则变为：       strsql=“Insert into mytable(username,age) values(‘” & thename & “',” & theage & “)”    注意上式，总之，替换变量，再连接后要完成和上边一样的字符串。      6．     小窍门        有一位同学摸索出了一个小窍门，要把下面的语句题换成变量的写法：       strsql=“Insert into mytable(username) values(‘张红')”           第一步：先把张红抹去，在原位置加两个引号          strsql=“Insert into mytable(username) values(‘”   “')”           第二步：在中间添加两个连接符&           strsql=“Insert into mytable(username) values(‘” & & “')”          第三步：把变量写在两个连接符之间            strsql=“Insert into mytable(username) values(‘” & thename & “')” -

简单的大表过滤的SQL语句中有一个“in 常量”的过滤条件，常量的个数非常多(约有2000多个)，基表数据量比较大，SQL语句执行不出来。Select * from test where col in(a,b,c,d,XXXX,);执行计划：执行计划中，in条件还是作为普通的过滤条件存在。这种场景下，最优的执行计划应该是将“in 常量”转化为join操作性能更好。问题原因执行计划中，in条件还是作为普通的过滤条件存在。这种场景下，最优的执行计划应该是将“in 常量”转化为join操作性能更好。解决办法qrw_inlist2join_optmode可以控制把“in 常量”转join的行为。默认是cost_base的。如果优化器估算不准，可能会出现需要转化的场景没有做转化，导致性能较差。这种情况下可以通过设置qrw_inlist2join_optmode为rule_base来规避解决。

为什么数据库设计很重要？用我们订购衬衫的在线商城网站举例。如今，从网站上订购衬衫的过程似乎很简单，但涉及了很多信息交换。例如：第一次浏览网页时，系统会展示给你一系列信息，包含产品分类，所有可用商品、相应价格、可用尺码、颜色以及其他相关信息。网站会从存储数据的数据库中检索，当用户选中所需商品并继续操作购买时，网站会询问个人详细信息、送货地址、付款详细信息，并确认订单。目前在此过程中产生的新数据，如用户详细信息、订单详细信息、购买及付款都会在同一个数据库中添加及更新。数据库设计很重要，因为对构建可伸缩且能够在高工作负载下运行的软件应用来说，它是至关重要的。设计数据库首先来说，选择数据库软件很关键。目前可用于构建应用的数据库软件有数百种可供选择，我们可以从一些最好的免费数据库软件中选择，之后便是设计符合要求的数据库了。下面列出了10个最优的数据库设计实践。数据库设计的10个最佳实践将所有人的观点列入考量要设计好的数据库，必须考虑所有相关利益者的观点。在构建数据库之前，先去收集信息，了解他们对数据库的期望以及对数据库的操作熟练度。这样就能得出数据库应当采用的技术水平，以及是否要就数据库的功能来训练用户。选择符合需求的数据库类型数据库有多种类型，选择正确类型则是数据库设计的关键。我们可以将数据库以两种方式分类。一是基于数据库用以定义和操作数据的查询语言。使用SQL的数据库是结构化数据最常用的类型。然而，由于NoSQL数据库的可伸缩性、灵活性和速度更优，它们更适合机器学习、网络分析以及物联网（IoT）使用。第二种分类方式则是基于数据模型。这样分类会有四种类型：关系数据库、分层数据库、网络数据库以及面向对象的数据库。研究数据库的不同类型，并针对应用需求作出选择，这是必要的初始步骤。以一致的方式来定义与标记表和列在定义数据项以及标记表与列时，遵从一致性原则非常重要，可以帮助我们更好地理解数据。命名表与列的最佳实践之一便是使用简单的名字来定义其包含的数据。比如：只需将包含用户名称的列标记为“CustomerName”（“用户名”）即可。应当避免使用复数名（如CustomerNames）、缩写（如CN），并且名称中不得使用空格（如Customer Name）。如果坚持遵守这些规则，则将来的用户在使用数据库时会更容易。规范化是关键数据库的规范化指的是将数据库中的所有信息组织起来，避免数据重复和冗余。简单来说，规范化是将数据打散分配到多个较小的相关表中，而不是统统存在一个大表里。将数据规范化是很好的数据库设计实践，有助于提高效率。但是请确保不要过度规范化，否则将会把数据分散到太多的小表中，反而造成混乱。数据库设计的文档化很重要事实上，文档化并非人见人爱，因为实在太烦了。但要记得，文档化对于良好的数据库设计至关重要，可以追踪所有的小细节。数据库设计应当附有指示说明、ER图、存储过程及所有其他相关的信息。文档还应当为编程者和终端用户提供足够信息量，确保他们能够理解并使用。隐私是首要考量很多时候，存储在数据库中的信息是加密信息，隐私就成了一个值得关注的问题。为了获得最大程度的安全性，我们应当对密码加密，使用身份验证来限制数据库的访问，并使用另一个服务器来存放数据库，而不是应用所在的服务器。这将确保你的数据不受攻击和隐私侵犯的威胁。考虑长期需求优秀的数据库设计应当具备可伸缩性，即：在使用量增加的情况下，仍然能承受较高的工作负载，并保障应用的运行。对工作量可能会有所改变的企业来说，在设计数据库时牢记此项至关重要。例如：如果一个电子商务网站预计当销售量增长时，访客会在一个月内急速增加，那么在设计数据库时应当将这一点列入考量，以便数据库可以响应迅速增长的访客，并保持在高工作负载的情况下运作。代码以及使用预存程序数据库设计中的常见错误之一，就是不使用预存程序。预存程序指的是，在操作数据时手边随时可用的提前预存代码串。例如，如果有个SQL查询是常用的操作指令，则将它提前写入预存程序，而不是在用的时候重新来写，就会让工作简单起来。一旦有了预存程序，就可以在需要时一步执行并载入这个SQL查询了。编写大量预存程序是个吃力的工作，但如果花时间完成并用文档记录下来的话，对终端用户来说，使用数据库就更加轻松了。在数据库建模和设计上投入时间优秀数据库设计的专业技巧之一是在数据库建模和设计上投入时间和精力。开发者常见的错误就是忽略这一步以节省时间，将重点放在软件开发更重要的其他方面上。但是，数据库设计对于保障应用的功能来说非常关键。如果一味想节省时间，不仔细思考设计的话，未来就会需要花费更多时间来维护数据库，甚至重新设计。测试设计测试也是数据库设计很关键的步骤，而且经常会被疏忽对待，甚至完全跳过，只为了赶DDL。我们应当在发布项目前，花些时间来彻底测试数据库设计，以确保其满足了所有计划中的需求，且正常运行。结语对于以数据为中心的项目来说，数据库设计极为重要，开发过程中我们也应当慎重对待。文中提到的数据库设计实践，如针对长期需求进行适当的计划，选择正确的数据库类型，使用一致性的名称与标签，数据规范化，数据库设计文档化，并提前测试，这些都是我们在设计优秀数据库时需要考虑的关键问题。

1、首先观察SQL语句中有not in 语法2、执行计划中有NestLoop3、NestLoop是导致语句性能慢的主要原因。Hashjoin只能做等值关联。NestLoop的条件中有or条件，所以无法用Hashjoin求解。导致出现这个现象的原因是由not in的语义决定的(具体可以baidu下not in 和 not exists的介绍)。4、因此上述语句可以通过修改将not in 修改为not exists就可以解决这个问题。

    一.本案例适合什么场景？1.集群操作系统为SUSE12.32.现象可能为CN实例异常重启3.现象可能为连接CN hung4.现象可能为sql执行慢，或长时间执行无结果    二.如何确定是该问题？1.cn日志failed to join thread xxx, ret is 110, Connection timed out2.选择一条hung住的sql，查询等待视图中该sql的信息select * from pgxc_thread_wait_status where query_id = 'xxxxxxxxxxx'; --xxx为该sql的query_id，可以从pg_stat_activity查到根据等待视图，可以得到分析结果如下a.该sql关联3个线程，1个cn线程，2个dn线程b.根据ptid字段，可以判断，236774（第二行）的父进程id为294563（第三行的lwtid）c.根据wait_status字段，cn在等待dn，dn子线程等待父线程结束，父线程为none，进程卡在这里长时间不释放wait_status字段值具体含义wait node等待接收与某节点的连接上的数据synchronize quit等待stream线程组内的线程统一退出none没在等任意事件3.对卡住的线程抓堆栈 gstack 294563（等待视图lwtid字段）以下堆栈信息#1行 in __lll_lock_elision ()为os加锁，则数据库省略加锁Thread 28 (Thread 0x7f7abbb61700 (LWP 51263)):#0  0x00007f7bd5c52b7c in __lll_lock_wait () from /lib64/libpthread.so.0#1  0x00007f7bd5c55520 in __lll_lock_elision () from /lib64/libpthread.so.0#2  0x0000560c90d29e80 in WLMReserveGlobalActiveStatement() ()#3  0x0000560c90d2a051 in WLMReserveAcstatement(ParctlType) ()#4  0x0000560c90a84c6c in exec_simple_query(char const*, MessageType, StringInfoData*) ()#5  0x0000560c90a8903d in PostgresMain(int, char**, char const*, char const*) ()#6  0x0000560c9092acfe in SubPostmasterMain(int, char**) ()#7  0x0000560c9092bc85 in MainStarterThreadFunc(void*) ()#8  0x00007f7bd5c4b724 in start_thread () from /lib64/libpthread.so.0#9  0x00007f7bd598aeed in clone () from /lib64/libc.so.6Thread 27 (Thread 0x7f7abcb62700 (LWP 51257)):#0  0x00007f7bd5c52b7c in __lll_lock_wait () from /lib64/libpthread.so.0#1  0x00007f7bd5c55520 in __lll_lock_elision () from /lib64/libpthread.so.0#2  0x0000560c90d29e80 in WLMReserveGlobalActiveStatement() ()#3  0x0000560c90d2a051 in WLMReserveAcstatement(ParctlType) ()#4  0x0000560c90a84c6c in exec_simple_query(char const*, MessageType, StringInfoData*) ()#5  0x0000560c90a8903d in PostgresMain(int, char**, char const*, char const*) ()#6  0x0000560c9092acfe in SubPostmasterMain(int, char**) ()#7  0x0000560c9092bc85 in MainStarterThreadFunc(void*) ()#8  0x00007f7bd5c4b724 in start_thread () from /lib64/libpthread.so.0#9  0x00007f7bd598aeed in clone () from /lib64/libc.so.6Thread 26 (Thread 0x7f7abe5e3700 (LWP 51221)):#0  0x00007f7bd5c52b7c in __lll_lock_wait () from /lib64/libpthread.so.0#1  0x00007f7bd5c55520 in __lll_lock_elision () from /lib64/libpthread.so.0#2  0x0000560c90d29e80 in WLMReserveGlobalActiveStatement() ()#3  0x0000560c90d2a051 in WLMReserveAcstatement(ParctlType) ()#4  0x0000560c90a84c6c in exec_simple_query(char const*, MessageType, StringInfoData*) ()#5  0x0000560c90a8903d in PostgresMain(int, char**, char const*, char const*) ()#6  0x0000560c9092acfe in SubPostmasterMain(int, char**) ()#7  0x0000560c9092bc85 in MainStarterThreadFunc(void*) ()#8  0x00007f7bd5c4b724 in start_thread () from /lib64/libpthread.so.0#9  0x00007f7bd598aeed in clone () from /lib64/libc.so.64.满足以上排查条件，可以初步判断是本次案例说明的问题，可采用下文解决手段    三.问题根因以及如何解决，见详细分析https://bbs.huaweicloud.com/forum/thread-94892-1-1.html

Flink SQL> SELECT 'Hello World';>[ERROR] Could not execute SQL statement. Reason:java.lang.NoSuchMethodError: scala.collection.JavaConversions$.deprecated$u0020seqAsJavaList(Lscala/collection/Seq;)Ljava/util/List;

【功能模块】运行  bin]$ ./sql-client.sh   embedded报错了[ERROR] Unknown or invalid SQL statement.【操作步骤&问题现象】1、2、CREATE TABLE pvuv_sink (>     dt VARCHAR,>     pv BIGINT,>     uv BIGINT> ) WITH (>     'connector.type' = 'jdbc',>     'connector.url' = 'jdbc:mysql://localhost:3306/flink-test',>     'connector.table' = 'pvuv_sink',>     'connector.username' = 'root',>     'connector.password' = '123456',>     'connector.write.flush.max-rows' = '1'> );[ERROR] Unknown or invalid SQL statement.【截图信息】【日志信息】（可选，上传日志内容或者附件）

内存问题常用定位视图目前，GaussDB DWS对外提供诸多系统视图，可以用来辅助内存问题的分析定位，常用视图及用法说明如下表所示。（☆代表常用程度）pv_total_memory_detail ☆☆☆☆☆查询当前实例上整体内存使用状态和信息，可以看到各类型内存使用情况，来对当前实例上内存使用情况做一个概要的判断。SELECT * FROM pv_total_memory_detail;返回结果如下：表1 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当前内存上下文中已使用的内存总数，单位字节。内存问题定位方法及解决措施Memory is temporary unavailable问题当出现memory is temporary unavailable报错后，首先确认是哪个实例报错，是CN还是DN。使用gsql登录到报错的实例上，查询pv_total_memory_detail，重点查看以下信息：当前是否还存在内存不足问题。方法为查看process_used_memory和max_process_memory的关系，如已经大于或比较接近，则说明当前内存使用已经或即将超限。如明显小于，则说明占用内存大的语句已经跑完或者被杀掉。当前系统已经恢复。这时可查看对应的peak_memory值，如peak_memory值过高，说明确实曾经出现过内存使用过大。当前是哪个类型的内存过大。最常见的是dynamic_used_memory过大，说明动态申请的内存过大，这类问题可能和客户正在运行的SQL强相关。如通过2发现当前内存占用仍过高，则进一步使用pv_session_memory_detail继续分析，看内存占用过高是哪个内存上下文引起的。视图中有线程号信息及内存上下文信息，通过这些信息可以判定是什么语句的什么操作占用了过多内存，进而可以cancel此语句，并给客户提出语句优化建议常见语句问题为：SQL不下推。如内存问题在CN上出现，很大程度上是因为某个SQL的不下推导致。通过explain确认语句不下推后，将语句进行修改使其下推。中间结果集倾斜。GaussDB DWS在进行表关联时，优先使用hash join，需要对一张表创建哈希表，当哈希表大小超过work_mem限制时，会进行下盘避免内存占用过多，但如果原始表里或中间结果集中在join列上存在大量重复数据，是无法下盘的，必须全部载入内存中进行计算，会造成内存大量占用。如pv_session_memory_detail中占用内存最大的内存上下文为hash context，则大概率是此问题。这时应对客户的表和SQL进行分析，对重复值进行处理后，再进行关联。如通过3没有发现内存占用过高的单个语句，但系统整体内存占用仍过高，则问题原因为参数配置不合理或用户语句并发设置不合理。局点上线后，或局点业务量增大后频繁报内存不足，很可能是因为max_active_statements设置过高，高并发的语句加起来后超出了系统可用内存上线，此时如检查第一点中参数都合理后，应将max_active_statements调小，让语句排序进行，避免一起运行时报错。局点新上业务后报内存不足，很可能是因为新业务较为复杂，有多个表join、sort或group by。此时如分析不存在中间结果集倾斜，则需要将并发调小，或将work_mem调小。以上操作都可能导致业务响应时间变长，需要和客户确认。max_process_memory设置过小，导致内存不能充分利用而提前报错。shared_buffer/cstore_buffer设置过大：shared_buffer设大可以增大缓存空间，提高数据读取效率，但如设置过大，会导致语句运行时无法申请到足够的动态内存，导致报错。work_mem/maintainence_work_mem设置过大：在高并发场景下，work_mem设置过大可能导致所有语句的work_mem加起来超过可用动态内存的最大值，从而导致报错。参数配置不合理。需评估系统关键内存参数是否设置合理。如用户将POC环境直接转为生产。POC环境为了追求极致性能，一般内存参数设置比较激进。而生产系统需要长期稳定运行，内存参数设置应相对保守，此时应调整相关参数。语句并发设置不合理。此问题与参数配置不合理问题相关。语句并发高，则内存参数配置应较小；反过来说，如内存参数配置较大，则可支撑的语句并发也就相应的要变低。如分析时已没有现场，则有3个方法来确认什么语句导致了问题。 到报错的节点日志中搜索全部memory is temporary unavailable报错，分析可能是哪个语句导致的。重新让客户运行业务，或等下次业务高峰期时进行分析。打开active sql。打开后会将内存相关信息记到系统表中。执行如下语句打开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分析方法如下： 查询2018-11-9峰值内存使用top10的SQL。SELECT * FROM pgxc_wlm_session_info WHERE start_time like '%2018-11-9%' ORDER BY nodename,max_peak_memory DESC limit 10;查询2018-11-9CPU使用top10的SQL。SELECT * FROM pgxc_wlm_session_info WHERE start_time like '%2018-11-9%' ORDER BY nodename,total_cpu_time DESC limit 10;查询2018-11-9查询时间最长的top10的SQL。SELECT * FROM pgxc_wlm_session_info WHERE start_time like '%2018-11-9%' ORDER BY nodename,duration DESC limit 10;查询2018-11-9SQL执行失败，错误信息为“memory is temporarily unavailable”且最大峰值内存超过1G的SQL。SELECT * 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;查询不下推的SQL。SELECT * FROM pgxc_wlm_session_info WHERE start_time like '%2018-11-9%' and query_plan like ‘%_REMOTE_TABLE_QUERY_ %’;查询不下盘的SQL。SELECT * FROM pgxc_wlm_session_info WHERE start_time like '%2018-11-9%' and warning like‘%spill%’;操作系统OOM问题查看/var/log/messages目录下的OS日志，搜索oom-killer，确认是否为gaussdb进程触发的OOM。分析数据库内存参数，确认设置是否合理，特别是max_process_memory。查看集群配置情况和关键参数常用语句集群每个物理节点内存、每个节点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 ;监控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;监控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 ;监控当前实例总totalsize memroy大小。SELECT pg_size_pretty(sum(totalsize)) FROM pv_session_memory_detail;监控当前实例总usedsize memroy大小。SELECT pg_size_pretty(sum(usedsize)) FROM pv_session_memory_detail;监控当前实例内存总体使用情况。SELECT * FROM pg_total_memory_detail;监控共享内存实时使用情况。SELECT * FROM pg_shared_memory_detail;

一、传统binlog主从复制，跳过报错方法mysql> stop slave;mysql> set global sql_slave_skip_counter = 1;mysql> start slave;mysql> show slave status \G二、GTID主从复制，跳过报错方法mysql> stop slave； #先关闭slave复制；mysql> change master to ...省略... #配置主从复制；mysql> show slave status\G #查看主从状态；发现报错：mysql> show slave status\G*************************** 1. row ***************************        Slave_IO_State: Waiting for master to send event         Master_Host: 172.19.195.212         Master_User: master-slave         Master_Port: 3306        Connect_Retry: 60       Master_Log_File: mysql-bin.000021     Read_Master_Log_Pos: 194        Relay_Log_File: nginx-003-relay-bin.000048        Relay_Log_Pos: 454    Relay_Master_Log_File: mysql-bin.000016       Slave_IO_Running: Yes      Slave_SQL_Running: No       Replicate_Do_DB:     Replicate_Ignore_DB:      Replicate_Do_Table:    Replicate_Ignore_Table:   Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table:          Last_Errno: 1007          Last_Error: Error 'Can't create database 'code'; database exists' on query. Default database: 'code'. Query: 'create database code'         Skip_Counter: 0     Exec_Master_Log_Pos: 8769118       Relay_Log_Space: 3500       Until_Condition: None        Until_Log_File:        Until_Log_Pos: 0      Master_SSL_Allowed: No      Master_SSL_CA_File:      Master_SSL_CA_Path:       Master_SSL_Cert:      Master_SSL_Cipher:        Master_SSL_Key:    Seconds_Behind_Master: NULLMaster_SSL_Verify_Server_Cert: No        Last_IO_Errno: 0        Last_IO_Error:        Last_SQL_Errno: 1007        Last_SQL_Error: Error 'Can't create database 'code'; database exists' on query. Default database: 'code'. Query: 'create database code' Replicate_Ignore_Server_Ids:       Master_Server_Id: 100         Master_UUID: fea89052-11ef-11eb-b241-00163e00a190       Master_Info_File: /usr/local/mysql/data/master.info          SQL_Delay: 0     SQL_Remaining_Delay: NULL   Slave_SQL_Running_State:      Master_Retry_Count: 86400         Master_Bind:   Last_IO_Error_Timestamp:   Last_SQL_Error_Timestamp: 201022 09:31:29        Master_SSL_Crl:      Master_SSL_Crlpath:      Retrieved_Gtid_Set: fea89052-11ef-11eb-b241-00163e00a190:8-5617      Executed_Gtid_Set: a56c9b04-11f1-11eb-a855-00163e128853:1-11224,fea89052-11ef-11eb-b241-00163e00a190:1-5614        Auto_Position: 1     Replicate_Rewrite_DB:         Channel_Name:      Master_TLS_Version: 1 row in set (0.01 sec)可以看到 Slave_SQL_Running 为 NO，表示运行取回的二进制日志出了问题；在 Last_Error 中也可以看到大概的报错；（因为我之前的操作，大概可以判断出 是因为主库的二进制日志中有创建code库的sql，而从库上我已经创建了这个库，应该是产生了冲突；）解决方法：1、如果清楚自己之前的操作，可以将从库中产生冲突的库删除；2、或者通过跳过GTID报错的事务的方法--- 通过 Last_SQL_Errno 报错编号查询具体的报错事务mysql> select * from performance_schema.replication_applier_status_by_worker where LAST_ERROR_NUMBER=1007\G*************************** 1. row ***************************     CHANNEL_NAME:      WORKER_ID: 0      THREAD_ID: NULL    SERVICE_STATE: OFFLAST_SEEN_TRANSACTION: fea89052-11ef-11eb-b241-00163e00a190:5615  LAST_ERROR_NUMBER: 1007  LAST_ERROR_MESSAGE: Error 'Can't create database 'code'; database exists' on query. Default database: 'code'. Query: 'create database code' LAST_ERROR_TIMESTAMP: 2020-10-22 09:31:291 row in set (0.00 sec)mysql> stop slave;Query OK, 0 rows affected (0.00 sec)--- 跳过查找到报错的事务（LAST_SEEN_TRANSACTION 的值）mysql> set @@session.gtid_next='fea89052-11ef-11eb-b241-00163e00a190:5615';Query OK, 0 rows affected (0.00 sec)mysql> begin;Query OK, 0 rows affected (0.00 sec)--- 提交一个空的事务，因为设置gtid_next后，gtid的生命周期开始了，必须通过显性的提交一个事务来结束；mysql> commit;Query OK, 0 rows affected (0.00 sec)--- 设置回自动模式；mysql> set @@session.gtid_next=automatic;Query OK, 0 rows affected (0.00 sec)mysql> start slave;Query OK, 0 rows affected (0.00 sec)

添加了jar包之后,还是报错了  NoSuchFieldError: PYFILES_OPTION/FusionInsight/client/HDFS/hadoop/share/hadoop/common/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]Exception in thread "main" java.lang.NoSuchFieldError: PYFILES_OPTION        at org.apache.flink.table.client.cli.CliOptionsParser.getEmbeddedModeClientOptions(CliOptionsParser.java:156)        at org.apache.flink.table.client.cli.CliOptionsParser.<clinit>(CliOptionsParser.java:139)        at org.apache.flink.table.client.SqlClient.main(SqlClient.java:195)

 接着上一个还是   FusionInsight/client/Flink的版本[ERROR] Flink SQL Client JAR file 'flink-sql-client*.jar'这个报错是?./bin/sql-client.sh embedded[ERROR] Flink SQL Client JAR file 'flink-sql-client*.jar' neither found in classpath nor /opt directory should be located in /xxxx/xxxFusionInsightxxx/xxclient/Flink/flink/opt.还要额外放入jar包.  才能跑起来吗?   

本次微话题经华为云数据库创新Lab布道师 Shawn评定，中奖名单公示如下：活动名称奖项名称用户昵称礼品名称【数据库·微话题】“GaussDB(for Influx)时序数据库”知多少，U盘、笔记本、玻璃杯送不停！优质微话题中奖用户好久没出门《华为数据之道》书籍CocoLiu202首先，恭喜各位中奖；其次，请填写收件信息，一定要填正确哈！我们会尽快发出奖品。https://devcloud.huaweicloud.com/expert/open-assessment/qtn?id=579b3d6c200e48c18cf6860c397450ea获奖用户已私信通知，请在3个工作日内（2021年4月1日00:00前）找我领取，过期视为放弃。本期【数据库·微话题】是2021年的第一期微话题活动，特邀华为云数据库创新Lab布道师 Shawn与大家一起讨论“GaussDB(for Influx)时序数据库”知多少，欢迎大家畅言，还有好礼送不停。 专家简介： 华为云数据库创新Lab布道师 ShawnShawn在网络安全、数据库领域等方面有丰富的经验，2017年加入华为CloudBU云数据库创新Lab，主要从事华为云NoSQL服务的研发工作，特别对时序数据库有较深入的了解。=======【数据库·微话题】“GaussDB(for Influx)时序数据库”知多少？=======Part1 今日份微话题：1. 您使用的是什么时序数据库？2. 您的使用场景是什么？3. 您使用的时序数据库有什么优势，有什么不足？4. 您最想了解GaussDB(for Influx)时序数据库什么功能？最想有什么功能？活动时间：2021年2月26日-3月14日参与方式：直接在本帖下方回复以上话题的理解或评论评选方式：活动结束后，将由本次专家根据回复的数量和质量，评选出优质的回复活动奖励：《华为数据之道》书籍、笔记本、U盘、高硼玻璃杯、GAUSSDB字母笔7支/盒有效评论数量奖品名称奖品数量<=200条《华为数据之道》书籍2本>200条《华为数据之道》书籍2+N本高硼玻璃杯每100层，6个中奖名额 注：1)有效评论数是指，和今日份微话题所列举问题相关的内容回复2）书籍可更换为笔记本、U盘3）高硼玻璃杯可更换GAUSSDB字母笔7支/盒奖品展示：Part2【开年采购季】填问卷，0门槛抽奖，100%中奖！移动电源、U盘、懒人手机支架等你哟！提示1.本次活动回帖内容需满足华为云论坛发帖规范 https://bbs.huaweicloud.com/forum/thread-23077-1-1.html。2. 活动结束3个工作日将在此帖公布获奖名单，敬请关注。3. 奖品将在公示期结束后15个工作日内发出。4. 由于获奖用户自身原因（包括但不限于提供的联系方式有误、身份不符或者通知领奖后超过15个工作日未领取等）造成奖品无法发送的，视为获奖用户放弃领奖。5.活动一切解释权归华为云数据库所有。

【功能模块】  SQL on OBS 【操作步骤&问题现象】1、创建Obs server 过程中  region  、 address 、 secret_access_key  应该怎么填写2、哪里可以找到 相关的帮助手册【截图信息】【日志信息】（可选，上传日志内容或者附件）