认知GaussDB
GaussDB是一个RDBMS关系型数据库，从2002年开始研发的数据库，到目前为止已经有19个年头了，全部都是由华为内部开发，自主可控，其中：
- GuassDB T是华为自研，对标Oracle。
- GuassDB A是基于PostgreSQL的开源面向MPP研发，对标Teredata。
GaussDB T / A : 从 100 到 200 和 300 命名的变迁
- 最初，华为的数据库公布出来的型号系列有三款，分别是 100、200 和 300，统一的命名都是 GaussDB。
- GaussDB 100，更名为 GaussDB T，以 OLTP为方向，最初和招商银行联合研发，然后推广，在 2020年6月，将会开源单机版本；
- GaussDB 200，以 PostgreSQL 为出发点，面向 MPP 研发，工商银行率先尝试使用，然后推广；
- GaussDB 300，以 HTAP 为方向，民生银行尝试使用。
在2019年10月左右，华为 GaussDB的命名再次调整：
- GaussDB 100，更名为 GaussDB T，以 OLTP 和集群为方向；
- GaussDB 200 合并 300 的部分设计，更名为 GaussDB A，以分析型为主方向；
- GaussDB 300，型号取消，涉及功能并入 100 或 200 。
Gaussdb T 有单机、HA、分布式集群三种架构，及后续的RAC 集群架构。
Gaussdb T 的三种架构中，单机是基本架构；HA是多套单机组成，可以是1主1备、1主2备等；分布式集群由多套HA组成，一般是多套1主2备组成。
GaussDB组成
注：为便于理解，以Oracle数据库为对比进行解释。
与Oracle数据库一样，GaussDB由实例和数据库组成，数据库是一系列的文件，实例是进程加内存结构（只有SGA，没有PGA）。
数据文件主要有3种：
- DATA FILE，数据文件，用于存放各种数据，单库最多1024个数据文件，每个数据文件最大8T(undo除外，undo最大32G)
- LOG FILE，日志文件，用于存放redo日志，可以重复使用，最少3组，每个redo 日志文件一般建议5-20G
- CONTROL FILE，控制文件，用于数据库名、数据文件位置等信息，在数据库启动到mount阶段时会检查。
实例层面有6个核心线程，用途跟Oracle一样，没有pmon线程（因为只有一个守护进程，不需要操作系统层面清理进程，直接数据库中关闭线程即可），多了一个STAT线程：
- DBWR，数据写线程，用于把脏数据写到磁盘，默认有8个线程，有多种方式控制写脏数据到磁盘。
- LOWR，日志写线程，用于把redo日志写到磁盘，跟oracle一样，有多种方式控制写日志到磁盘。
- CKPT，检查点线程，用于控制检查点。
- SMON，用于实例恢复，UNDO前滚等。
- ARCH，归档日志线程，用于控制切换归档日志。
- STAT，统计信息线程，用于收集对象统计信息的。
内存结构上，基本也跟oracle一样，不过多了一个cr pool：
- Data buffer，数据缓存区，缓存表索引等数据。
- Log buffer，日志缓存区，缓存redo日志。
- Shared pool，共享池，缓存SQL语句、执行计划等信息。
- Temporary buffer，排序用，不够时直接放临时表空间。
- Large pool，大池，存放较大的SQL。
- Cr pool，一致性读池，用于构建一致性读的数据块，与Oracle不一样的地方。
数据文件的构造，跟Oracle一样，由段、区、块组成。默认1个块是8K，一个区是8个块，在创建表时指定，暂时还没有自动扩展区的功能，因此如果是大表，在创建的时候建议直接指定2M或者更大的区，否则频繁插入时会出现高水位等待事件。
连接上，跟Oracle差不多，由一个lsnr线程监听，如果有客户端发起连接，判断符合条件即可建立会话，由reactor控制连接池，这一点跟Oracle也不一样。
GaussDB T的启动进程只有一个，跟MySQL数据库一样，是通过线程控制的，杀会话也只能在数据库中进行，不能像Oracle一样在操作系统层面杀进程来断开会话。
数据仓库服务 GaussDB(DWS)
数据仓库服务（Data Warehouse Service，简称DWS）是完全托管的企业级云上数据仓库服务，具备免运维、在线扩展、高效的多源数据加载能力，兼容PostgreSQL生态。助力企业经济高效地对海量数据进行在线分析，实现数据快速变现。
云产品服务介绍：
https://bbs-video.huaweicloud.com/upload/videos/media/20171031/20171031173758_30785.mp4
GuassDB T单机版部署
具备分析及混合负载能力的分布式数据库，支持x86和Kunpeng硬件架构，支持行存储与列存储，提供PB(Petabyte)级数据分析能力、多模分析能力和实时处理能力，用于数据仓库、数据集市、实时分析、实时决策和混合负载（HTAP）等场景，广泛应用于金融、政府、电信等行业核心系统。
软件下载地址：
https://support.huawei.com/enterprise/zh/cloud-computing/gaussdb-200-pid-21407429/software
华为数据库相关工具下载地址：
https://support.huaweicloud.com/tg-dws/dws_07_0002.html
文档下载地址：
https://support.huawei.com/enterprise/zh/fusioninsight/gaussdb-200-pid-21407429?category=
product-documentation-sets
注：曾经安装部署过Sybase、DB2、Oracle、HDP、CDH等的，对于这样的部署和基于linux命令行的安装应该不存在问题，其中也不太需要过多的对系统打补丁。但是最好还是联网进行部署。
DSC（Database Schema Convertor）
当客户选择切换到DWS数据库后可能会面临数据库的迁移任务，数据库迁移包括用户数据迁移和应用程序sql脚本迁移，其中，应用程序sql脚本迁移是一个复杂、高风险且耗时的过程。
- DSC（Database Schema Convertor）是一款运行在Linux或Windows操作系统上的命令行工具，致力于向客户提供简单、快速、可靠的应用程序sql脚本迁移服务，通过内置的语法迁移逻辑解析源数据库应用程序sql脚本，并迁移为适用于GaussDB T、GaussDB A 和 DWS数据库的应用程序sql脚本。
- DSC不需要连接数据库，可在离线模式下实现零停机迁移，迁移过程中还会显示迁移过程状态，并用日志记录操作过程中发生的错误，便于快速定位问题。
- 工具支持从Teradata到 GaussDB A和DWS的迁移，包括模式、DML、查询、系统函数、类型转换等。
迁移对象
- DSC支持迁移Teradata、Oracle、Netezza、MySQL、DB2数据库的对象有：
- Oracle、Teradata、Netezza、MySQL、DB2支持的通用对象：SQL模式，SQL查询
- 仅Oracle和Netezza支持的对象：PL/SQL
- 仅Teradata支持的对象：包含BTEQ和SQL_LANG脚本的Perl文件
迁移流程
DSC迁移sql脚本流程如下：
- 从Teradata或Oracle数据库导出待迁移的sql脚本到已安装了DSC的Linux或Windows服务器。
- 执行DSC命令进行语法迁移，命令中指定输入文件路径、输出文件路径以及日志路径。
- DSC自动将迁移后的sql脚本和日志信息归档在指定路径中。
安装部署及使用白皮书：
https://support.huaweicloud.com/tg-dws/dws-tg.pdf
执行Teradata SQL迁移
执行以下命令设置源数据库、输入和输出文件夹路径、日志路径和应用程序语言：
Linux命令行:
./runDSC.sh
--source-db Teradata
[--input-folder ]
[--output-folder ]
[--log-folder ]
[--application-lang SQL] Windows命令行:
runDSC.bat
--source-db Teradata
[--input-folder ]
[--output-folder ]
[--log-folder ]
[--application-lang SQL] 以示例文件夹路径为例，命令如下：
Linux:
./runDSC.sh --source-db Teradata --target-db GaussDBA --input-folder /opt/DSC/DSC/input/teradata/ --output-folder /opt/DSC/DSC/output/ --log-folder /opt/DSC/DSC/log/ --application-lang SQL --conversion-type BulkWindows:
runDSC.bat --source-db Teradata --target-db GaussDBA --input-folder D:\test\conversion\input --output-folder D:\test\conversion\output --log-folder D:\test\conversion\log --application-lang SQL --conversion-type Bulk在工具执行时，控制台上会显示迁移汇总信息，包括迁移进度和完成状态。执行信息和错误会录入日志文件。
********************** Schema Conversion Started *************************
DSC process start time : Mon Jan 20 17:24:49 IST 2020
Statement count progress 100% completed [FILE(1/1)]
Schema Conversion Progress 100% completed
**************************************************************************
Total number of files in input folder : 1
**************************************************************************
Log file path :....../DSC/DSC/log/dsc.log
DSC process end time : Mon Jan 20 17:24:49 IST 2020
DSC total process time : 0 seconds
********************* Schema Conversion Completed ************************迁移使用说明
- 迁移过程中，输入脚本的元数据保存在以下文件中，允许迁移调用这些元数据；当迁移Teradata时，使用teradata-set-table.properties。
- 以下迁移场景时，需要清空上述文件：不同文件的迁移；相同文件的迁移，但是参数配置不同。
迁移设计及流程
需要梳理具体有哪些工作，哪些事项，再对各项工作进行计划安排，其主要工作有：范围分析、环境准备、数据模型迁移、数据初始化、脚本迁移、调度迁移、数据一致性校验、应用切换等工作。
其中首先要清楚的是，迁移绝对不是一次成功的，必然是要迭代进行的，一定是迁移-数据校验-发现问题改进-迁移-数据检验-发现问题改进-….。
- 范围分析：范围分析工作看着比较虚，实则非常重要。因为如果在范围分析阶段，少分析了一张表，甚至一个视图，这种缺失经常在最终的数据校验阶段才能被发现，这意味着，必须有下一轮的迁移迭代，这个成本无疑是巨大的。
- 环境准备：主要是测试环境和生产环境中数据库、ETL、调度等环境的准备。
- 数据模型迁移：此处的模型指的是表、视图等结构。要实现迁移，首先要把模型迁移到GaussDB。
- 数据初始化：主要是将Teradata上的初始化截面数据复制到GaussDB中，作为初始化数据。
- 脚本迁移：脚本的迁移其实就是语法的迁移。整个迁移中，脚本迁移是重中之重，虽然不是耗时最长、最困难的，但一定是最具技术挑战的。使用上述DSC工具，在配合人工对于特出场景进行处置；且注意保留日志等进行追述。
- 调度迁移：主要是将原本在数据仓库调度系统中的作业配置迁移到新一代调度系统中。
- 数据一致性校验：如果脚本迁移是最具技术挑战的环节，那么数据一致性校验就是最困难、耗时耗力最大的一个环节。如果迁移时间是10分，那么数据初始化要占3分，所有的模型迁移、脚本迁移、作业迁移、性能优化等一堆工作占3分，最后的4分都是在做数据的一致性校验，而且这还是在我们的数据一致性校验工具在做到极致的情况下。整个迁移产出的一系列工具中，让我们最有成就感、做得最极致的，也是这个数据一致性校验工具。
- 应用切换：应用系统在确认迁移数据质量满足其加工需求后，将数据源从Teradata切换成GaussDB。
迁移特定关注要点
通过范围分析，一般能获取需迁移的作业范围、脚本范围、模型范围、和数据范围，但这些范围可能无法一下子做到完全准确，需要后面迁移的过程中不断地迭代，不断地完善：
- 作业依赖不能完全体现实际上的加工依赖，导致部分需迁移范围不能通过最开始的范围分析确定出来，有些缺失的范围需在后续的测试、数据验证阶段发现。
- 除对应用加工模型有经验丰富人员外，初始化数据范围分析通常需要范围分析人员通过深入脚本阅读代码的方式来分析、确定初始化的数据范围，效率较低，且容易有遗漏、缺失。
数据模型迁移，其实就是把Teradata的物理表结构和视图结构迁移到GaussDB上，主要分如下几个步骤：
- 范围分析：分析出具体有哪些表或者视图，即可以通过写脚本工具的方式，从需要迁移的脚本中批量获取到需要迁移的表和视图清单。但这种方式只能识别面上一层的模型，也就是在脚本中有直接使用到的表和视图，至于这些表和视图是怎么加工出来的，脚本工具就没办法获取到。如果是物理表，它的数据血缘可能会体现在作业依赖上，当然也不一定完全准确。但更重要的是分析出来的需要迁移的视图或表是依赖于其他视图或物理表生成的，这个依赖关系不会体现在作业依赖上，只体现在模型语句中，所以这需要在后续的转换后模型创建步骤中，逐步发现缺失模型，不断完善分析出的数据模型迁移范围。
- 批量模型转换：根据Teradata和GaussDB语法差异，使用DSC，并利用数据模型自动转换工具，批量实现物理表和视图的迁移。
- 转换后模型创建：这一过程通常需要耗费一定的时间去迭代才能最终将转换后的模型都创建成功。视图创建的时候，容易出现该视图所需要的其他视图或者物理表未迁移，而导致该视图创建不成功的情况。这就需要将该视图需要的其他视图或者物理表加入到迁移范围中，再重新梳理更新需要迁移的作业范围、脚本范围、模型范围和数据范围。更新完后，再将新分析出来并转换完后的模型再进行创建，若又发现有模型的缺失，则需要再更新各迁移范围，依此类推，不断地迭代更新迁移范围。
- 脚本空跑：是验证数据模型迁移范围是否完备的重要一步，只有真正的脚本空跑过了，才能算是数据模型迁移范围的基本确定。当然后面数据验证的时候，也可能会发现一些模型的缺失，但一般不会太多。
迁移数据初始化
数据初始化主要是将Teradata上的初始化截面数据复制到GaussDB中，在做数据迁移的时候，需要使用数据同步组件或ETL工具，或华为Data Lake Governance Center等工具；当然，为了适应迁移工作的特殊性和合规性，也可以使用客户的工具及组件，并适当进行一定改造和人工处理。一般是为了数据迁移工作的效率，去掉了部分数据同步组件的自动数据校验功能，并改为由人工批量校验方式来保证数据迁移的准确性。