【摘要】 使用Python连接GaussDB(DWS)的配置步骤及程序编写样例。配置方法：1、安装psycopg2；rpm -ivh python-psycopg2-2.5.1-3.el7.x86_64.rpm2、编写python脚本样例，并赋予执行权限；import psycopg2conn = psycopg2.connect(database="pocdb", user="u1",password="******", host="*.*.*.*", port="25308")cursor = conn.cursor()cursor.execute("DROP TABLE if exists test_conn")cursor.execute("CREATE TABLE test_conn(id int, name text)")cursor.execute("INSERT INTO test_conn values(1,'haha')")cursor.execute("INSERT INTO test_conn values(2,'lala')")cursor.execute("update test_conn set name = 'xixi'")cursor.execute("delete from test_conn where id = 1")conn.commit()cursor.execute("select * from test_conn")rows = cursor.fetchall()for row in rows:    print 'id = ',row[0], 'name = ', row[1], '\n'cursor.close()conn.close()3、执行脚本刷新环境变量：source /opt/huawei/Bigdata/mppdb/.mppdbgs_profilepython test.py4、登录数据库，查验数据；步骤1 连接服务器：*.*.*.*  root/*****，或者直接用omm用户连接，omm/******;步骤2 切换omm用户 ,刷新环境变量；         source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile步骤3 连接数据库；         gsql -d pocdb -p 25308  -U u1 -W ****** -r         执行sql命令，\d+ tablename查看表定义；         \d+ test_conn         查询表数据；         Select * from test_conn;

摘要】 本文介绍使用perl通过ODBC连接GaussDB(DWS)的安装和配置方法使用perl语言连接Gaussdb1 准备本例使用软件如下unixODBC-2.3.0DBI-1.642DBD-ODBC-1.562   安装unixODBC2.1 上传安装包使用root用户上传安装包unixODBC-2.3.0.tar.gz到/tmp下2.2 安装使用root用户安装，执行如下命令cd /tmptar zxvf unixODBC-2.3.0.tar.gzcd unixODBC-2.3.0./configure --enable-gui=no（x86编译命令）./configure --enable-gui=no --build=arm-linux（arm编译命令）makemake install2.3 测试安装结果命令行敲击isql，出现如下结果，表示安装成功2.4  替换驱动程序包解压GaussDB-Kernel-V300R002C00-SUSE11-64bit-Odbc.tar.gz包把odbc/lib下的psqlodbcw.la，psqlodbcw.so 这2个文件拷贝到/usr/local/lib路径下。2.5 添加环境变量使用omm用户，编辑~/.bashrc文件,追加红色内容vi ~/.bashrcexport LD_LIBRARY_PATH=/usr/local/lib/:$LD_LIBRARY_PATHexport ODBCSYSINI=/usr/local/etcexport ODBCINI=/usr/local/etc/odbc.ini 生效环境变量source ~/.bashrc2.6   配置数据源使用root用户，做如下操作。在“/usr/local/etc/odbcinst.ini”文件中追加以下内容。vi /usr/local/etc/odbcinst.ini[GaussMPP]Driver64=/usr/local/lib/psqlodbcw.sosetup=/usr/local/lib/psqlodbcw.so 在“/usr/local/etc/odbc.ini ”文件中追加以下内容。vi /usr/local/etc/odbc.ini[GaussODBC]Driver=GaussMPPServername=10.185.180.123（数据库Server IP）Database=postgres （数据库名）Username=odbc （数据库用户名）Password=Bigdata123@ （数据库用户密码）Port=25308 （数据库监听端口）Sslmode=allow2.7  配置pg_hba.conf文件gs_guc set -Z coordinator -N all -I all -h "host all all 10.185.180.123/32 sha256"2.8  重启集群source /opt/huawei/Bigdata/mppdb/.mppdbgs_profilecm_ctl stopcm_ctl start2.9  创建odbc配置的用户如果用户已经存在，可以忽略此步。登录CNsource /opt/huawei/Bigdata/mppdb/.mppdbgs_profilegsql -d postgres -p 25308 -arcreate user odbc password 'Bigdata123@';2.10 测试isql -v GaussODBC出现如下结果表示配置成功3  安装DBI3.1  上传安装包使用root用户上传安装包DBI-1.642.tar到/tmp下3.2 安装使用root用户安装，执行如下命令cd /tmptar xvf DBI-1.642.tarcd DBI-1.642perl Makefile.PLmakemake install4 安装DBD-ODBC4.1 上传安装包使用root用户上传安装包DBD-ODBC-1.56.tar.gz到/tmp下4.2  安装使用root用户安装，执行如下命令cd /tmptar zxvf DBD-ODBC-1.56.tar.gzcd DBD-ODBC-1.56perl Makefile.PLmakemake install5  Perl脚本连接数据库脚本：use DBI;my $dbh;$dbh = DBI->connect("dbi:ODBC:GaussODBC","odbc","Bigdata123@",{AutoCommit => 1, PrintError => 1, RaiseError => 0, LongReadLen => 1048576});my $sth = $dbh->prepare("select current_time");$sth ->execute();@tabrow=$sth->fetchrow();$result=@tabrow[0];$sth->finish();$dbh->disconnect();print $result."\n";

背景：当前sql多表关联sql性能较差，经分析关联条件已经是分布键，数据分布均匀，统计信息均已收集，想进一步优化可以通过创建PCK进行性能提升。PCK的选取遵循以下原则：•【关注】一张表上只能建立一个PCK，一个PCK可以包含多列，但是一般不建议超过2列。•【建议】在查询中的简单表达式过滤条件上创建PCK。这种过滤条件一般形如col op const，其中col为列名，op为操作符 =、>、>=、<=、<，const为常量值。•【建议】在满足上面条件的前提下，选择distinct值比较少的列上建PCK。1、在已有表结构创建pckALTER TABLE tablename ADD PARTIAL CLUSTER KEY(column name);主表从表均需要增加局部聚簇键，然后对张表执行VACUUM FULL，使局部聚簇生效。2、当pck设置不合理可以用如下语句删除再调整ALTER TABLE tablename DROP CONSTRAINT pckname;3、pckname获取方式可以执行\d+ tablename ,红色部分即pcknamePartial Cluster :    "student1_cluster" PARTIAL CLUSTER KEY (stuno)4、pck紧随where 也可提升性能

我们在学习GaussDB(DWS)的基础知识时都学习了安全环的概念，即GaussDB在数据安全方面采用的是三副本（主，备，从）的安全环方式，那么，大家是否有思考过，一个多节点的集群中最多可以坏几个节点呢？    虽然设计的是三副本，日常使用中至少得保证有两副本可用才不会导致集群不可用。下面分别以3节点2DN和8节点2DN的集群来分析一下这个“最多”我们应该怎么计算。   如果我们采用3节点2DN的方式部署集群的话，三副本的主备从分布图如下：             根据上图，我们以节点1上的主DN为基准，什么损坏情况下这两个DN的数据损坏会导致集群不可用呢？我们假设节点3宕机了，那么，此时DN1的从备和DN2的备份不可用，而在节点2上分别有DN1的备份和DN2的从备，此时仍然保障着两幅本可用，即不会导致集群不可用，只是会导致集群的性能下降。仍然回到DN1和DN2的分布上来，如果再多宕机一台节点，明显可以看到，同理，当我们以DN3和DN4的主为基准时，分析的方法是相同的，即此时节点1和节点3可以任意宕机一个。      综上，我先假设一个计算方法，一个集群中最多可down机的节点个数=节点总数/(dn个数+1)，对应到上面的例子：3/(2+1)=1,即最多可以有一个节点down机。          如果是8节点2DN的集群呢？ 上述公式是否同样适用？ 首先，我们来看8节点2DN的主备从分布图，如下：          上图中我们仍然以DN1和DN2为基准，可以看到节点1到节点4组成了一个安全环，假设节点1down了，那么节点2,3,4就不能再down了；我们接着看，假设节点5down了，那么，节点6,7,8就不能再down了。此时，我们看到节点1和节点5down掉以后，其他节点都不具备down机的条件了，否则就会导致集群不可用。我们看看此时上述公式是否使用？ 节点总数 8/ (dn个数+1) = 8/3约等于2.6， 因为机器没有半台，而我们又不能多down机一台，只能取整数部分。这样来看，上述公式基本适用，但是，需要完善，即取一下整数部分。      综上，个人认为一个集群中最多可down的节点数 =节点总数/(dn个数+1)，然后，取整数。      以上纯属个人观点，如有错误，欢迎指正。

我们知道GaussDB(DWS)为了保证业务的连续性和高可靠性，各个组件都进行了高可用设计。下图是应用访问GaussDB(DWS)的业务流程架构图，对于业务应用或者用户来说，他们发生请求给CN，CN解析并生成执行计划，交给DN去执行，执行后再由CN汇总将数据返回给业务用户或者业务应用。这个过程是容易理解的，本次我们重点关注的是站在CN前面的LVS+KeepAlived。现在的问题是：CN的返回结果是否会经过LVS，然后再返回给前端应用？如果经过LVS，那么，LVS会不会成为单点瓶颈？带着这两个问题我们探究一下LVS和KeepAlived的原理。一、LVS是什么？ LVS是Linux Virtual Server的简称，也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，它的官方站点是www.linuxvirtualserver.org。现在LVS已经是 Linux标准内核的一部分，在Linux2.4内核以前，使用LVS时必须要重新编译内核以支持LVS功能模块，但是从Linux2.4内核以后，已经完全内置了LVS的各个功能模块，无需给内核打任何补丁，可以直接使用LVS提供的各种功能。二、LVS的目的是什么？LVS主要用于服务器集群的负载均衡，拥有VIP，客户端将所有请求发送至此VIP，LVS负责将请求分发到不同的RS，客户不感知RS。其目的是提高服务器的性能，将请求均衡的转移到不同的服务器上执行，从而将一组服务器构成高性能、高可靠的虚拟服务器。 三、LVS的体系结构使用LVS架设的服务器集群系统有三个部分组成：　　（1）最前端的负载均衡层，用Load Balancer表示；　　（2）中间的服务器集群层，用Server Array表示；　　（3）最底端的数据共享存储层，用Shared Storage表示；在用户看来，所有的内部应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务。如图：Load Balancer层：位于整个集群系统的最前端，有一台或者多台负载调度器（Director Server）组成，LVS模块就安装在Director Server上，而Director的主要作用类似于一个路由器，它含有完成LVS功能所设定的路由表，通过这些路由表把用户的请求分发给Server Array层的应用服务器（Real Server）上。同时，在Director Server上还要安装对Real Server服务的监控模块Ldirectord，此模块用于监测各个Real Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除，恢复时重新加入。Server Array层：由一组实际运行应用服务的机器组成，Real Server可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个，每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中，Director Server也可以同时兼任Real Server的角色。Shared Storage层：是为所有Real Server提供共享存储空间和内容一致性的存储区域，在物理上，一般有磁盘阵列设备组成，为了提供内容的一致性，一般可以通过NFS网络文件系统共享数据，但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系统，例如Red hat的GFS文件系统，oracle提供的OCFS2文件系统等。    从整个LVS结构可以看出，Director Server是整个LVS的核心，目前，用于Director Server的操作系统只能是Linux和FreeBSD，linux2.6内核不用任何设置就可以支持LVS功能，而FreeBSD作为Director Server的应用还不是很多，性能也不是很好。对于Real Server，几乎可以是所有的系统平台，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。四、LVS的程序组成部分LVS 由2部分程序组成，包括 ipvs 和 ipvsadm。ipvs(ip virtual server)：一段代码工作在内核空间，叫ipvs，是真正生效实现调度的代码。ipvsadm：另外一段是工作在用户空间，叫ipvsadm，负责为ipvs内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)五、LVS的负载均衡机制1、 LVS是四层负载均衡，也就是说建立在OSI模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS支持TCP/UDP的负载均衡。因为LVS是四层负载均衡，因此它相对于其它高层负载均衡的解决办法，比如DNS域名轮流解析、应用层负载的调度、客户端的调度等，它的效率是非常高的。2、 LVS的转发主要通过修改IP地址（NAT模式，分为源地址修改SNAT和目标地址修改DNAT）、修改目标MAC（DR模式）来实现。 GaussDB(DWS)目前主要采用的是DR(Direct Routing)模式，所以，我们主要聊一聊DR模式。下图是DR模式的一个示意图：DR模式下需要LVS和RS集群绑定同一个VIP（RS通过将VIP绑定在loopback实现），请求由LVS接受，由真实提供服务的服务器（RealServer, RS）直接返回给用户，返回的时候不经过LVS。详细来看，一个请求过来时，LVS只需要将网络帧的MAC地址修改为某一台RS的MAC，该包就会被转发到相应的RS处理，注意此时的源IP和目标IP都没变，LVS只是做了一下移花接木。RS收到LVS转发来的包时，链路层发现MAC是自己的，到上面的网络层，发现IP也是自己的，于是这个包被合法地接受，RS感知不到前面有LVS的存在。而当RS返回响应时，只要直接向源IP（即用户的IP）返回即可，不再经过LVS。至此，回答了我们第一个问题：CN的返回结果是否会经过LVS，然后再返回给前端应用？答：GaussDB(DWS)采用的是LVS的DR模式，返回时不再经过LVS。 接下来，我们看看keepAlived。一、什么是keepAlived？Keepalived顾名思义，保持存活，在网络里面就是保持在线了，也就是所谓的高可用或热备，用来防止单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生。二、keepAlived的原理Keepalived的实现基于VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议），而VRRP是为了解决静态路由的高可用。虚拟路由器由多个VRRP路由器组成，每个VRRP路由器都有各自的IP和共同的VRID(0-255)，其中一个VRRP路由器通过竞选成为MASTER，占有VIP，对外提供路由服务，其他成为BACKUP，MASTER以IP组播（组播地址：224.0.0.18）形式发送VRRP协议包，与BACKUP保持心跳连接，若MASTER不可用（或BACKUP接收不到VRRP协议包），则BACKUP通过竞选产生新的MASTER并继续对外提供路由服务，从而实现高可用。三、KeepAlived与LVS的关系1、keepalived 是 lvs 的扩展项目，是对LVS项目的扩展增强，因此它们之间具备良好的兼容性。2、对LVS应用服务层的应用服务器集群进行状态监控：若应用服务器不可用，则keepalived将其从集群中摘除，若应用服务器恢复，则keepalived将其重新加入集群中。3、检查LVS主备节点的健康状态，通过IP漂移，实现主备冗余的服务高可用，服务器集群共享一个虚拟IP，同一时间只有一个服务器占有虚拟IP并对外提供服务，若该服务器不可用，则虚拟IP漂移至另一台服务器并对外提供服务，解决LVS本身单点故障问题。 至此，我们可以回答第二个问题：如果经过LVS，那么，LVS会不会成为单点瓶颈或者出现单独故障？答：返回结果不会经过LVS，不会因为返回的数据量太大造成单独瓶颈的问题。对应请求， LVS只需要将用户请求转发给CN即可，负载很低，也不会出现单独瓶颈的问题。另外，LVS通过keepAlived实现了主备冗余，避免了单独故障。

本文主要是探讨OLAP关系型数据库框架的数据仓库平台如何设计双集群系统，即增强系统高可用的保障水准。当前社会、企业运行当中，大数据分析、数据仓库平台已逐渐成为生产、生活的重要地位，不再是一个附属的可有可无的分析系统，外部监控要求、企业内部服务，涌现大批要求7*24小时在线的应用，逐步出现不同等级要求的双集群系统。数据仓库主流数据库平台均已存在多重高可靠保障措施设计，如硬盘冗余的raid设计、数据表冗余、节点备用冗余、机柜备用数据交叉等，以及加上服务进程高可用冗余设计，其最大化程度满足数据仓库服务持续在线。但现实场景，如数据库软件缺陷、定期加固补丁、产品迭代、硬件升级这些产品现实因素，以及来自机房、数据中心、地域、网络的外部灾难故障因素，均在降低数据仓库可用性服务水平。鉴于数据仓库存在大量数据吞吐，针对不同数据库、不同可用性要求，若需要设计双集群冗余设计，可选技术手段分别有数据同步模式、双ETL模式、双活模式，具体探讨如下：1.       数据同步模式a)         架构由于数据库IO能力有限、且两个数据库间带宽有限，除了首次全量同步之后，后续通常考虑增量同步技术，即如何准确、高效获取“变化数据”，一般存在日志同步技术、备份增量同步技术、逻辑数据同步；b)        日志同步技术日志同步技术，有业内最著名Oracle Golden Gate，大部分厂家也有自己的实现方式，像Teradata近年来推出Unity CDM（变化数据广播）技术，而我司GaussDB for DWS可采用xlog及page进行变化数据同步。优势：直接同步变化数据增量，数据量少，要求带宽低，但目前市面技术大都只适合数据每日变化量较少的数据仓库环境；劣势：现实的技术门槛高，应对各类异常场景适应能力差，对主数据库侵入性能要求高，一旦主库繁忙，同步时效低；面对全删全插等变化数据量大场景，同步吃力；c)         备份增量同步技术主要利用各数据库平台备份恢复能力，进行数据增、全量备份、恢复；通常源库备份数据压缩之后，经网络传输后，解压恢复到目标库；对应GaussDB for DWS可采用roach备份恢复工具实现；优势：利用同一技术实现增、全量数据同步，逻辑清晰，各场景容错能力强；劣势：要求数据库支持增备能力，且往往锁等待严重；d)        逻辑数据同步该项主要涉及较高的业务侵入性，即充分获取ETL调度数据流元数据，对应数据库当日数据稳定之后，发起数据表导出-导入操作，针对数据表加工特性，选择增全量同步规则，进行数据准实时同步。优势：较上述同步技术，可以实现多样选择性同步，同步过程由实施项目本身控制，做到表级数据同步，不需要全系统同步，即可实现部分业务双集群；劣势：客户化同步逻辑，操作前置依赖多，实施投入人力多，较难推广；2.       双ETL模式a)         架构即采用两套独立调度平台进行数据加工，抽取同一个数据源（往往是落地稳定的数据交换平台），采用同一套ETL代码依赖逻辑调度，各自生成目标数据，往往批量过程中，采取主库对外持续服务，待主备库数据准实时或批后校验一致后，再开放备库对外服务。若双集群数据发生不一致场景，主要以主库数据为准，覆盖备库。该同步过程，需要使用到“数据同步模式”相关同步技术。b)         参照落地架构c)         加载源数据考虑为保证两套ETL调度加载数据源一致及数据复用，往往要求搭建一个数据交换平台。因为至少存在一个文件被两套调度读取，要求数据交换平台两倍过往吞吐能力；且禁止加载的数据文件被二次覆盖，导致两套系统加载不一致；d)         调度依赖顺序考虑由于ETL作业调度关系没有配置完备，即存在A作业使用B作业的数据，但不配置依赖关系（绝大部分的情况是A作业可容忍B数据的时效，是否最新数据均可以使用，故为时效，业务上不配置依赖关系；当然也存在物理时间上，通常B远远早于A执行），导致两套系统A作业生成数据不一致。该场景下，在一套调度平台无法发现此问题，但存在两套系统的校验比对，即发现数据不一致；该问题建议用户补全依赖关系，确认执行顺序一致性；当然若希望灵活使用依赖关系，则需二次开发，控制两套调度当日时序一致性；e)         ETL代码服务器考虑为了避免两套ETL调度代码维护不一致，需考虑统一维护渠道，包含不限于同一个代码存储源、版本服务器，以及代码变更时机f)          存在不确定值的SQL函数返回ETL代码中往往存在sample、random、row_number排序这种同一份数据产生不同结果集的函数，造成两套系统数据不一致；该问题建议用户使用替代函数、明确取值、唯一排序，确保最终数据一致性；同时，该设计逻辑正确情况下，哪份数据均可被业务采信，若该数据对下游影响少，可每日批后从主库同步备库，拉平数据；g)         报错修数逻辑考虑其中一套系统的数据发生报错、修数行为，会涉及到另一套系统的维护行为；可选作法是保留操作逻辑，待另一套系统发生报错时重复执行一次；其它交给数据质量校验（DQC）、数据校验去复查；h)         干预重跑修数逻辑考虑若批后重跑，两套系统重跑逻辑一致，涉及重复劳动（或支撑平台优化），相对简单；但涉及批量过程中发现部分数据需要重跑，由于两套调度进度不一致，会导致i)           数据校验 i.              校验时机批后校验，逻辑清晰，对调度依赖少，即根据整体调度进度，做到分层、分库或整体数据校验；准实时校验，即侵入调度环节，在每个作业完成时，均发起日志解析，提取每个SQL影响记录数，若相应作业SQL存在影响记录数不一致场景，即中止较晚完成的调度平台调度后续作业；ii.              校验手段增全量校验，即针对不同加工逻辑的数据表，区分增、全量数据值，以最小代价覆盖所有业务表iii.              校验方法通常作法有记录数、汇总值、checksum校验；汇总值校验，通过是数值型字段直接sum、字符型计算字符长度的sum、时间类型则转换成数值相加的比对；Checksum校验，针对全表或部分字段，进行md5或hash运算，完成两套系统一致性比对；对于关系型数据库，校验开销代价逐步递增（记录数 < 汇总值 < checksum校验）；往往是结合增量校验、结合重要指标，区分维度校验，日常增量逻辑校验，定期全量校验，在校验数据一致性和系统性能之间取得平衡点。j)           优化考量i.              校验改进即嵌入调度平台，提取ETL代码运行日志，通过执行SQL影响的记录值，实时进行两套系统完成作业日志比对，发现记录值影响，立即停止备库调度，采用人工或自动方式修复数据，继续后续批量。该作法最大好处是，即时发现数据异常，避免问题放大，保障备库更高可用性；ii.              引入统一维护平台即减少人为双系统维护操作，代码变更平台化，修数逻辑平台化，由平台分别下发两套调度平台、两套数据库。3.       双活模式以下基于Teradata Unity产品理念的延伸构想a)         架构b)         双活功能点i.              访问路由能力客户端直接将中间件作为数据库登陆，保持原来登陆逻辑不变；中间件根据登陆用户及附加参数实现拒绝登陆、双系统登陆、或单系统登陆，实现写登陆、读登陆，实现受控方式登陆、或非受控方式登陆；即实现受控和非受控方式的系统读写；同时兼顾考虑异常路由选择或同步路由选择，满足最大化异常执行及少部分同步需求场景；ii.              SQL分发能力经中间件发送的SQL指令，正常发送到相应数据库，并接受数据库响应信息；iii.              批量导入、导出能力针对数据大批量的导入，需要考虑采用更加高效的加载协议进行数据加载，并考虑经中间件复制数据块，异步分发两个数据库；数据导出，需要考虑高效数据导出协议，从其中一套数据库正确导出数据；iv.              更新类SQL校验能力Delete、Update、Insert、Merge等更新类DML SQL进行SQL影响记录数校验；DDL/DCL执行返回码验证一致性能力；v.              对象注册功能通过路由及创建对象的DDL语句，实现对象动态注册；通过命令行指令实现对象注册；适当增加对象索引、约束索引的注册信息，用于扩展细粒度对象锁能力，提高数据仓库ETL SQL并发能力；*数据仓库环境下，只需要考虑到表级双活的能力，不建议实施字段级、记录级双活； vi.              对象锁能力根据SQL指令给相应对象动态加锁、释放锁；同时根据数据库自带的锁特征，至少区分读、写锁控制，以及部分数据库的脏读功能锁；vii.              对象状态控制能力进行管理的多套数据库在线状态控制；进行对象状态控制功能，包含不限于在线、离线、只读、只写、主动中断缓存中、被动中断缓存中、不可用等状态；viii.              缓存能力进行SQL指令流缓存能力，以及缓存恢复执行的能力；进行SQL与加载数据结合缓存、以及缓存恢复执行的能力；ix.              SQL异常控制能力考虑用户体验，始终由返回响应正确的SQL指令返回客户端；两个数据库返回均成功，但返回的影响记录数不一致，则响应慢的数据库对应SQL及涉及对象被设置成不可用状态；若两套数据库其中一套执行成功，另一套执行失败，则执行失败的数据库SQL和涉及对象被设置为被动中断缓存中，同时缓存SQL，定时重试SQL；若两套数据库返回均报错，才通知客户端报错；若SQL涉及对象已处理非在线状态，则新提交的SQL被缓存，新提交SQL相应对象被设置为被动中断缓存中。针对中间件和数据库之间，存在数据库已执行完、但中间件未收到信号场景，需考虑闪环该场景（如增加事务锁等）；c)         Teradata Unity参照落地架构ü  主要通过Unity实现多集群SQL、数据分发与管理；ü  Data Mover实现集群间数据同步；ü  Eocsystem Manager实现数据批后自动校验及不一致重同步事件触发；ü  Viewpoint实现系统平台透视图展现与维护，并对接用户告警平台；d)         中间件高可用考虑由于引入了中间件（前置）服务，即该服务的稳定、可靠对双活模式至关重要。数据库单套系统本身已经具备极高的可用性，引入中间件后，由于所有数据库访问行为均通过该中间件，中间件任何异常均同时影响两套数据库访问能力。除了中间件本身所有相关服务需要满足高可用之外，还需考虑极端场景下bypass能力，此项能力在于极端异常条件下，可以保障系统持续服务的能力。高可用场景中，存在控制节点脑裂与自动升主场景，需借鉴仲裁机制减少脑残裂发生；e)         数据重同步考虑即利用“数据同步模式”相关同步技术，实现两套数据库数据重同步能力；f)          不确定值的SQL函数考虑最佳方案，是采用“数据同步模式”的数据日志重同步技术，直接将第一套数据库SQL执行结果的日志信息同步到第二套数据库中，消除返回结果不一致；部分简单的系统时间函数，直接通过中间件改写，保障SQL执行结果一致性；另外，则通过SQL改写，保证row_number函数进行主键或全字段排序，保证SQL执行结果一致性；g)         异常会话重放能力针对异常会话过程的SQL，可能需要从会话建立后，可视化选择，倒回前几个SQL重新执行，并指定过程SQL是否参与结果集校验，以及SQL回放结束的确认动作，让异常场景处理手段更加丰富。4.       适用场景a)         “数据同步模式” – 日志同步技术适用数据变化量小、数据传输压力小的数据场景，通常只适用于小型数据仓库平台；对于规模小的平台，RPO、RTO可以接近0；b)         “数据同步模式” – 备份增量同步技术适合大数据量同步场景，实现方式容易被用户理解；往往需要数据库备份工具具备增量备份恢复能力；同时考验备份工具消除相关硬件限制条件，让该技术方案更加灵活；双集群的初始化同步往往采用全备全恢的逻辑实现，可以最大化、最快拉平存量数据；对于规模大的平台，RPO往往需要小时级别，RTO最好水准也在分钟、10分钟以上；同时主集群需要保障一定资源量供数据同步使用，对主集群开销大；c)         “数据同步模式” – 逻辑数据同步技术适用灵活同步场景，往往数据同步量不会太大，或同步时间可容忍场景；此场景往往适合于用户对其数据仓库ETL过程元数据信息清晰、完整，依赖客户开发能力，相关同步数据存在清晰ETL算法，结合调度作业运行进度，动态发起相关数据表增、全量同步；对于中等规模的平台，RPO可以做到分钟、半小时，RTO可以维持在分钟级；d)         “双ETL模式”需要两套ETL调度环境，整体成本翻倍，但调度逻辑清晰、易于理解和维护；较容易匹配不同规模的数据仓库平台采纳；较难实现数据实时比对，以及数据发生不一致之后的控制逻辑（若需要实现，对于调度逻辑侵入性大）；ETL调度批量中途，较难实现两套调度链路协调重跑；同时数据不一致，依赖于”数据同步模式”技术辅助实施；由于主备调度进行不一致，无法做到主备统一视图展现；若双集群硬件相当，RPO、RTO均可以维持在分钟级别；e)         ”双活模式“需要独立中间件、且严重依赖数据库自身厂商，中间件实现难度大；中间件的高可用（稳定性）成为它落地的最大障碍；“双ETL模式”的升级版，能适应各类数据仓库双集群场景；绝大部分场景下，RPO、RTO均可以接近0，特别是双活同时在线能力，不存在双集群的主备切换，RTO可以做到0；同时存在统一视图，不会因为其中一个集群故障，造成前后同一个查询返回结果不一致场景；5.       总结比对

Informatica10.2与GaussDB A8.0对接方法1. Informatica 通过插件与GaussDB对接1.1 了解 PowerExchange for GaussDB A        PowerExchange for GaussDB A是由GaussDB A 提供的可在ETL工具PowerCenter上使用的插件，可实现数据的快速导入。        本插件可以将PowerCenter处理好的数据快速导入GaussDB A 8.0数据库。主要原理是把 PowerCenter处理数据写入本地管道，通过调用gaussload工具启动GDS服务，然后将管 道数据传输至GaussDB A数据库DN端，实现了数据快速导入。        本文档主要介绍Informatica PowerCenter安装和使用。此文档适用于具备数据装载权限 的数据库管理和开发人员，且假设您已掌握以下基本知识：数据库基本理论、 GaussDB A 8.0和PowerCenter使用方法。1.2 安装 PowerExchange for GaussDB A 8.01.2.1 安装准备插件名称：        GaussDB-8.0.0-REDHAT-x86_64bit-Informatica-plugin.tar.gz        GaussDB-8.0.0-REDHAT-x86_64bit-gauss-loader.tar.gz插件位置：        FusionInsight_MPPDB_8.0.0_RHEL.tar.gz安装包中，FusionInsight_MPPDB/software/components/package/package路径下。软件环境要求：        Linux操作系统：支持SUSE Linux Enterprise Server 11 SP1/SP2, x86_64，Redhat，centos。        PowerCenter版本：10.2。 工具：必须为系统自带Python2.6版本。前提条件本地已成功安装PowerCenter server组件。PowerCenter client端已配置GaussDB A 8.0 ODBC驱动（配置方法见后面章节）。用户对<PowerCenter Installation Directory>/server/bin目录具有读写执行权限。需要提前安装gaussload工具，安装步骤如下：                步骤1：进入gaussload解压目录，执行bash install_gaussload.sh。                步骤2：配置环境变量GAUSS_LOADERS，将$GAUSS_LOADERS/bin加到PATH环境变量中，export PATH=$GAUSS_LOADERS/bin:$PATH。1.2.2安装步骤步骤1 在Informatica Server主机上，解压GaussDB-8.0.0-REDHAT-x86_64bit-Informatica-plugin.tar.gz文件，执行bash install.sh命令，提示安装成功。步骤2 打开Informatica的B/S管理端"Informatica Administrator"，使用域口令登录。        说明 该管理端的入口在Informatica Server的安装过程中会有提示。一般的URL为： http://10.119.31.38:6008，其中IP地址为Informatica Server所在IP，端口默认为6008。如果在安装 过程中使用的是自定义端口，这里请做相应修改。步骤3 找到需要配置的PowerCenter存储库服务，在属性页面找到“存储库属性”，点击修 改，如下图。          步骤4 将PowerCenter的存储库操作模式调整为“独占”模式，这将会重启存储库，请注意。步骤5 待存储库重启完成后，转到插件页面，点击添加插件图标，如下图：         步骤6 在弹出的“PowerCenter存储库服务注册插件”页面，选择步骤1中GaussDB-8.0.0-REDHAT-x86_64bit-Informatica-plugin.tar.gz解压出的插件文件 GaussDB_Kernel_Connector.xml        说明：如果之前注册过该插件，请勾选“更新现有插件注册”，并请同步更新Informatica Server的插件安装包，执行install.sh脚本，见步骤1。 步骤7 按照之前的步骤，重新将存储库服务的操作模式，调整为“普通”，重启存储库服务，完成。----结束 1.2.3 使用 PowerExchange for GaussDB A        当需要通过PowerCenter向GaussDB A 8.0导入数据时，可以利用PowerExchange for GaussDB A组件实现数据快速导入。 操作步骤步骤1 导入GaussDB A 8.0目标表。        用户可以在设计阶段从GaussDB A 8.0数据库导入目标表，PowerCenter会做数据类型转换，将原始数据类型转换为ODBC数据类型。        1、点击源或目标，选择从数据库导入，添加GaussDB A 8.0与数据库的DSN连接。                2、选择"PostgreSQL Unicode"选项，点击完成进入"PostgreSQL ANSI ODBC Driver(psqlODBC) Setup"窗口，填写用户名、密码，连接GaussDB A 8.0                 3、配置好数据源后，选择相应ODBC数据源，输入用户名、密码等信息，点击连接，空白窗口显示表信息，选择要导入的源表或目标表         步骤2  配置PowerExchange for GaussDB A 8.0连接        1、单击连接，选择关系，显示关系连接浏览器窗口                2、单击“新建”，选择PWX GaussMPP，选中确定进入连接对象定义窗口，将跳转至链接配置信息页面                3、输入连接配置信息，详细内容请参见表1-1                表 1-1 PowerExchange for GaussDB A 8.0 连接属性         步骤3  配置PowerExchange for GaussDB A 8.0会话(Session)属性。 用户可以在映射(Mapping)窗口设置Session属性，配置信息如表1-2所示                 表 1-2 PowerExchange for GaussDB A 8.0 会话(Session)属性                                ----结束 参数配置成功后，可以执行导入操作，具体使用方法参考参照《PowerCenter用户指 南》文档。 2. Informatica通过ODBC方式连接GaussMPP2.1 Informatica版本        Informatica Server版本：        2.2  配置ODBC驱动        Informatica利用ODBC方式连接GaussMPP，需要分别配置server端及client端。2.2.1 server端配置GaussMPP odbc驱动步骤1  从unixODBC官方网站下载unixODBC-2.3.0.tar.gz，解压、编译、安装；        tar zxvf unixODBC-2.3.0.tar.gz        ./configure        make && make install步骤2  从FusionInsight_MPPDB_8.0.0_RHEL.tar.gz安装包的解压文件的路径FusionInsight_MPPDB/software/components/package/package下。得到GaussDB-8.0.0-REDHAT-x86_64bit-Odbc.tar.gz驱动包，解压得到psqlodbcw.la, psqlodbcw.so两个文件；步骤3  以上package路径下解压GaussDB-8.0.0-REDHAT-x86_64bit-Libpq.tar.gz得到libpq的lib文件；步骤4  将$Informatica_intall/ODBC7.1/lib/备份为$Informatica_intall/ODBC7.1/lib.bak，重新建立$Informatica_intall/9.6.1/ODBC7.1/lib/目录，将unixODBC安装得到的/usr/local/lib/libodbc.so.1.0.0、so.1.0.0及libpq.so拷贝到$Informatica_install/ODBC7.1/lib/目录中，将步骤2解压得到的psqlodbcw.la、psqlodbcw.so拷贝到$Informatica_install/ODBC7.1/lib/目录中。(其实无需备份，直接拷贝到ODBC7.1/lib目录即可)。        将/usr/local/lib目录下的libodbc.so.2.0.0和libodbcinst.so.2.0.0拷贝到$Informatica_intall/9.6.1/ODBC7.1/lib/目录中。（/usr/local/lib目录下若没有可搜索系统中其他位置是否有）。步骤5  修改$Informatica_intall /ODBC7.1/ini文件，添加如下（按照实际填写）：        2.2.2  客户端配置GaussMPP odbc驱动步骤1  从FusionInsight_MPPDB_8.0.0_RHEL.tar.gz安装包的解压文件的路径FusionInsight_MPPDB/software/components/package/package下。得到GaussDB-8.0.0-Windows-Odbc.tar.gz驱动包，解压后安装psqlodbc.msi文件和psqlodbc_x64.msi文件，安装psqlODBC成功步骤2  配置驱动，win64位系统需配置C:\Windows\SysWOW64\odbcad32.exe文件，系统32位系统需配置C:\Windows\System32\odbcad32.exe文件，添加mppdb驱动。        点击Test测试连接是否成功。步骤3  PowerCenter 客户端工具在通过ODBC方式连接到GaussMPP数据库时，可以连接，但是出现以下两处警告，如下图所示：               消除以下两处警告；修改D:\Informatica\9.6.1\clients\PowerCenterClient\client\bin\powrmart.ini，在[ODBCDLL]中添加条目：PostgreSQL=extodbc.dll2.3  从oracle向gaussmpp中导入数据步骤1 repository manager中创建ORACLE_TO_MPP文件夹；        步骤2  在designer中创建源、目标和Mapping                  源使用oracle数据库中的bi_source的emp表        目标指定到mpp中的tmp表        需要提前在mpp中创建空白表        步骤3  workflow中指定目标emp的关系连接编辑器，连接字符串连接为gaussdb，与ini文件中名称一致；        步骤4  执行会话，结果显示成功, workflow monitor显示如图：        步骤5  确认oracle中dept表的数据        步骤6  查看MPP中tmp表的数据        步骤7  使用Informatica的测试工具，一直是等待状态，没有其他提示         补充：客户端如果与服务端不在同一机器上时，客户端(windows)需要安装msi文件，win64位系统需配置C:\Windows\SysWOW64\odbcad32.exe文件，系统32位系统需配置C:\Windows\System32\odbcad32.exe文件，添加mppdb驱动。        服务端需配置mpp odbc驱动，所需文件，其中libpq必须，不能缺少；        指定源和目标时，目标无需从数据库导入，只要从源数据创建就可以。源使用oracle数据库中的scott的dept表，目标指定到mpp中的dept表，需要提前在mpp中创建空白表。3. 遇到过的问题：1、1.2.3中步骤2中无法看到PWX GaussMPP的插件。解决方法：1.2.2中，卸载其他插件，只安装Gauss的插件后，可以在1.2.3的步骤2中看到该插件。

ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中。目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。1      ETL算法概览>  算法应用场景概览以上共计累积了8种ETL算法，其中主要分成4大类，增量累加、拉链算法是更符合数据仓库历史数据追踪的算法，但现实中基于业务及性能考虑，往往存在全删全插、增量累全算法的数据表应用。2      全删全插模型即Delete/Insert实现逻辑；>  应用场景主要应用在维表、参数表、主档表加载上，即适合源表是全量数据表，该数据表业务逻辑只需保存当前最新全量数据，不需跟踪过往历史信息。>   算法实现逻辑1.清空目标表；2.源表全量插入；>   ETL代码原型--   1. 清理目标表TRUNCATE TABLE <目标表>; --   2. 全量插入INSERT INTO <目标表>   (字段***)SELECT 字段***FROM <源表>***JOIN <关联数据>WHERE   ***;3      增量累全模型即Upsert实现逻辑；>  应用场景主要应用在参数表、主档表加载上，即源表可以是增量或全量数据表，目标表始终最新最全记录。>  算法实现逻辑1.利用PK主键比对；2.目标表和源表PK一致的变化记录，更新目标表；3.源表存在但目标表不存在，直接插入；>  ETL代码原型-- 1. 生成加工源表Create temp Table <临时表> ***;INSERT INTO <临时表> (字段***)SELECT 字段***  FROM <源表>***JOIN <关联数据>WHERE ***; -- 2. 可利用Merge Into实现累全能力，当前也可以采用分步Delete/Insert或Update/Insert操作Merge INTO <目标表> As T1 (字段***)Using <临时表> as S1on (***PK***)when Matched thenupdate set Colx = S1.Colx ***when Not Matched thenINSERT (字段***)   values (字段*** );4      增量累加模型即Append实现逻辑；>   应用场景主要应用在流水表加载上，即每日产生的流水、事件数据，追加到目标表中保留全历史数据。流水表、快照表、统计分析表等均是通过该逻辑实现。>  算法实现逻辑1.源表直接插入目标表；>  ETL代码原型--   1.插入目标表INSERT INTO <目标表>   (字段***)SELECT 字段***FROM <源表>***JOIN <关联数据>WHERE   ***;5      全历史拉链模型>  拉链表背景知识l  概念拉链表是一张至少存在PK字段、跟踪变化的字段、开链日期、闭链日期组成的数据仓库ETL数据表；l  益处根据开链、闭链日期可以快速提取对应日期有效数据；对于跟踪源系统非事件流水类表数据，拉链算法发挥越大作用，源业务系统通常每日变化数据有限，通过拉链加工可以大大降低每日打快照带来的空间开销，且不损失数据变化历史；l  示例，提取指定日期有效数据提取2020年2月5日当日有效数据Select *From  <目标表>Where 开始日期<=date'2020-02-05'And   结束日期 >date'2020-02-05';最终提取到数据：>   应用场景全历史拉链，跟踪源表全量变化历史，若源表记录不存在，则说明数据闭链；根据PK新拉一条有效记录。>  算法实现逻辑1.提取当前有效记录；2.提取当日源系统最新数据；3.根据PK字段比对当前有效记录与最新源表，更新目标表当前有效记录，进行闭链操作；4.根据全字段比对最新源表与当前有效记录，插入目标表；>  ETL代码原型-- 1. 提取当前有效记录Insert into <临时表-开链-pre> (不含开闭链字段***)Select 不含开闭链字段***From <目标表>Where 结束日期 =date'<最大日期>';;-- 2. 提取当日源系统最新数据<源表临时表-cur>-- 3 今天全部开链的数据，即包含今天全新插入、数据发生变化的记录Insert Into <临时表-增量-ins>Select 不含开闭链字段***From <源表临时表-cur>where (不含开闭链字段***) not in   (Select 不含开闭链字段***    From <临时表-开链-pre>   );-- 4 今天需要闭链的数据，即今天发生变化的记录Insert into <临时表-增量-upd>Select 不含开闭链字段***,开始时间From <临时表-开链-pre>where (不含开闭链字段***) not in   (Select 不含开闭链字段***    From <临时表-开链-cur>   );-- 5 更新闭链数据，即历史记录闭链（删除-插入替代更新）DELETE FROM <目标表>WHERE (PK***) IN(Select PK*** From <临时表-增量-upd>)AND 结束日期=date'<最大日期>';INSERT INTO <目标表>      (不含开闭链字段***,开始时间,结束日期)Select 不含开闭链字段***,开始时间,date'<数据日期>'From  <临时表-增量-upd>;-- 6 插入开链数据，即当日新增记录INSERT INTO <目标表> .      (不含开闭链字段***,开始时间,结束日期)Select 不含开闭链字段***,date'<数据日期>',date'<最大日期>'From    <临时表-增量-ins>;6      增量拉链模型>  应用场景增量拉链，目的是追踪数据增量变化历史，根据PK比对新拉一条开链数据；>  算法实现逻辑1.提取上日开链数据；2.PK相同变化记录，关闭旧记录链，开启新记录链；3.PK不同，源表存在，新增开链记录>  ETL代码原型--   1. 提取当前有效记录Insert into <临时表-开链-pre> (不含开闭链字段***)Select 不含开闭链字段***From <目标表>Where 结束日期 =date'<最大日期>';--   2. 提取当日源系统增量记录<源表临时表-cur>--   3. 提取当日源系统新增记录Insert into <临时表-增量-ins>Select 不含开闭链字段***From <临时表-开链-cur>where (***PK***) not in  (select ***PK*** from <临时表-开链-pre>);--   4. 提取当日源系统历史变化记录Insert into <临时表-增量-upd>Select 不含开闭链字段***From <临时表-开链-cur>inner join <临时表-开链-pre>on (***PK 等值***)where (***变化字段 非等值***);--   5. 更新历史变化记录，关闭历史旧链，开启新链update <目标表> AS T1SET <***变化字段 S1赋值***>,结束日期 = date'<数据日期>'FROM <临时表-增量-upd> AS S1WHERE ( <***PK 等值***> )AND   T1.结束日期 =date'<最大日期>';INSERT INTO <目标表>      (不含开闭链字段***,开始时间,结束日期)SELECT 不含开闭链字段***,date'<数据日期>',date'<最大日期>'FROM <临时表-增量-upd>;--   6. 插入全新开链数据INSERT INTO <目标表>      (不含开闭链字段***,开始时间,结束日期)SELECT 不含开闭链字段***,date'<数据日期>',date'<最大日期>'FROM <临时表-增量-ins>;7      增删拉链模型>  应用场景主要是利用业务字段跟踪增量数据中包含删除的变化历史。>  算法实现逻辑1.提取上日开链数据；2.提取源表非删除记录；3.PK相同变化记录，关闭旧记录链，开启新记录链；4.PK比对，源表存在，新增开链记录；5.提取源表删除记录；6.PK比对，旧开链记录存在，关闭旧记录链；>  ETL代码原型--   1. 清理目标表《待续...》TRUNCATE TABLE <目标表>; --   2. 全量插入INSERT INTO <目标表>   (字段***)SELECT 字段***FROM <源表>***JOIN <关联数据>WHERE   ***;8      全量增删拉链模型>  应用场景主要是利用业务字段跟踪全量数据中包含删除的变化历史。>  算法实现逻辑1.提取上日开链数据；2.提取源表非删除记录；3.PK相同变化记录，关闭旧记录链，开启新记录链；4.PK比对，源表存在，新增开链记录；5.提取源表删除记录；6.PK比对，旧开链记录存在，关闭旧记录链；7.PK比对，提取旧开链存在但源表不存在记录，关闭旧记录链；>  ETL代码原型--   1. 清理目标表，《待续...》TRUNCATE TABLE <目标表>; --   2. 全量插入INSERT INTO <目标表>   (字段***)SELECT 字段***FROM <源表>***JOIN <关联数据>WHERE   ***;9      自拉链模型>  应用场景主要将流水表数据转化成拉链表数据。>  算法实现逻辑借助源表业务日期字段，和目标表开链、闭链日期比对，首尾相接，拉出全历史拉链；>  ETL代码原型--   1. 清理目标表，《待续...》TRUNCATE TABLE <目标表>; --   2. 全量插入INSERT INTO <目标表>   (字段***)SELECT 字段***FROM <源表>***JOIN <关联数据>WHERE   ***;10  其它说明1.根据数据仓库最佳实践，所有数据表通常还会包含一些控制字段，即插入日期、更新日期、更新源头字段，这样对于数据变化敏感的数据仓库，可以进一步追踪数据变化历史；2.ETL算法本身是为了更好服务于数据加工过程，实际业务实现过程中，并不局限于传统算法，即涉及到更多适应业务的自定义的ETL算法。

GaussDB(DWS)基于postgreSQL进行的开发，在公共模式方面两者基本一致；常见的公共模式有以下三种：PUBLIC模式，Catalog模式，information_Schema模式。1、Public模式缺省时，创建的表(以及其它对象)都自动放到一个叫做"public"的模式中去了。每个新数据库都包含一个这样的模式。搜索路径中第一个存在的模式是创建新对象的缺省位置。这就是为什么缺省的对象都会创建在 public 模式里的原因。如果在其它环境中引用对象且没有模式修饰，那么系统会遍历搜索路径，直到找到一个匹配的对象。因此，在缺省的配置里，任何未修饰的访问只能引用 public 模式。public 模式没有任何特殊之处，只不过它缺省时就存在。我们也可以删除它。请注意，缺省时每个人都在public模式上有CREATE和USAGE权限。这样就允许所有可以连接到指定数据库上的用户在这里创建对象。2、Catalog模式除了public和用户创建的模式之外，每个数据库都包含一个pg_catalog模式，它包含系统表和所有内置数据类型、函数、操作符。pg_catalog总是搜索路径中的一部分。如果它没有明确出现在路径中，那么它隐含地在所有路径之前搜索。这样就保证了内置名字总是可以被搜索。自从系统表名以pg_开头开始，最好避免使用这样的名字，以保证自己将来不会和新版本冲突：那些版本也许会定义一些和你的表同名的表(在缺省搜索路径中，一个对你的表的无修饰引用将解析为系统表)。系统表将继续遵循以pg_开头的传统，因此，只要你的表不是以pg_开头，就不会和无修饰的用户表名字冲突。3、information_schema模式 Information_schema自动的存在于每个database中，里面包含了数据库中所有对象的定义信息。 Information_schema默认不存在于任何用户的search_path中，所以对所有用户都是隐藏的。\dn看不到，通过pgAdmin等客户端工具也不会自动显示。因此访问这个schema的任何视图都需要加上schema名。当然也可以通过修改search_path参数来访问。但不推荐这样做，因为里面的视图名称可能会跟用户应用程序中的对象名冲突。information_schema模式下几个重要的视图：表信息: information_schema.tables ，相当于Oracle中的all_tables字段信息： information_schema.columns，相当于Oracle中的all_tab_cloumns 权限信息：   table_privileges中记录了表权限；column_privileges中记录了列上的权限；routine_privileges上记录了function/procedure的权限role_usage_grants记录了sequence/domain等类型的对象的usage权限，跟usage_privileges类似视图信息：  Views中记录视图基础信息；view_table_usage记录视图所依赖的表；view_routine_usage记录所依赖的function；view_column_usage记录所涉及的字段 PostgreSQL有两个系统架构调用information_schema和pg_catalog，这可能会让大家感到困惑。下面是一些区别，标了一些关键字，请大家自行理解。Catalog：The system catalogs are the place where a relational database management system stores schema metadata, such as information about tables and columns, and internal bookkeeping information. PostgreSQL's system catalogs are regular tables. You can drop and recreate the tables, add columns, insert and update values, and severely mess up your system that way. Normally, one should not change the system catalogs by hand, there are always SQL commands to do that. (For example, CREATE DATABASE inserts a row into the pg_database catalog — and actually creates the database on disk.) There are some exceptions for particularly esoteric operations, such as adding index access methods.Information_schema: The information schema consists of a set of views that contain information about the objects defined in the current database. The information schema is defined in the SQL standard and can therefore be expected to be portable and remain stable — unlike the system catalogs, which are specific to PostgreSQL and are modeled after implementation concerns. The information schema views do not, however, contain information about PostgreSQL-specific features; to inquire about those you need to query the system catalogs or other PostgreSQL-specific views. 

AIX服务器通过客户端工具访问GaussDB A，可以使用下面方法：1、Aix安装gmake，下载make-4.1-2.aix6.1.ppc.rpm        ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/make/2、root执行rpm -ivh make-4.1-2.aix6.1.ppc.rpm3、下载postgresql-9.2.4源码包。        https://www.postgresql.org/ftp/source/v9.2.4/        或https://ftp.postgresql.org/pub/source/v9.2.4/4、上传postgresql-9.2.4.tar.gz到aix服务器，并解压。5、进入到解压后的目录，使用root用户执行。      ./configure      gmake      gmake install6、使用psql命令连接GaussDB数据库。

在线上，我们DWS（数据仓库服务）与ADB for MySQL有非常多的差异，将目前发现的差异总结如下，如有遗漏，欢迎大家补充。一、总体结构的差异在ADB for MySQL中，由上至下的结构是：实例-->数据库-->表   JDBC需要连接到实例上，使用库名.表名来进行表数据的增删改查等操作。由此可见，ADB for MySQL中实例对应DWS中的数据库，其数据库对应DWS中的模式（schema），同样，在ADB中可以使用库名.表名的方式进行跨库访问（类似于跨schema访问）。二、数据类型的差异ADB(MySQL)中大部分数据类型与DWS是一致的，如VARCHAR、int、bigint、decimal等，但有如下几个数据类型需要大家注意：    1.datetime与timestamp在ADB(MySQL)中datetime是没有时区的时间戳，而timestamp是带时区的时间戳，因此，在转换成DWS中的数据类型时，datetime需要转为timestamp without time zone，timestamp转为timestamp with time zone;    2.tinyintDWS与ADB中均存在tinyint这种数据类型，但是，在ADB中其范围是 -128~127，而DWS中为0~255，因此，ADB中的tinyint需要转为DWS中smallint，或int；三、常用函数的差异ADB中的日期处理函数与DWS中完全不一致，在语法改造过程中需要格外的注意。日期的加减，在ADB中有两个不同函数，分别为date_add及date_sub，DWS中可直接改为加减号，但是有一点大家要注意，ADB中INTERVAL后是可以不加单引号的，而且其数值可以是一个字段名。      如下，select DATE_ADD(NOW(),INTERVAL col1 DAY) from table1;而且，在ADB中INTERVAL 后面的小数会自动截取整数位，这点也是与DWS有很大差距的，这种语法一样但是结果不同的差异，大家一定要注意。此外，字符与日期之间的相互转化，ADB中为date_format(now(),'%Y%m%d')及str_to_date('20201127193000','%Y%m%d%H%i%s')，这里有一点需要注意，to_date这个函数在MySQL兼容模式下，其输出为日期，而不是时间戳。例如：to_date('20201127193000','yyyymmddhh24miss')，其结果为 2020-11-27，因此在做函数转化的时候，需要将str_to_date改为to_timestamp而不是to_date。    其他一些ADB特有的函数，如ifnull、if、max_pt等，都需要做相应的转换四、其他    ADB（MySQL）与DWS的差异当然不仅仅这些，这里只是简单列举了一些常见的、容易出问题的地方供大家参考，此外还有以下几点需要注意：1、ADB中联合主键中的某一个字段可以为空值。若需要从ADB中同步数据时，如果报错信息是违反非空约束，那除了字段与ADB没有对齐之外，还有一种可能就是因为联合主键中出现了空值。此时，可以将主键改为唯一索引来规避此问题。2、ADB中如果没有指定主键，会自动建一个`__adb_auto_id__` bigint AUTO_INCREMENT的自增序列作为主键，DWS中需要改成__adb_auto_id__ bigserial。在使用CDM从ADB同步数据时，该字段是无法默认出现的，需要在CDM中手工添加该字段的映射关系，或去掉该字段映射，使用DWS的默认自增序列。3、ADB中的replace into需要改为merge into，如果是调度周期比较短或者更新表数据量很大，需要重点关注，可以将merge into 改为select * from a union all select b.* from b left  join a on b.id =a.id where a.id is null（a是源表，b是目标表）4、分区ADB中可以支持overwrite一个分区的数据，而DWS不支持，因此，在进行语法改造的时候要提高警惕，不要把所有的overwrite都复制过来，需要先删除当前分区的数据，再插入新的数据。

一、安装前检查1、检测服务器主机名称主机名与业务平面IP地址保持一一映射关系，即每个主机名对应唯一一个业务平面IP地址，每个业务平面IP地址对应唯一一个主机名。执行命令:hostname2、检查硬盘分区是否符合规范OS盘需要对以下目录单独分区/  20G/tmp 10G/var 10G/var/log 130G/srv/Bigdata 60G/opt 200G其他24块硬盘以每组6个做成4组raid54组raid不挂载目录，在后续安装过程中会自行挂载ps：由于/srv/BigData/dbdata_om及/srv/BigData/LocalBackup没有单独分区，因此需要在主备管理节点，手工挂载磁盘，创建分区，具体操作步骤见下文二、配置软件包1、将安装包《GaussDB_A_8.0.0_RHEL.zip》上传到主管理节点198.203.70.206的/opt目录下在opt目录下解压安装包cd /opt$tar -zxvf GaussDB_A_8.0.0_RHEL.zip得到以下软件包：•FusionInsight_Manager_6.5.1_RHEL.tar.gz•FusionInsight_Manager_6.5.1.6_redhat.tar.gz•FusionInsight_BASE_6.5.1_RHEL.tar.gz•FusionInsight_BASE_6.5.1.6_redhat.tar.gz•GaussDB_A_8.0.0_RHEL.tar.gz•FusionInsight_SetupTool_6.5.1.6.tar.gz2、解压软件包tar -zxvf FusionInsight_Manager_6.5.1_RHEL.tar.gztar -zxvf GaussDB_A_8.0.0_RHEL.tar.gztar -zxvf FusionInsight_SetupTool_6.5.1.6.tar.gz3、copy文件到指定目录cp FusionInsight_BASE_6.5.1_RHEL.tar.gz FusionInsight_MPPDB_8.0.0_RHEL.tar.gz FusionInsight_Manager/software/packs/cp FusionInsight_Manager_6.5.1.6_redhat.tar.gz FusionInsight_BASE_6.5.1.6_redhat.tar.gz FusionInsight_Manager/software/patch/4、挂载操作系统镜像mount /home/backuofile/iso/rhel7664.iso /mnt/ -o loop5、检查OS的编码格式是否符合要求locale 检查OS的编码格式是否为“en_US.UTF-8“三、生成配置文件1、打开《配置规划工具》，启用宏2、基础配置修改集群名称：CMBC_GAUSS芯片类型：uname -p  x86_64OS类型：redhat-7.6OS镜像挂载目录：/mnt/配置套餐：MN&CN&DN集群节点数量：5输出配置文件路径：D:\gaussdb\ini3、选择服务使用默认配置即可，无需修改4、IP规划与进程部署选择206与207为主备管理节点，因此在前两行类型为MN&CN&DN中填写206及207相关信息，其他3行填写208~210的信息管理IP 199.203.76.206业务IP 198.203.70.206前两行MN&CN&DN中OMSServer、LdapServer、KrbServer均填Y，其余行不填，MPPDBServer所有行均填Y5、节点信息CPU虚拟核数：40 （ cat /proc/cpuinfo |grep "processor"|sort -u|wc -l ）内存 ：256 （free -g  ）主机逻辑磁盘数量 ：5 （parted -l 2>/dev/null | grep "Disk /dev/" | grep -iv "Disk /dev/mapper" | wc -l）最小数据盘容量 ：4500 （执行命令 parted -l 2>/dev/null | grep "Disk /dev/" | grep -iv "Disk /dev/mapper" 得出 5001G，再乘以0.9得 4500）主机名：206-gscmdn001 207-gsmcdn002 208-gsdn003 209-gsdn004 210-gsdn005（hostname）6、浮动IP浮动IP：198.203.70.65接口：bond0:web bond0:oms（ifconfig 查找与浮动IP在同一网段的网卡名称 bond0）子网掩码：255.255.255.0（ifconfig Use Iface为bond0的数据中对应的Genmask）网关：198.203.70.1（ifconfig Use Iface为bond0的数据中对应的Gateway）7、磁盘配置参照前文《一、安装前检查》中“2、检查硬盘分区是否符合规范”，查看OS盘分区，并填写至相应目录/     20/tmp  10/var  10/var/log 130/srv/Bigdata 60/opt  200元数据盘数：206与207填写1（如无多余硬盘分区，则选择0），其他3台机器选择0数据盘数：4（每台服务器配置4个dn，每个dn单独占据一块磁盘）8、集群参数配置选择默认配置即可，无需修改9、实例参数配置206、207选择1，其他服务器选择010、点击生成配置文件四、配置并检查安装环境1、进入“2.基础配置”中 输出配置文件路径：D:\gaussdb\ini，将software文件夹打包，然后通过跳板机上传到206这台服务器的/opt/ini_file目录下2、登录206服务器，进入配置文件压缩包所在目录后，解压压缩包cd /opt/ini_fileunzip software.zip3、将配置文件copy到指定目录cd /opt/ini_file/software/cp -r ./preinstall/* /opt/FusionInsight_Manager/software/preinstall//cp -r ./preinstall/* /opt/FusionInsight_SetupTool/preinstall//cp -r ./precheck /opt/FusionInsight_Manager/software/precheck//cp -r ./precheck /opt/FusionInsight_SetupTool/precheck//cp -r ./install_oms  /opt/FusionInsight_SetupTool4、执行preinstallcd /opt/FusionInsight_SetupTool./setuptool.sh preinstall注：若执行错误，可在“/tmp/fi-preinstall.log”路径下查看“preinstall”的日志文件，并进行相应处理。5、“preinstall”过程结束后，默认会自动继续进行“precheck”若precheck执行失败，可查看precheck日志/opt/FusionInsight_SetupTool/precheck/log/precheck_failed.log，并进行相应处理五、安装manager1、确认上一步preinstall及precheck执行无误，检查**.ini文件已传到主节点服务器/opt/FusionInsight_Manager/software/install_oms下2、检查ini文件是否配置正确cd /opt/FusionInsight_Manager/softwarecat install_oms/192.168.10.10.ini3、执行manager安装命令，等待安装执行完毕cd /opt/FusionInsight_Manager/software./install.sh -f /opt/FusionInsight_Manager/software/install_oms/192.168.10.10.ini注1：安装命令执行过程中，不支持通过“Ctrl+Z”将任务挂起。挂起后再恢复执行时可能会导致安装失败。注2：安装失败后，查看日志/var/log/Bigdata/controller/scriptlog/install.log and /var/log/Bigdata/controller/controller.log，定位错误原因。修改之后，在执行安装之前，需执行/opt/huawei/Bigdata/om-server/om/inst/uninstall.sh进行卸载后，再重新安装六、安装集群1、在步骤五安装完成后，会在控制台输出FIM页面地址：HTTP://****:8080/web复制该网址到谷歌浏览器2、输入初始用户名\密码 admin\Admin@123，首次登录后修改密码，然后重新登录3、登录成功后，点击创建集群按钮4、点击按钮模板安装，选择通过lld工具生成的xml文件，d:\gaussdb\ini\software\install_cluster\installTemplet.xml,点击提交5、选择root用户并输入“密码”，单击“查找”发现节点。查找后会自动跳转至“确定”页面，此时若发现配置规划数据有误，可单击“上一步”回到各配置项检查或更改参数值。6、确认配置信息，单击“提交”，在弹出的对话框中确认是否勾选“安装后启动集群”。7、单击“确定”开始安装集群。则待集群安装完成后，在弹出的对话框中确认是否启动集群。七、安装后检查1、检查集群状态登录FusionInsight Manager系统● 检查服务的状态。选择“集群 > 待操作的集群名称 > 服务”，各服务的“运行状态”为“良好”。● 检查节点状态。在FusionInsight Manager页面单击“主机”，各节点的“运行状态”为“良好”。注：● 主机名称前有标志表示该节点为主管理节点。● 主机名称前有标志表示该节点为备管理节点。2、执行健康检查● 执行集群的健康检查a. 选择“集群 > 待操作的集群名称” 。b. 选择“更多 > 健康检查”。● 执行主机健康检查a. 单击“主机”。b. 勾选待检查主机前的复选框。c. 选择“更多 > 健康检查”启动指定主机健康检查。附：安装过程中出现的部分问题及解决方案问题【一】：执行preinstall报错问题现象：执行preinstall时，有3台服务器磁盘分区成功，有2台服务器磁盘分区失败原因分析：成功的3台服务器为纯DN服务器，206及207这两台服务器是失败的，通过分析日志中的错误信息，发现是由于/srv/BigData/LocalBackup及/srv/BigData/dbdata_om没有单独分区，因此在执行preinstall过程中，需要4（DN数量）+1（OS系统盘）+1（/srv/BigData/LocalBackup及/srv/BigData/dbdata_om）共6块磁盘，而实际可用硬盘数量为5，从而导致执行失败。解决方案：在206及207两台机器中，分别手工执行挂载目录，具体操作步骤如下：1、创建磁盘挂载目录（按照规划sda~d分别对应/srv/BigData/data1~4，以daeta1为例）mkdir -p /srv/BigData/data12、将指定的磁盘分区，划分分区并执行格式化parted -s /dev/sda mklabel gptparted -s /dev/sda mkpart logic 100M 100%mkfs.xfs -f /dev/sda13、刷新操作系统分区表partprobe4、获取新分区的UUID。运行如下命令：blkid /dev/sda15、修改“/etc/fstab”，将如下语句作为新行添加到“/etc/fstab”中UUID=XXXXXXXXXXXXXXXXXXXXXXX /srv/BigData/data1 xfs defaults,noatime,nodiratime 1 06、挂载磁盘，并修改属主mount -achown 2000:wheel /srv/BigData/data17、重复执行步骤1~6，直至206及207两台服务器上data1~4均挂载成功使用df -h查看目录是否挂载成功8、主节点修改preinstall.ini配置文件，将参数“g_parted”值设为09、重新执行preinstall脚本，执行成功问题【二】：执行precheck报错问题现象：执行precheck报错，查看日志，报错信息为the real disk number 6 does not match the config file 7原因分析：与问题【一】原因一致，是由于/srv/BigData/LocalBackup及/srv/BigData/dbdata_om没有单独分区导致解决方案：修改precheck下checkNodes.Config，将/srv/BigData/LocalBackup及/srv/BigData/dbdata_om的硬盘分区信息删除，重新执行precheck脚本，执行成功问题【三】：在FIM使用模板安装集群时报错问题现象：使用模板安装集群，执行第一步校验请求参数报错，页面显示报错信息为 the hostname already exists原因分析：查看日志信息，报错信息为 Failed to verify node：gsmcdn001， the hostname already exists，怀疑可能是因为手工在/etc/hosts下添加所有机器的ip对应主机名信息导致。解决方案：1、删除所有5台服务器中/etc/hosts下所有手工添加的信息，在FIM使用模板创建集群，点击提交按钮后，显示“无效的业务IP”错误信息，修复失败2、将每台服务器下/etc/hosts中只保留本机的配置，如206服务器保留 198.203.70.206 gsmcdn001，在FIM使用模板创建集群，点击提交按钮后，执行第一步校验请求参数报错，页面显示报错信息为 the hostname already exists，修复失败3、删除所有5台服务器中/etc/hosts下所有手工添加的信息，然后执行/opt/huawei/Bigdata/om-server/om/inst/uninstall.sh卸载 Manager，重新安装安装Manager，再次使用模板创建集群，点击提交按钮后，显示“无效的业务IP”错误信息，修复失败4、删除所有5台服务器中/etc/hosts下所有手工添加的信息，然后执行/opt/huawei/Bigdata/om-server/om/inst/uninstall.sh卸载 Manager，重新执行preinstall后再重新安装安装Manager，再次使用模板创建集群，点击提交按钮后，执行第一步校验请求参数报错，页面显示报错信息为 the hostname already exists，修复失败5、将所有安装文件删除，重新解压安装包，从头重来一次（因目录已挂载成功，所有将preinstall.ini中 g_parted值设为0）,在FIM中使用模板安装集群，成功。问题【四】：安装集群后有两个告警信息问题现象：集群安装完成后，在FIM中有两个告警信息-“主要配置文件出错”，分别是在gsmcdn001及gsmcdn002中原因分析：查看日志中的报错信息为/etc/fstab中的UUID “XXXXXXXXXX”与mount的UUID XXXXXXXX不一致，猜测是由于这两台服务的目录挂载是手工执行的，可能与脚本自动挂载的不一致。查看其它3台正常服务器中的/etc/fstab文件与有告警信息的2台服务器做对比，发现有告警信息的服务器中是 UUID="XXXXXXXX"，而正常服务器中为UUID=XXXXXXXX解决方案：删除多余的双引号，再执行mount -a，然后再次执行日志中记录报出告警的shell脚本，shell脚本执行通过，无异常。再等待一段时间后，告警自动消除。

Cognos11.0.12 对接GaussDB A 8.01.       Cognos 介绍        Cognos是IBM公司研发的一款BI工具，实现了企业级的交互式数据库查询和报表生成。它不仅能够让企业的每一位员工都能够轻松自如地访问企业重要数据，有效地管理其业务，还能对企业数据进行多维分析和统计汇总，为企业管理者决策提供依据。cognos11与cognos10相比，变动较大。2.       环境准备GaussDB A已经安装完成。Cognos已经安装完成。Framework Manager已经安装完成。本文验证所用Cognos及GaussDB A的版本和操作系统信息如下：软件版本操作系统IBM cognos11.0.12Redhat6.5GaussDB A8.0.0Redhat 7.43.       使用JDBC对接cognos113.1 在Cognos 服务器端配置 GaussDB A JDBC 驱动        在Cognos服务器端配置GaussDB A的JDBC驱动后，Web端才可以通过JDBC连接GaussDB A，并将GaussDB A设置为数据源以完成对接。解压GaussDB A安装包获得JDBC驱动包 jar。                将JDBC驱动 jar 复制到Cognos的安装目录下的：<cognos install>/drivers。（与cognos10版本的配置路径有差异）。将jar 重命名为 postgresql-9.4.1202.jdbc42.jar。（cognos10版本的需改成postgresql-9.4-1201.jdbc4.jar）。重启Cognos服务使配置生效。    ----结束3.2 在Cognos Web 端将GaussDB A 配置为数据源         在Cognos Web端将GaussDB A配置为数据源后，Framework Manger可以将GaussDB A数据制作成数据包，并发布到Cognos服务端，最终由Cognos Web端的Report Studio根据已发布的数据包自定义生成报表。打开浏览器通过 http://serverIP:9300/bi访问Cognos server。例如：访问 http://189.122.105.25:9300/bi        点击左下角“管理”进入管理界面后选择“管理控制台”，跳转到新的界面，点击“配置”标签，单击右上角的（新建数据源）。        配置数据源，通过JDBC连接GaussDB A。输入名称，单击“下一步”。        类型中选择标准JDBC，单击“下一步”。        将 JDBC URL: jdbc:postgresql://<host>:<port>/<database-name> 替换为实际值。登录中的用户信息和密码使用可连接到数据库的用户帐号及密码。        说明：基于安全考虑，GaussDB A已禁止使用omm用户进行远程连接。故需要使用自行创建的用户，例如 “test_user”。配置结束后单击“测试连接”。        单击“测试”，查看能否成功连接数据源。        如下表示数据源连接成功。        保存数据源配置生成数据源。            ----结束3.3 测试报表是否可直连数据库随便找一张报表，点击编辑报表。        点击左侧工具栏“查询”-“查询”，然后再点击左侧工具栏“工具箱”（锤子图标）。                拖动查询下面的“sql”图标到右侧，然后点击右上角“显示属性”。        点击“数据源”，选择前面配置的数据源JDBC_TO_GaussDB，点击确定。        点击右侧“sql”后面的…按钮，打开sql窗口。输入查询语句，点击验证。        验证通过。        如果第6步报以下错误，可以从pg官网下载postgresql-9.4.1202.jdbc42.jar驱动，按照上面的方法重新配置。                        4.       使用ODBC对接cognos11        以下操作在cognos服务器上操作。4.1 准备并安装驱动网上下载以下软件源码包：名称网址附件postgresql-9.2.4.tarhttps://www.postgresql.org/ftp/source/v9.2.4/       https://ftp.postgresql.org/pub/source/v9.2.4/20M左右，可从官网下载。该包的作用是，odbc可能会用到pg的一些lib库文件。unixODBC-2.3.0.tar.gzftp://ftp.unixodbc.org/pub/unixODBCpsqlodbc-12.00.0000.tar.gzhttps://www.postgresql.org/ftp/odbc/versions/src/ 依次解压并编译安装（需要编译为32位的）        注意：如果原来系统里面已经安装过上面三个软件需要先卸载后再安装。         #postgresql        ./configure  CFLAGS="-m32"  --without-readline --without-zlib --prefix=/usr/local/pgsql/        make        make install        #unixODBC         ./configure  CFLAGS="-m32"  --prefix=/usr/local/unixodbc/        make        make install        #pgsqlodbc        ./configure  CFLAGS="-m32"  --prefix=/usr/local/psqlodbc/ --with-unixodbc=/usr/local/unixodbc/ --with-libpq=/usr/local/pgsql/         使用odbcinst –j 进行测试 ，确定使用的是新安装的unixodbc ，如果不是，需要设置PATH         配置DSN        修改 vi $ODBCINI ,添加 如下内容       [TRCBDB]       Driver=/usr/local/psqlodbc/lib/psqlodbcw.so       Servername=10.16.87.113       Port=25308       Database=trcbdb       Username=etl_usr       Password=etl_usr@123       Sslmode=allow 测试连接       [root@cognos02 analytics]# isql -v TRCBDB       +---------------------------------------+       | Connected!                            |       |                                       |       | sql-statement                         |       | help [tablename]                      |       | quit                                  |       |                                       |       +---------------------------------------+       SQL>         重启cognos        [root@cognos02 bin64]# pwd        /cognos/analytics/bin64        [root@cognos02 bin64]# ./shutdown.sh        JAVA_HOME is /cognos/jdk1.8.0_171        JRE_HOME is        JAVA_CMD is /cognos/jdk1.8.0_171/bin/java        正在停止服务器 cognosserver。        服务器 cognosserver 已停止。        [root@cognos02 bin64]# ./startup.sh        JAVA_HOME is /cognos/jdk1.8.0_171        JRE_HOME is        JAVA_CMD is /cognos/jdk1.8.0_171/bin/java        COGNOS_INSTALL_DIR is /cognos/analytics        LD_LIBRARY_PATH is set to /cognos/analytics/bin64:.::/usr/local/nz/lib:/lib64/:/usr/local/lib/:/usr/local/pgsql/lib/:/usr/local/psqlodbc/lib:/usr/local/nz/lib:/lib64/:/usr/local/lib/:/usr/local/pgsql/lib/:/usr/local/psqlodbc/lib        正在启动服务器 cognosserver。        服务器 cognosserver 已启动，进程标识为 128015。 4.2 在cognos 服务端配置odbc 连接登录cognos服务端，如：http://10.16.86.35:9300/bi/ 输入用户密码        进入管理控制台，新建数据源GaussDBODBC。                        填写ini中配置的数据源TRCBDB        点击测试链接，成功。         4.3 测试报表是否可直连数据库随便找一张报表，点击编辑报表。        点击左侧工具栏“查询”-“查询”，然后再点击左侧工具栏“工具箱”（锤子图标）。                拖动查询下面的“sql”图标到右侧，然后点击右上角“显示属性”。        点击“数据源”，选择前面配置的数据源GaussDBODBC，点击确定。        点击右侧“sql”后面的…按钮，打开sql窗口。输入查询语句，点击验证。        验证成功。        5.       GaussDB A 8.0.0对接cognos11遇到的问题5.1 问题描述1、对接cognos10版本时，客户的cognos10安装在windows server服务器上，使用GaussDB A 8.0.0安装包中的odbc和jdbc驱动，按照GaussDB A 8.0.0产品文档的操作配置odbc和jdbc后可以正常对接cognos10。2、对接cognos11版本时，客户的cognos11安装在linux系统上（5），使用GaussDB A 8.0.0安装包中的jdbc驱动，按照congnos10版本的配置方法配置后，数据源可以正常配置。但在cognos工具直连数据库取数据时报错。报错信息如下：                3、对接cognos11版本时，客户的cognos11安装在linux系统上（5），使用GaussDB A 8.0.0安装包中的odbc驱动，按照GaussDB A 8.0.0产品文档的操作配置odbc后，在linux系统后台执行isql -v TRCBDB可正常连接到集群，但在cognos11配置odbc数据源后会报下图中的错。        5.2  解决方案        针对5.1中2和3的问题，最终发现是驱动使用的问题。官网原文如下：Before making the datasource connection in IBM Cognos Administration you will need to make sure that you have installed the 32bit PostgreSQL ODBC driver。Once this is complete you will need to download the necessary JDBC driver file(postgresql-9.4.1202.jdbc42.jar) from the PostgreSQL Site then copy that to the <cognos install>/drivers directory.详细内容见后面网址或图片。ODBC解决方法        cognos11要求odbc是32位的驱动，并且要使用32位的unixodbc，GaussDB A 8.0.0暂无linux下的32位驱动，都是64位的。下载psqlodbc、unixODBC、postgresql源码包，编译安装。详细过程见第4章使用ODBC对接cognos11。JDBC解决方法        cognos11中对pg的jdbc要求的版本与cognos10要求的不一样，cognos11要求postgresql-9.4.1202.jdbc42.jar，cognos10要求postgresql-9.4-1201.jdbc4.jar。可以下载官方要求的jdbc驱动版本或者按照第3章使用jdbc对接cognos11中的方法把GaussDBA的jdbc驱动名称改名为要求的名字。附：官方驱动安装说明，链接中网页最下面有对应驱动的下载地址。https://www.ibm.com/support/pages/node/302939    （cognos11）https://www.ibm.com/support/pages/node/530621    （cognos10）

GaussDB(DWS)存在丰富的审计日志记录信息，通常客户现场存在审计需求时，往往需要记录长历史全部数据库访问信息；默认情况下，数据库为保护自身存储空间，audit_space_limit默认控制保留1GB日志空间，远远无法满足客户对审计的分析、挖掘需求；故促使我们需要实践审计日志转储。1 实施设计打开相关审计日志开关；开启审计audit_enabled = on; (默认打开)除了默认开启的审计内容，其它可参照打开，打开用户访问越权：audit_user_violation 0 -> 1;数据库对象操作：audit_system_object 12295 -> 524287;DML除select操作：audit_dml_state 0 -> 1;Select操作：audit_dml_state_select 0 -> 1;函数操作：audit_function_exec 0 -> 1;COPY操作： audit_copy_exec 0 -> 1;创建转储数据库用户表固化系统级schema，用于存储审计日志，如pg_audit;转储用户表命名: pg_audit.audit_dtl;同时设计成列存合并文件表（colversion=2.0）；设计转储审计表分区定义保留最近7天每天一个分区，用户可以快速查询、挖掘近期审计；此外，历史每月一个分区；分区命名格式：<表名>_<YYYYMMDD> 或 <表名>_<YYYYMM>每隔2小时，转储10分钟前审计日志，并删除转储走的审计日志；设置2小时，目的是防止超2小时，审计日志超过默认系统定义的1GB，导致审计日志遗漏；只转储10分钟前的日志，避免10分钟内审计日志还在异步变动的，导致转储过程中遗漏；2 实践代码2.1 审计转储用户表用户表：Create table if not exists pg_audit.audit_dtl(Audit_date date,Audit_time timestamp,Type varchar(100),Result varchar(100),Usename varchar(100),Database varchar(100),Client_conninfo varchar(500),Object_name varchar(100),Detail_info text,Node_name varchar(100),Thread_id varchar(500),Pid bigint,Query_id bigint,Local_port varchar(100),Remote_port varchar(100))With ( orientation=column, compression=Middle, colversion=2.0)Distribute by hash(pid)Partition by range ( audit_date )(Partition audit_dtl_202103 values less than (‘2021-03-18’::date),Partition audit_dtl_20210318 values less than (‘2021-03-19’::date),Partition audit_dtl_20210319 values less than (‘2021-03-20’::date),Partition audit_dtl_20210320 values less than (‘2021-03-21’::date),Partition audit_dtl_20210321 values less than (‘2021-03-22’::date),Partition audit_dtl_20210322 values less than (‘2021-03-23’::date),Partition audit_dtl_20210323 values less than (‘2021-03-24’::date),Partition audit_dtl_20210324 values less than (‘2021-03-25’::date))Enable row movement;转储控制表：Create table if not exists pg_audit.audit_dtl_ctl(Ctl_typ varchar(20),Ctl_val varchar(500)) With ( orientation=column, compression=Middle, colversion=2.0)Distribute by hash(Ctl_typ);插入初始值：Insert into pg_audit.audit_dtl_ctl values( ‘last_partition’,’1900-01-01’);Insert into pg_audit.audit_dtl_ctl values( ‘last_status’,’1900-01-01 00:00:01’);删除已转储审计日志：（系统只提供了单CN审计日志清理，封装一层所有CN日志清理函数）Create or replace function public.pgxc_delete_audit(starttime timestamp with time zone,endtime timestamp with time zone)Returns BooleanLanguage plpgsqlNot fenced not shippableAs $$Declare    row_name record;   query_str text;   query_str_nodes text;   Beginquery_str_nodes := ‘select node_name from pgxc_node where node_type=’’c’’’;For row_name in execute (query_str_nodes) loop   query_str := ‘execute direct on (‘||row_name.node_name||’) ‘’select pg_delete_audit(‘’’’’||start_time||’’’’’,’’’’’||end_time||’’’’’)’’’;   execute query_str;end loop;return true;   end; $$2.2 Gsql代码\timing on /* 程序参数提取 */Select 7 as partition_interval /* 保留最近7天每日分区 */,10 as tm_interval /* 每次提取10分钟前审计日志 */,Case when ctl_val::date=current_date then 0 when extract(month from current_date- partition_interval+1) != extract(month from current_date- partition_interval) then 2else 1end as is_create_prt /* 是否处理 */,to_char(current_date- partition_interval+1,’YYYYMMDD’) as p1,to_char(current_date- partition_interval+1,’YYYYMM’) as p2,to_char(current_date +1,’YYYYMMDD’) as p3,to_char(current_date +2,’YYYY-MM-DD’) as p4,‘\copy’ as cp,‘’’’ as queteFrom pg_audit.audit_dtl_ctlWhere ctl_typ=’last_partition’;\if ${ERROR} \goto WITHERROR \endif \if ${ is_create_prt} == 1 \goto merge_part \elif ${ is_create_prt} == 2 \goto create_month \else \goto insert_audit \endif/* 跨月分区合并 */\label create_monthAlter table pg_audit.audit_dtl rename partition audit_dtl_${p1} to audit_dtl_${p2};\goto create_cur/* 合并最旧一日分区到月份中 */\label merge_partAlter table pg_audit.audit_dtl rename partition audit_dtl_${p2} to audit_dtl_${p2}_bak;\if ${ERROR} \goto WITHERROR \endifAlter table pg_audit.audit_dtl merge partition audit_dtl_${p2}_bak, audit_dtl_${p1}  into partition audit_dtl_${p2};\if ${ERROR} \goto WITHERROR \endif/* 新增当日分区 */\label create_curAlter table pg_audit.audit_dtl addpartition audit_dtl_${p3} values less than (‘${p4}’::date);\if ${ERROR} \goto WITHERROR \endifUpdate pg_audit.audit_dtl_ctlSet ctl_val=to_char(current_date,’YYYY-MM-DD’)Where ctl_typ=’last_partition’;\if ${ERROR} \goto WITHERROR \endif/* 审计日志提取、转储,采用copy性能更佳 */\label insert_auditSelect ctl_val as lst_tm,to_char(current_timestamp-interval ‘${tm_inerval}’ minute,’YYYY-MM-DD HH24:MI:SS’ as new_tm from pg_audit.audit_dtl_ctl where ctl_typ=’last_status’;/* 元命令，清理临时数据 */\! rm -f /tmp/.tmp_audit_dtl/* 输出审计日志 */\o /tmp/.tmp_audit_dtl.sql\qecho ${cp} (select time::date,time,type,result,username,database,client_conninfo,object_name,detail_info,node_name,thread_id,case when thread_id=${quote}null${quote} then null else split_part(thread_id, ${quote}@${quote},1) end as pid, case when thread_id=${quote}null${quote} then null else split_part(thread_id, ${quote}@${quote},2) end as query_id,local_port,remote_port from pgxc_query_audit(${quote}${lst_tm}${quote}::timestamp, ${quote}${new_tm}${quote}::timestamp) ) to ${quote}/tmp/.tmp_audit_dtl${quote} with (delimiter ${quote}<@|@>${quote},format ${quote}csv${quote},encoding ${quote}UTF8${quote});\o \i /tmp/.tmp_audit_dtl.sql\if ${ERROR} \goto WITHERROR \endif \copy pg_audit.audit_dtl from ‘/tmp/.tmp_audti_dtl’ with (delimiter ‘<@|@>’,format ‘csv’,encoding ‘UTF8’);\if ${ERROR} \goto WITHERROR \endifUpdate pg_audit.audit_dtl_ctlSet ctl_val=’${new_tm}’Where ctl_typ=’last_status’;\if ${ERROR} \goto WITHERROR \endif/* 删除转储的原审计日志 */Select public.pgxc_delete_audit(‘${lst_tm}’::timestamp,’${new_tm}’::timestamp);\if ${ERROR} \goto WITHERROR \endif \goto FINISH \label WITHERROR \! Rm -f /tmp/.tmp_audit_dtl \q 1\label FINISH \! Rm -f /tmp/.tmp_audit_dtl \q 02.3 循环执行添加到crontab中每隔2小时执行

一、从OBS上读数据并导入DWS进入OBS控制台，新建桶dws-test20210316及对象testobs1。上传txt数据文件到obs上。连接DWS集群建立内表table1，以及obs外表table1_inobs_ft。CREATE FOREIGN TABLE table1_inobs_ft(like  table1)SERVER gsmpp_server OPTIONS(LOCATION 'obs://dws-test20210316/testobs1/text1.txt',FORMAT 'text' ,DELIMITER ',',ENCODING 'utf8',HEADER 'false',ACCESS_KEY 'U76V66',SECRET_ACCESS_KEY 'qCJyo9B',FILL_MISSING_FIELDS 'true',IGNORE_EXTRA_DATA 'true')READ ONLY LOG INTO product_info_err PER NODE REJECT LIMIT 'unlimited';注意：ACCESS_KEY，SECRET_ACCESS_KEY 是在“我的凭证”—“访问密钥”中下载。首次申请密钥后会提示下载。读取obs数据Select * from table1_inobs_ft;导入OBS数据到DWSinsert into table1 select * from table1_inobs_ft;二、DWS导出数据到OBS在桶dws-test20210316中新建对象output1，设置可读写。创建table1的obs导出外表CREATE FOREIGN TABLE table1_outobs_ft (like  table1)SERVER gsmpp_server OPTIONS(LOCATION 'obs://dws-test20210316/output1/',FORMAT 'text',ENCODING 'utf8', DELIMITER ',', ENCRYPT 'off',ACCESS_KEY 'U7DGJ6V66',SECRET_ACCESS_KEY 'qC9B') WRITE ONLY;导出数据到obsinsert into table1_outobs_ft select * from table1;建立外表读取上步骤导出的数据（LOCATION 中table1_outobs_ft表示所有以table1_outobs_ft开头的文件）CREATE FOREIGN TABLE table1_selobs_ft (like  table1) SERVER gsmpp_server  OPTIONS(LOCATION 'obs://dws-test20210316/output1/table1_outobs_ft',FORMAT 'text' ,DELIMITER ',',ENCODING 'utf8',HEADER 'false',ACCESS_KEY 'U7D66',SECRET_ACCESS_KEY 'qCJycqn0wo9B',FILL_MISSING_FIELDS 'true',IGNORE_EXTRA_DATA 'true')READ ONLY ;select * from table1_selobs_ft;