db2数据库 怎么修改一个字段的数据类型

运行db2cc，在控制中心中右击要修改的表，生成DDL，将该DDL中CREATE

TABLE命令包括表名进行相应修改后，运行该命令创建符合需要的新表。

然后insert

into

newtable

select

*

from

oldtable，如果可以兼容的话，否则你需要考虑怎么修改一下。

最后删除旧表，新表改名为旧表。

希望能帮到您。

在数据库设计的时候，VARCHAR和CHAR类型之间的使用，我和小唐发生了分歧。

我坚持要对表中的某些列，比如个性签名，使用CHAR型的来存储字符串信息。因为我认为使用CHAR一方面在数据库检索起来速度更快，同时在使用COBOL程序在逻辑上处理CHAR字符串生成的变量的时候，也相对简单，只要直接给变量赋值就可以了，这样子也便于程序的处理。而如果使用使用那个VARCHAR的话，数据检索效率相对低，而在COBOL中需要首先给字符串的长度赋值，然后在给它的内容赋值。这样子加大了程序的逻辑处理过程。还带来了一定的风险，比如赋值的时候，如果赋值的长度超过了最大的值，就会使得程序执行的时候出现意想不到的后果。

而他认为，他使用CHAR类型，很容易浪费存储空间，因为如果使用CHAR，无论存储的字符串内容的长度是多长，都会使用它固定长度去存储它。而使用VARCHAR则可以根据它实际的字符串长度去存储数据。这个是VARCHAR类型最大的特点，也是它到现在在数据库技术中还能存在的根本原因。

我开始对自己的想法变得有点怀疑。后来，我去网上找了找相关的资料，得知：

1,如果希望列中的数据值大小接近一致，请使用char；如果希望列中的数据值大小显著不同，请使用varchar。

2,事实上，因为char类型通常要比varchar类型占用更多的空间，所以从减少空间占用量和减少磁盘i/o的角度，使用varchar类型反而更有利

3，当数据的长度相差较大时，使用char会浪费很多的空间，而使用varchar可以节约大量的空间，对于数据量比较大的情况，更能体现出两者的差异。当数据长度比较固定（相差较小或固定不变）时，两者的差别就不太大。

4，在查询时，由于存储方式上的不同，导致char字段的查询速度要好于varchar字段，特别是对于在极大量的数据中查询。

综合上述因素，我采取了他的做法。后来才知道，其实，那些东西都已经是约定俗成了的。对于较长的字符串就是应该使用VARCHAR类型。看来自己还是有很多的东西值得去学习，而不是片面地从程序处理逻辑上来理解，判断。

今天把自己遇到的一个小问题跟大家分享一下如何修改db2数据库表中列的属性--将列的非空属性改为允许空的属性，修改数据表的某一列属性其实很简单但是里面有需要细节需要dba注意，毕竟数据的安全才是最重要的啊！

db2数据库支持直接使用ddl修改原表列属性，但是在修改之前需要确认要修改的列是否存在唯一性约束，否则你是无法修改属性的。

注：该 *** 作会导致表处于pending状态，在 *** 作之前需要确认该表是否24小时表，是否为大表（因为需要reorg重置表状态，数据量太大将导致业务中断时间变长），谨慎 *** 作~

以下是具体 *** 作步骤,敬请参考：

1、首先检查需要修改的列是否含有唯一性检查约束（注：主键不可设置为null）

1）使用db2系统表查询将要修改的表是否含有唯一约束

#db2 "select CONSTNAME, type from SYSCAT.TABCONST where TABNAME='T01'"

#主要看type，一般type的值有P（主键约束）、U（唯一性约束）、K（列值检查）、F（外键）

#如果返回的type值中有没有U类型的行则可以直接将原列设置为null然后reorg即可，反之需要继续第二步

2）使用db2look工具确认

#db2look -d dbname -e -t tabname

#查看将要修改的表的ddl语句，检查是否有unique子句，如果有这证明有唯一性约束列存在

2、如果有唯一性约束且恰好定义在需要修改的列上，我们需要先将该列的唯一性约束删除,如果没有则跳过该步

#db2 "alter table tabname drop unique CONSTNAME "

#回退步骤：db2 "alter table tabname add unique(colname)"

3、修改列的属性为null

db2 "alter table tabname ALTER colname drop not null"

#回退步骤：db2 "alter table t01 ALTER colname set not null"

4、对该表进行重组

因为修改列的属性后，该表处于reorg pending状态所以我们必须进行reorg才能使该表恢复到正常状态（这一步很重要）

db2 "reorg table tabname use tempsys"

db2 "runstats on table tabname with distribution and detailed indexes all"

5、验证

db2 load query table tabname

如果返回表状态为normal则此次 *** 作完成。

---