使用 IBM Data Studio 管理数据库最佳实践

使用 IBM Data Studio 管理数据库最佳实践

简介

从 DB2 V10.1 开始, DB2 控制中心将不再成为随着 DB2 一起发布的数据库工具,取而代之的是 IBM Data Studio3.1.1。Data Studio 是一个基于 Eclipse 的综合工具平台,它主要提供数据库的管理,数据库应用程序的开发功能,同时它也集成了 IBM Optim 家族中另一款产品 OQWT 的 SQL 调优的基本功能,而且这些功能都是免费的 , 另外 IBM Data Studio3.1.1 的工具包中还包一个叫 Web Console 的工具,它允许你从浏览器监测数据库的性能和状态。DB2 控制中心所能完成的所有的数据库的管理功能,Data Studio 都可以实现,并且在 Data Studio3.1.1 中对这些功能还做了很多的改进,同时也增加了一些 DB2 控制中心不具备的数据库管理功能,对此,您可以在 DB2 的信息中心了解更为详细的信息。 作为一款即将成为主流的数据库工具,为了让 DB2 控制中心的老用户和希望使用 Data Studio 的新用户更快的掌握 Data Studio 的数据库管理功能,笔者对用户在使用 Data Studio 进行数据库管理操作容易产生迷惑和出错的地方做了归纳,并通过几个典型的实例来和大家分享这些操作。本文主要演示实例操作,若您想对 Data Studio 的数据库对象的编辑功能有全面的了解,请参阅文章 IBM Data Studio 3.1 的数据库对象编辑利器 Unified Object Management Editor

实例一 :对一个表的数据进行导出操作

本实例讲解用 Data Studio 对远程数据库中的表数据进行导出操作。

操作步骤

1. 创建数据库连接

启动 Data Studio,打开 Admininstrator Explorer 视图,点击 New->New Connection to a Database, 在弹出的新建连接向导中,在 Connection name 文本框指定数据库连接的显示名称,本例采用默认名称 UOMDB。输入数据库的连接信息,确保你输入的用户有足够的数据库操作权限,本例使用 DB2 实例用户连接数据库,然后点击 Finish 按钮。请参考图 1:

图 1. 新建数据库连接向导
新建数据库连接

2. 在 Administrator Explorer 视图下,找到刚才新创建的连接,展开数据库 UOMDB 下的节点。点击文件夹 Tables, 你会看到 UOMDB 下所有的表在 Data Studio 的数据库对象列表编辑视图中打开。右键点击一个包含数据的表,选择 Unload -> With Export Utility,本例使用的测试表 DB2INST3.MYTB02,请参考图 2:

图 2. 在表的列表编辑视图中选择 Export 工具
在表的列表编辑视图中选择 Export 工具

此时,导出表数据的任务向导会被打开,请参考图 3:

图 3. 表数据的导出向导
表数据的导出向导

3. 在导出任务向导中的 Target 页面,点击 Path 文本框右侧的 Browse 按钮。此时如果数据库服务器所在的机器上没有启动 SSH 服务, 那么您将会看到如下的对话框弹出表明您数据库服务器上没有启动 SSH 服务,您将无法选择导出路径。请参考图 4:

图 4. 数据库服务器上 SSH 没有启动的提示框
数据库服务器上 SSH 没有启动的提示框

请首先确保您的数据库服务器启动了 SSH 服务,再次重做以上步骤,那么您将会看到如下的对话框弹出让您选择表数据要导出的路径。

图 5. 在数据库服务器上选择导出表数据的路径
在数据库服务器上选择导出表数据的路径

选择连接数据库的实例用户 db2inst3 的用户目录下的 exportdata 目录,点击 OK. 再在导出向导的 File Name 文本框中输入导出的文件名为 mytb02_exportdata,保持其它设置为缺省值。点击导出表数据向导中的链接 Preview Command, 您将看到为导出操作产生的 DDL,请参考图 6:

图 6. 预览生成的表数据导出 DDL
预览生成的表数据导出 DDL

4. 在上图中点击按钮 Run, 你将会在 Data Studio 的 SQL Results 视图中看到在执行导出的语句时有以下 Warning 产生:

1
2
3
4
5
SQL3104N The Export utility is beginning to export data to file
"/home/db2inst3/exportdata/mytb02_exportdata".
SQL3001C An I/O error (reason = "sqlofopn -2079391743") occurred
while opening the output file.
 SQL3105N The Export utility has finished exporting "0" rows.

从结果看出,产生输入输出错误,没有一行数据导出,请参考图 7:

图 7. 导出时的 I/O 错误
导出时的 I/O 错误

此时用户应该注意: Data Studio 是采用 ADMIN_CMD 的用户功能函数 UDF 来执行导出操作,而这个 UDF 是用 DB2 的防护用户 (Fenced User) 在 DB2 的地址空间外执行。所以我们应该确保指定一个 DB2 防护用户有写权限的导出路径。本例中 DB2 的防护用户 db2fenc3 对实例用户 db2inst3 的用户目录 /home/db2inst3 没有写权限,所以导出失败。

5. 在服务器所在的机器上创建一个 DB2 防护用户有权读写的目录 /userdata,然后在 DataStudio 的表数据导出向导上选择此目录为表数据导出目录, 再执行此导出操作,DDL 就可以成功执行,请参考图 8:

图 8. 导出数据成功
导出数据成功

实例一操作总结:

1. 当 Data Studio 客户端和数据库服务器需要通信时,确保数据库端启用了 SSH 服务,Data Studio 客户端采用 SSH 和数据服务器端通信。

2. DataStudio 采用 ADMIN_CMD 的功能函数导出表数据,此功能函数使用防护用户执行,我们需要确保 DB2 防护用户对指定的导出路径有写权限。本人建议最好实例用户和防护用户都对数据导出目录有写权限。

实例二:在不同的 schema 下迁移数据库对象

本实例将实现将一个 DB2V9.7 数据库某个 Schema 下的数据库对象和相关联的对象全部迁移到另一个 DB2V9.7 数据库下的某个 Schema 下。

环境介绍:

1. 源数据库 SAMPLE 位于 Linux 机器 A, 包含一个名为 SOURCESCHEMA 的 schema, SOURRCESCHEMA 下有一些表,其中有些表包含索引,并且用到了各自指定的表空间,不同的表空间又指定了不同的缓冲池。
2. 目标数据库 TEST 位于 Linux 机器 B,包含一个名为 TARGETSCHEMA 的 schema, TARGETSCHEMA 下没有任何表。

操作目的:

把数据库 SAMPLE 的 SOURCESCHEMA 下的表和相关联的数据库对象迁移到数据库 TEST 的 TARGETSCHEMA 下。

操作步骤:

1. 为数据库 SAMPLE 和 TEST 创建两个数据库连接。
数据库 SAMPLE 下的 SOURCESCHEMA 下包含的表如下图。在这里告诉大家一个小技巧,在 Schema 的列表编辑视图中双击一个 Schema 可以显示这个 Schema 下的所有表,请参考图 9:

图 9. 源 Schema 下的所有表
源 Schema 下的所有表

2. 在 Administrator Explorer 视图,展开数据库 TEST 的节点,点击文件夹 Schemas 打开 Schema 的列表编辑器视图,选择 TARGETSCHEMA,然后从 Data Studio 主菜单中选择 Migrate – >Compare and Migrate Objects,请参考图 10:

图 10. 在目标数据库连接中选择要同步的 Schema
在目标数据库连接中选择要同步的 Schema

3. 在接下来弹出的迁移向导中,会让您选择从那里获得要迁移的数据库对象,这里选择 Database connection,表示从当前工作区中已经创建的连接中选择。然后从列表中选择数据库 SAMPLE。请参考图 11:

图 11. 在迁移向导中选择源数据库
在迁移向导中选择源数据库

4. 在上图中点击按钮 Next。在接下来的选择源数据库对象类型的向导中,选择 Schemas,然后在对象列表中勾选 SOURCESCHEMA,点击 Add 按钮。请参考图 12:

图 12. 在迁移向导中选择源数据库对象
在迁移向导中选择源数据库对象

5. 在上图中点击 Next 按钮,会进入到迁移对象映射向导,在 Database Object 下拉列表中选择 Schema,在 In Mask 的下拉列表中选择源模式 SOURCESCHEMA,在 Out Mask 的下拉列表中选择目标模式 TARGETSCHEMA,点击按钮 Add Mask。请参考图 13:

图 13. 在迁移向导中定义模式的映射关系
在迁移向导中定义模式的映射关系

6. 在上图中点击按钮 Next,会进入源数据库对象和目标数据库的比较向导,在此向导中会列出源 Schema 和目标 Schema 下的数据库对象以及其它相关联的数据库对象。 在列表中展开节点 Schema,您会看到它们底下各自所包含的表对象。请参考图 14:

图 14. 源数据库和目标数据库同步前的比较向导
源数据库和目标数据库同步前的比较向导

7. 在比较向导中选择 Schema 行,点击比较向导中的 Copy from Left to Right 按钮,您会看到 Schema 下的所有表和其它想关联的对象 (Buffer Pools 和 Table Spaces) 都从源数据库拷贝到目标数据库,请参考图 15:

图 15. 源数据库和目标数据库同步后的比较向导
源数据库和目标数据库同步后的比较向导

8. 点击 比较向导中的 Finish 按钮,将会返回到目标数据库连接的 Schema 的编辑视图,并且 Data Studio 将为此次迁移生成一个 Change Plan,点击视图右上方绿色的 Review and deloy changes 按钮。您将会看到预览部署的对话框弹出,并显示迁移的 DDL,请参考下图 16:

图 16. 产生迁移操作 DDL 的部署预览视图
产生迁移操作 DDL 的部署预览视图

从生成的 DDL 中可看出 Schema 下的表和相关的 TableSpaces 及 BufferPools 都将会在目标数据库上创建,同时 DDL 中也包含了一些 Grant 语句和表的 Reorg 语句,但是由于一般都会由具有权限的实例用户执行这些操作,又由于目前只是迁移表结构,不需要对表进行 Reorg 操作,所以我们可以在执行 DDL 之前去掉这些 Grant 和 Reorg 语句。

9. 点击 Edit 按钮编辑产生的 DDL,会打开 SQL 编辑器,在 SQL 编辑器中删除产生的 Grant 语句和 Reorg 语句,用户也可以点击预览部署对话框右上方的 Advanced Options 按钮来定制是否产生 Reorg 语句。然后点击 SQL 编辑器右上方绿色的 Run Sql 按钮,我们可以在 Status 视图中看到迁移操作的 DDL 被成功的执行。请参考图 17:

图 17. 在 SQL 编辑器中运行编辑生成的 DDL
在 SQL 编辑器中运行编辑生成的 DDL

10. 此时,我们需要做一下清理工作,由于刚才我们并没有执行为迁移操作产生的 Chang Plan,它处于 Pending 的状态,我们是转到了 SQL 编辑器中成功执行了迁移操作。我们最好取消掉这个还未执行的 Change Plan。返回到目标数据库连接的 Schema 的列表编辑器视图,点击视图右上角红色的 X 按钮(Close Change Plan),在弹出的确认关闭对话框中选择 Discard 就可以了,当然如果我们在 DDL 的部署预览视图中直接点击 Run 按钮而不进入 SQL Editor 来执行 DDL,那么这个 Change plan 就会处于 Deployed 状态而不是 Pending 的状态了。

实例 2 操作总结:

1. 在用迁移向导在不同的 Schema 之间迁移数据库对象时,一定要在向导中做 Schema 映射,相同的 Schema 之间不需要映射操作。
2. 在用迁移向导做数据对象的迁移和实际数据的迁移时,我们很有可能需要修改生成的 DDL, 尤其是当两个数据库不在同一个物理机器上时,因为 Data Studio 是管理操作数据库,它不会去管理数据库所在的服务器。比如,当两台机器的环境不同,在源数据库服务器上的要迁移的表空间用到了容器 /home/db2inst1/tabspace.dat, 在迁移时 Data Studio 产生同样的表空间创建语句,而很有可能目标数据库的连接用户并没有权限去在目标服务器上创建或访问这个容器指定的目录,对此 Data Studio 是无法判断的。

实例三: 在多分区数据库上的分区组上创建表空间。

本实例讲解使用 Data Studio 在一个 DB2 多分区数据库的分区组 (partition group) 上创建表空间,并将指定表空间在不同分区上的容器。

环境介绍:

笔者事先搭建了一个有 4 个分区的 DB2 数据库,分区 0 和 1 位于机器 A, 分区 2 和 3 位于机器 B。数据库服务器都为 Linux 机器,数据库的名称为 UOMDB。

操作步骤:

1. 在 Data Studio 中为数据库 UOMDB 创建一个数据库连接,在 Administrator Explorer 视图,展开数据库 UOMDB 节点,右键点击文件夹 Partition Groups,选择 Create Partition Group,如下图 18:

图 18. 从 Administrator Explorer 视图中创建分区组
从 Administrator Explorer 视图中创建分区组

2. 分区组的列表编辑器视图和属性视图会被打开,在打开的属性视图中,选择 General 页面,给新的分区组命名为 PG1,点击 Partitions 文本框右边的 Edit 按钮,然后在弹出的向导中添加分区 0 和 1 和 2。请参考下图 19:

图 19. 编辑分区组
编辑分区组

3. 点击分区组列表编辑器右上方绿色的 Review and Deploy Changes 按钮,在接下来弹出的部署预览对话框中会显示创建分区组的 DDL,点击部署预览对话框上的 Run 按钮。分区组 PG1 被成功创建,请参考下图 20:

图 20. 成功创建分区组
成功创建分区组

4. 在 Administrator Explorer 视图,展开数据库连接下的 UOMDB 节点,右键点击文件夹 Table Spaces,选择 Create Regular Table Space,表空间的列表编辑器视图和属性视图会被打开。在表空间的属性视图中,选择 General 页面,指定表空间的名字为 TBSPACE1,并指定 Management 的值为 Database Managed,请参考下图 21:

图 21. 编辑新建表空间的 General 信息
编辑新建表空间的 General 信息

5. 在表空间属性视图中选择 Storage Options 页面,在 Group 下拉列表中选择分区组 PG1,如下图 22:

图 22. 指定表空间所在的分区组
指定表空间所在的分区组

6. 在表空间的属性视图中选择 Containers 页面,点击加号按钮添加三个表空间容器,并指定容器的大小,本例中每个容器设为 1000 页。 这三个表空间容器将会被分配到分区组的三个分区上。请参考下图 23:

图 23. 指定表空间的容器
指定表空间的容器

7. 在表空间的属性视图中选择 Partitioning 页面,您会看到一个包含两个列的表,第一列为 Container,第二列为 Partitions,其中 Container 列已经自动被填写了图 23 中的容器信息。 我们需要在 Partitions 列为每一个容器填写它所在的分区。我们依次为这三个容器指定分区为 0、1、2,请参考下图 24:

图 24. 指定表空间容器所在的分区
指定表空间容器所在的分区

8. 表空间的编辑完成,点击表空间的列表编辑器视图右上角绿色的 Review and Deploy Changes 按钮,在接下来弹出的部署预览对话框中会显示创建表空间的 DDL 如下:

清单 1. 在分区组上创建表空间
1
2
3
4
5
6
CREATE REGULAR TABLESPACE TBSPACE1 IN DATABASE PARTITION GROUP PG1
PAGESIZE 4096 MANAGED BY DATABASE USING ( FILE '/home/dpfins97/tscon0' 1000 )
ON DBPARTITIONNUM ( 0 ) USING ( FILE '/home/dpfins97/tscon1' 1000 )
ON DBPARTITIONNUM ( 1 ) USING ( FILE '/home/dpfins97/tscon2' 1000 )
ON DBPARTITIONNUM ( 2 ) BUFFERPOOL IBMDEFAULTBP OVERHEAD 7.5
TRANSFERRATE 0.06 DROPPED TABLE RECOVERY ON;

点击部署预览对话框上的 Run 按钮,表空间被成功创建。

实例 3 操作总结:

1. 如果用户没有为每个表空间容器指定分区组中的分区,也就是没执行本例第 7 步,就点击了 Review and Deploy Changes 按钮,那么一个警告对话框会弹出显示类似如下的信息:

Table Space container /home/dpfins97/tscon0 is not assigned to a database partition. Click the Partitioning tab to assign the container to a database partition.

最终执行也不能成功。

2. 在多分区 DB2 数据库的分区组上创建表空间时,用过 DB2 控制中心的用户可能都知道,DB2 控制中心在多个分区上创建表空间指定容器时, 也就是类似本实例的第六步,在控制中心中的向导中不能为每个分区指定自己的容器,而是用表达式如”/home/dpfins97/mycon $N”作为容器名称,然后控制中心会自动依次为每个分区指定容器指派容器命名为 mycon0,mycon1,mycon2。这样做不够灵活,用户不能为每个分区指定自己想要的表空间容器目录和表空间容器名称,Data Studio 在这方面做了改进。

实例四:Data Studio 的 Eclipse 参数页配置。

本实例讲解 Data Studio 对 Eclipse 的参数配置页的扩展。

Data Studio 基于 Eclipse,它对 Eclipse 的参数配置页做了某些扩展,比如,当用户在第一次启动 Data Studio 进行数据库管理操作时,假设用户想创建一个缓冲池,右键点击 Administrator Explorer 视图中的数据库节点下的 Buffer Pools 文件夹,选择 Create Buffer Pool,一个提示对话框会弹出提示用户“您正在对数据库对象进行更改操作,已经为您的操作在 Change plans 文件夹里创建了一个缺省的 Change Plan”,同时对话框上会有个 Checkbox 让用户选择是否以后还显示这个提示框。请参考下图 25:

图 25. 编辑数据库对象时的提示对话框
编辑数据库对象时的提示对话框

其实无论用户是否想在以后的操作中看到此提示框,都可以在 Data Studio 的 Eclipse 参数页里进行配置。点击主菜单中的 Window->Preferences,会弹出参数配置页,在参数配置页里选择 Data Management->Object List Options,您将看到一个 Checkbox 让您选择是否在编辑数据库对象时弹出“Change Plan 已经创建”的对话框。请参考下图 26:

图 26. 在参数页中选择是否在编辑数据库对象时弹出提示对话框
在参数页中选择是否在编辑数据库对象时弹出提示对话框

在使用 Data Studio 时,只要您看到弹出的提示框中包含有类似”Don ’ t show me again”的选择框,那么是否显示这个提示都可以在参数页进行配置。 再比如,很多时候在您的操作会产生冲突时,Data Studio 默认都会弹出一个冲突验证提示框,请参考下图 27 中创建 Schema 时指定的名称和已经存在的 Schema 同名时的场景:

图 27. 操作中产生命名冲突的验证提示框
操作中产生命名冲突的验证提示框

Data Studio 在参数页中扩展了一个名为 Model Validation 的选项页面,用户可以在其中设置 Include Live warning 选项来选择是否显示此类的提示框。请参考下图 28:

图 28. 在参数页中设置是否显示验证对话框
在参数页中设置是否显示验证对话框

当然,如果您选择不显示验证对话框,Data Studio 就会高亮度显示出现冲突的区域来对您进行提示,并把信息打印在 Console 视图里。 以上参数页中的配置并不影响实际的操作,下面举一个 典型的创建表外键的场景来向您展示参数页中的配置可以影响到实际操作的例子。

环境准备:

在 Data Studio 的 Administrator Explorer 视图中选择您的数据库,然后点击视图右上角的下拉箭头,选择 New Sql Script 打开 SQL 编辑器,在编辑器里运行下面的语句创建两个表。

清单 2. 创建主键和外键表
1
2
3
4
create table pktable
(id integer not null, name varchar(20), age integer, primary key(id));
create table fktable
(managerid integer, dept varchar(20));

其中 pktable 作为子表,fktable 作为父表。以下操作想为表 fktable 的列 managerid 创建一个外键,让它引用表 pktable 的主键列 id。此时大家可以看到,子表中所有的列都可以为空,而且没有主键。

操作步骤:

1. 在 Administrator Explorer 视图中右键点击您数据库下的 Constraints 文件夹,选择 Create Foreign Key,在弹出的对话框列表中选择表 fktable 作为子表。如下图 29:

图 29. 选择子表(外键表)
选择子表

在上图中点击 OK 按钮,会出现向导让您选择父表,从列表中选择 pktable 如下图 30:

图 30. 选择父表(主键表)
选择父表

2. 在上图中点击 OK 按钮,会显示外键的属性视图,在外键属性视图中选择 Details 页面,此时会看到在子表的外键列的列表中和父表的主键列的列表中,Data studio 已经自动地分别的添加了名为 ID 的列,此时大家可能会想:子表中并不包含 ID 列啊?下文中会给出解释。但是我们想让子表的 managerid 作为外键列,点击子表的 Key Columns 右边的按钮,在弹出的列表里取消 ID 列的选择,仅选择 managerid,请参考下图 31:

图 31. 在外键属性视图中选择外键列
在外键属性视图中选择外键列

3. 在上图中点击 OK 按钮,再点击外键列表编辑器视图右上方绿色的 Review and Deploy Changes 按钮,在弹出的预览部署对话框中出现错误提示说 :“ID 列设为非空,请为 ID 列指定值”,请参考下图 32:

图 32. 在运行创建外键的操作时出现验证错误
在运行创建外键的操作时出现验证错误

但是 DB2 本身是允许外键列为空,而且也允许外键列和主键列不同名。产生这个结果的原因是 Data Studio 为了模型验证,当子表里不包含和父表里的主键列同样的列时,Data Studio 缺省会自动为子表加上和父表的主键同样的列作为外键,并会验证外键是否非空。当然是否在创建外键时把父表的主键列迁移到子表是可以在参数页里设置的,点击 Data Studio 主菜单中的 Window->Preferences 打开参数页,选择 Data Management->Key Migration->On Add,取消 Migrate Key automatically 选择,如下图 33:

图 33. 在参数页取消创建外键时自动迁移外键列的选项
在参数页取消创建外键时自动迁移外键列的选项

4. 点击参数页上的 OK 按钮保存设置,取消以上步骤 1-3 的操作,重新执行步骤 1,然后在外键的属性视图中,在 General 页面选择选项 Non-Identifying,如下图 34:

图 34. 在外键属性视图中选择不验证外键
在外键属性视图中选择不验证外键

接下来再选择 Details 页面,此时用户就会发现这次和图 31 中显示的结果不同,子表的外键列表和父表的主键列表都是空的,这次点击子表的添加外键的按钮时,在弹出的列选择框里就不会在看到 ID 列了,选择 managerid 作为外键,请参考下图 35:

图 35. 在参数页取消外键列自动迁移选项后的外键属性视图
在参数页取消外键列自动迁移选项后的外键属性视图

然后在父表的 Unique Constraint or index 下拉框中手动选择主键。

5. 点击 Review and Deploy Changes 按钮,在弹出的预览部署对话框中不会在有错误出现,并且产生如下的 DDL:

清单 3. 创建可以为空并和主键不同名的外键
1
2
3
4
5
ALTER TABLE ADMINISTRATOR.FKTABLE ADD CONSTRAINT FKTABLE_PKTABLE_FK
FOREIGN KEY ( MANAGERID ) REFERENCES ADMINISTRATOR.PKTABLE ( ID )
ON DELETE CASCADE ON UPDATE NO ACTION;
CALL SYSPROC.ADMIN_CMD( 'REORG TABLE ADMINISTRATOR.FKTABLE' );
CALL SYSPROC.ADMIN_CMD( 'RUNSTATS ON TABLE ADMINISTRATOR.FKTABLE' );

点击预览部署对话框上的 Run 按钮,我们指定的外键成功创建。
在此,也想向大家解释一下参数页中的 Migrate Key automatically 选项和外键属性视图中 Gnenral 页面的 Identifying 选项, 当在参数页中的选项 Migrate Key automatically 处于勾选状态时,如果子表中不包含父表的主键列,那么 Data Studio 会在创建外键的时候自动为子表添加和父表的主键列同样的列,反之,不添加。

对于选项 Identifying,如果在创建外键时选择此选项,那么 Data Studio 会验证子表是否设置了和父表相同的主键作为外键列,如果没有,就会看到图 32 中显示的错误,如果此时在图 32 中点击 Next 按钮,在接下来产生的 DDL 中就会为子表添加和父表同样的主键。如果选择 Non-Identifying,则不验证外键列,也不会强制为子表设置主键,当然也就不会验证子表的主键列是否为空,那么我们也就不会在看到图 32 中的验证错误。在本例中,我们并不想做这样的验证,所以在参数页中对参数进行了修改。

实例 4 操作总结

大家都知道,当用工具进行数据库的管理和开发及调优操作时,提供一些和用户交互的对话框是必需的,同时也要考虑用户在操作中的一些自己的设置偏好。为了便于用户自己对这些设置进行定制,Data Studio 对 Eclipse 的参数页做了很多扩展,您能在参数页的 Data Management 选项下发现 Data Studio 管理数据库操作的绝大部分扩展项,其中当然也包含 DB2V10 中新的数据库对象的一些管理定制,比如 Temporal Tables,感兴趣的读者请自己体验一下吧! 至此,本文的讲解全部结束。

结束语

本文用几个典型的实例向您详细讲解了在使用 Data Studio 管理数据库操作中需要注意的地方,同时也尽可能地在讲解的过程中向您展示更多的 Data Studio 使用技巧。相信读者在看完本文后,对 Data Studio 会有更深的认识。无论如何,本文只是抛砖引玉,用户只有在自己的亲身体验中,才能感觉到 Data Studio 强大的数据库操作功能。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章