我的Oracle学习旅程---杂项---碎片整理

于 2008-09-01 23:02:38 发布
阅读量122 收藏
点赞数
文章标签： 数据库 大数据

方法一：传统的清除行迁移的方法

具体步骤如下：

1． 执行$ORACLE_HOME/rdbms/admin目录下的utlchain.sql脚本创建chained_rows表。

@$ORACLE_HOME/rdbms/admin/utlchain.sql

2． 将存在有行迁移的表（用table_name代替）中的产生行迁移的行的rowid放入到chained_rows表中。

ANALYZE TABLE table_name LIST CHAINED ROWS INTO chained_rows;

3． 将表中的行迁移的row id放入临时表中保存。

CREATE TABLE table_name_temp AS

SELECT * FROM table_name

WHERE rowid IN

(SELECT head_rowid FROM chained_rows

WHERE table_name = 'table_name');

4． 删除原来表中存在的行迁移的记录行。

DELETE table_name

WHERE rowid IN

(SELECT head_rowid

FROM chained_rows

WHERE table_name = 'table_name');

5． 从临时表中取出并重新插入那些被删除了的数据到原来的表中，并删除临时表。

INSERT INTO table_name SELECT * FROM table_name_temp;

DROP TABLE table_name_temp;

对于这种传统的清除RM的方法，优点是执行起来过程比较简单，容易实现。但是这种算法的缺陷是没有考虑到表关联的情况，在大多数数据库中很多表都是和别的表之间有表关联的，有外键的限制，这样就造成在步骤3中根本无法delete掉存在有行迁移的记录行，所以这种方法能够适用的表的范围是有限的，只能适用于表上无任何外键关联的表。由于这种方法在插入和删除数据的时候都没有disable掉索引，这样导致主要消耗时间是在删除和插入时维持索引树的均衡上了，这个对于如果记录数不多的情况时间上还比较短，但是如果对于记录数很多的表这个所消耗的时间就不是能够接受的了。显然，这种方法在处理大数据量的表的时候显然是不可取的。

以下是一个具体在生产数据库上清除行迁移的例子，在这之前已经调整过表的pctfree参数至一个合适的值了：

SQL>@$ORACLE_HOME/rdbms/admin/utlchain.sql

Table created.

SQL> ANALYZE TABLE CUSTOMER LIST CHAINED ROWS INTO chained_rows;

Table analyzed.

SQL>SELECT count(*) from chained_rows；

TABLE_NAME COUNT(*)

------------------------------ ----------

CUSTOMER 21306

1 rows selected.

查看在CUSTOMER表上存在的限制:

SQL>select CONSTRAINT_NAME,CONSTRAINT_TYPE,TABLE_NAME from USER_CONSTRAINTS where TABLE_NAME='CUSTOMER';

CONSTRAINT_NAME C TABLE_NAME

------------------------------ - ------------------------------

PK_CUSTOMER1 P CUSTOMER

SQL>select CONSTRAINT_NAME,CONSTRAINT_TYPE,TABLE_NAME from USER_CONSTRAINTS where R_CONSTRAINT_NAME='PK_CUSTOMER1';

no rows selected

SQL> CREATE TABLE CUSTOMER_temp AS

SELECT * FROM CUSTOMER WHERE rowid IN

(SELECT head_rowid FROM chained_rows

WHERE table_name = 'CUSTOMER');

Table created.

SQL>select count(*) from CUSTOMER;

COUNT(*)

----------

338299

SQL> DELETE CUSTOMER WHERE rowid IN

(SELECT head_rowid

FROM chained_rows

WHERE table_name = 'CUSTOMER');

21306 rows deleted.

SQL> INSERT INTO CUSTOMER SELECT * FROM CUSTOMER_temp;

21306 rows created.

SQL> DROP TABLE CUSTOMER_temp;

Table dropped.

SQL> commit;

Commit complete.

SQL> select count(*) from CUSTOMER;

COUNT(*)

----------

338299

SQL> truncate table chained_rows;

Table truncated.

SQL> ANALYZE TABLE CUSTOMER LIST CHAINED ROWS INTO chained_rows;

Table analyzed.

SQL> select count(*) from chained_rows;

COUNT(*)

----------

0

以上整个清除两万多行的行迁移过程在三分钟左右，而且全部都在联机的状态下完成，基本上不会对业务有什么影响，唯一就是在要清除行迁移的表上不能有对外键的限制，否则就不能采用这个方法去清除了。

方法二：改进了的传统清除行迁移的方法

1． 执行$ORACLE_HOME/rdbms/admin目录下的utlchain.sql脚本创建chained_rows表。

2． 禁用所有其它表上关联到此表上的所有限制。

3． 将表中的行迁移的row id放入临时表中保存。

4． 删除原来表中存在的行迁移的记录行。

5． 从临时表中取出并重新插入那些被删除了的数据到原来的表中，并删除临时表。

6． 启用所有其它表上关联到此表上的所有限制。

这种算法是对传统算法的一种改进，对于使用这种算法来清除行迁移，考虑到了表之间的关联，还可以灵活的利用的TOAD工具生成的表关联信息，是一种比较适合于清除行迁移的一种方法。但是因为使用这种方法后来需要重建索引，如果记录数很大，比如说上千万条以上的记录的表，就不是很合适了，因为这个重建索引的时间会很长，是线性时间复杂度的，而重建索引是会导致索引所在的表被锁定的，从而导致插入不了新的记录，重建索引的时间太长导致记录长时间插入不了是会严重影响应用的，甚至导致数据的丢失，因此这个是使用这个方法前必须要考虑到的一个重要因素；对于8i以上的版本可以使用online的方法来重建索引，这样不会导致锁表，但是会有额外更多的开销，时间会很长。再者，因为这种方法在插入记录和删除记录都是带着索引的，如果表上的行迁移比较多，这样耗时间会比较长，而且占用资源也会比较大，因此只适用于表上行迁移存在的比较少的表。总的来说，这种方法对于表记录太多或者是表上的行迁移太多的情况都不是很适用，比较适合表记录少和表上行迁移都不太多的情况。

以下是一个具体在生产数据库上清除行迁移的例子，在这之前已经调整过表的pctfree参数至一个合适的值了：

SQL>select index_name,index_type,table_name from user_indexes where table_name='TERMINAL';

INDEX_NAME INDEX_TYPE TABLE_NAME

-----------------------------------------------------------------

INDEX_TERMINAL_TERMINALCODE NORMAL TERMINAL

I_TERMINAL_ID_TYPE NORMAL TERMINAL

I_TERMINAL_OT_OID NORMAL TERMINAL

PK_TERMINAL_ID NORMAL TERMINAL

UI_TERMINAL_GOODIS_SSN NORMAL TERMINAL

SQL>select CONSTRAINT_NAME,CONSTRAINT_TYPE,TABLE_NAME from USER_CONSTRAINTS where R_CONSTRAINT_NAME='PK_TERMINAL_ID';

CONSTRAINT_NAME C TABLE_NAME

------------------------------ - ------------------------------

SYS_C003200 R CONN

SQL>alter table CONN disable constraint SYS_C003200;

Table altered.

SQL>CREATE TABLE TERMINAL_temp AS

SELECT * FROM TERMINAL

WHERE rowid IN

(SELECT head_rowid FROM chained_rows

WHERE table_name = 'TERMINAL');

Table created.

SQL>select count(*) from TERMINAL_temp;

COUNT(*)

----------

8302

SQL>DELETE TERMINAL

WHERE rowid IN

(SELECT head_rowid

FROM chained_rows

WHERE table_name = 'TERMINAL');

8302 rows deleted.

SQL>INSERT INTO TERMINAL SELECT * FROM TERMINAL_temp;

8302 rows created.

SQL>alter table CONN disable constraint SYS_C003200;

Table altered.

SQL>select count(*) from terminal;

COUNT(*)

----------

647799

SQL>truncate table chained_rows;

Table truncated.

SQL>ANALYZE TABLE TERMINAL LIST CHAINED ROWS INTO chained_rows;

Table analyzed.

SQL>select count(*) from chained_rows;

COUNT(*)

----------

0

从上面过程中可以看出，对TERMINAL这张表的行迁移清除耗时总共不到五分钟的时间，总体来说还是比较快的。从我在生产数据库中清除行迁移的经验来说，这种方法基本适用于大部分存在有行迁移的表。

方法三：使用TOAD工具清除行迁移的方法

1． 备份要清除RM的表。

RENAME table_name TO table_name_temp;

2． Drop 所有其它表上关联到table_name的外键限制。

SELECT CONSTRAINT_NAME,CONSTRAINT_TYPE,TABLE_NAME from USER_CONSTRAINTS where R_CONSTRAINT_NAME in (SELECT CONSTRAINT_NAME from USER_CONSTRAINTS where TABLE_NAME='table_name' AND CONSTRAINT_TYPE=’P’);

ALTER TABLE table_name DROP CONSTRAINT XXXX;（XXXX为上述的查询结果）

3． 重建1中被rename的表。

CREATE TABLE table_name AS SELECT * FROM table_name_temp WHERE 0 = 1;

4． 重建表中原来的数据。

INSERT /*+ APPEND */ INTO table_name SELECT * FROM table_name_temp;

5． 删除在table_name_temp上的索引和关联其他表的外键。

6． 在table_name上建立和原来一样的索引、主键和所有的外键限制。

7． 重新编译相关的存储过程、函数和包。

8． 删除表table_name_temp。

对于使用这种方法来清除行迁移，全部的代码都是可以由TOAD工具来生成的。由于此方法把表上的关联考虑进去了，也是一种比较的全面的考虑的一种清除方法，而且在清除过程中重建了表和索引，对于数据库的存储和性能上都有提高。因为这种方法一开始是rename表为临时表，然后重建一个新表出来的，因此需要两倍的表的空间，因此在操作之前一定要检查要清除的表所在的表空间的free空间是否足够；但是也有一定的缺陷，因为在新表中重新插入原来的数据后需要重建索引和限制，因此在时间和磁盘的空间上都有比较大的开销，而且对于前台的应用可能会有一段时间的中断，当然，这个中断时间就主要是消耗在重建索引和重建限制上了，而时间的长短跟需要重建索引和限制的多少以及表的记录多少等等因素都有关系。使用这种方法对于7*24小时要求的系统上清除行迁移不是很合适，因为使用这种方法会导致系统可能有一段时间的停机，如果系统的实时性比较高，这种方法就不是很适用了。

方法四：使用EXP/IMP工具清除行迁移的方法

1． 使用EXP导出存在有行迁移的表。

2． 然后TRUNCATE原来的表。

3． IMP开始导出的表。

4． 重建表上所有的索引。（可选）

使用这种方法可以不用重建索引，省去了这部分时间，但是完成之后索引的使用效率不会很高，最好是在以后逐步的在线重建索引，这样是可以不需要中断业务的。但是需要考虑的是IMP的时候会比较慢，而且会占用比较大的IO，应该选择在应用不是很繁忙的时候做这项工作，否则会对应用的正常运行产生较大的影响。对于这种方法还存在有一个比较大的弊端，就是在EXP表的时候要保证该表是没有数据的更新或者是只读状态的，不能对表有插入或者更新操作，否则会导致数据的丢失。

SQL> select count(*) from test;

COUNT(*)

----------

169344

SQL> truncate table chained_rows;

Table truncated.

SQL> analyze table test LIST CHAINED ROWS INTO chained_rows;

Table analyzed.

SQL> select count(*) from chained_rows;

COUNT(*)

----------

3294

$ exp allan/allan file=test.dmp tables=test

Export: Release 9.2.0.3.0 - Production on Sun Jun 6 13:50:08 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to: Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.3.0 - Production

Export done in ZHS16GBK character set and AL16UTF16 NCHAR character set

About to export specified tables via Conventional Path ...

. . exporting table TEST 169344 rows exported

Export terminated successfully without warnings.

$ sqlplus allan/allan

SQL*Plus: Release 9.2.0.3.0 - Production on Sun Jun 6 13:50:43 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved

Connected to:

Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.3.0 - Production

SQL> truncate table test;

Table truncated.

SQL> exit

Disconnected from Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.3.0 - Production

$ imp allan/allan file=test.dmp full=y ignore=y buffer=5000000

Import: Release 9.2.0.3.0 - Production on Sun Jun 6 13:51:24 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to: Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.3.0 - Production

Export file created by EXPORT:V09.02.00 via conventional path

import done in ZHS16GBK character set and AL16UTF16 NCHAR character set

. importing ALLAN's objects into ALLAN

. . importing table "TEST" 169344 rows imported

Import terminated successfully without warnings.

$ sqlplus allan/allan

SQL*Plus: Release 9.2.0.3.0 - Production on Sun Jun 6 13:52:53 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:

Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.3.0 - Production

SQL> select count(*) from test;

COUNT(*)

----------

169344

SQL> select index_name from user_indexes where table_name='TEST';

INDEX_NAME

------------------------------

OBJ_INDEX

SQL> alter index OBJ_INDEX rebuild online;

Index altered.

SQL> truncate table chained_rows;

Table truncated.

SQL> analyze table test LIST CHAINED ROWS INTO chained_rows;

Table analyzed.

SQL> select count(*) from chained_rows;

COUNT(*)

----------

0

方法五：使用MOVE命令来清除行迁移的方法

1． 查看要清除行迁移的表所在的表空间。

Select table_name,tablespace_name from user_tables where table_name='table_name’;

2． 查看要清除行迁移的表上的具体索引。

select index_name,table_name from user_indexes where table_name＝‘table_name’;

3． Move要清除RM的表到指定的表空间中去。

alter table table_name move tablespace tablespace_name;

4． 重建表上的所有索引。

alter index index_name rebuild;

这种方法适用于8i及其以上的数据库版本，主要是利用数据库的一个MOVE命令来实现行迁移的清除的，MOVE命令的实质其实就是INSERT … SELECT的一个过程，在MOVE表的过程中是需要两倍的原来的表大小的，因为中间过程是要保留原来的旧表的，新表创建完成后旧表就被删除并释放空间了。MOVE的时候要注意后面一定要加上表空间参数，所以必须要先知道表所在的表空间；因为MOVE表之后需要重建索引，所以之前要确定表上的所有的索引。

这种方法对于表记录数很大或者表上索引太多的情况不太适用，因为本身的MOVE就会很慢， 而且MOVE表的时候会要锁定表，时间长了会导致对表的其他操作出现问题，导致数据插入不了丢失数据；MOVE表后还要重建索引，索引太多了的话重建的时间也会太长；再者，这个方法也比较消耗资源，因此强烈建议在业务不繁忙的时候再执行。

以下是一个具体在生产数据库上清除行迁移的例子，在这之前已经调整过表的pctfree参数至一个合适的值了：

SQL>ANALYZE TABLE SERVICE LIST CHAINED ROWS INTO chained_rows;

Table analyzed.

SQL>SELECT count(*) from chained_rows;

COUNT(*)

----------

9145

SQL>select table_name,tablespace_name from user_tables where table_name='SERVICE';

TABLE_NAME TABLESPACE_NAME

------------------------------ ------------------------------

SERVICE DATA

SQL>select index_name,table_name from user_indexes where table_name='SERVICE';

INDEX_NAME TABLE_NAME

------------------------------ ------------------------------

I_SERVICE_ACCOUNTNUM SERVICE

I_SERVICE_DATEACTIVATED SERVICE

I_SERVICE_SC_S SERVICE

I_SERVICE_SERVICECODE SERVICE

PK_SERVICE_SID SERVICE

SQL>select count(*) from SERVICE;

COUNT(*)

----------

518718

SQL>alter table SERVICE move tablespace DATA;

Table altered.

SQL>alter index I_SERVICE_ACCOUNTNUM rebuild;

Index altered.

SQL>alter index I_SERVICE_DATEACTIVATED rebuild;

Index altered.

SQL>alter index I_SERVICE_SC_S rebuild;

Index altered.

SQL>alter index I_SERVICE_SERVICECODE rebuild;

Index altered.

SQL>alter index PK_SERVICE_SID rebuild;

Index altered.

SQL>truncate table chained_rows;

Table truncated.

SQL>ANALYZE TABLE SERVICE LIST CHAINED ROWS INTO chained_rows;

Table analyzed.

SQL>SELECT count(*) from chained_rows;

COUNT(*)

----------

0

利用MOVE命令来清除行迁移，执行的命令都相对比较的简单，上面的例子中清除表SERVCIE中的行迁移的时间大概在五分钟左右，其中move命令执行的时间为不到两分钟，也就是锁表的时间大概是不到两分钟，对于大多数的应用来说一般问题都是不大的，放在系统闲的时候执行基本上不会对应用产生什么太多的影响。

方法六：对于一些行迁移数量巨大而且表记录数巨大的表的行迁移的清除方法

1． 使用TOAD工具或者别的方法获取存在有大量行迁移并且表记录很大的表的重建表的SQL，然后保存为脚本。

2． 使用RENAME命令将原始表重命名为一个备份表，然后删除别的表对原始表上的限制、以及原始表上的外键和索引。
3． 利用1中生成的脚本重建原始表，以及表上的限制，外键，索引等对象。

4． 然后按表模式导出2中备份的表，然后导入到另外的一个临时中转的数据库库中，因为表的名字已经改变，所以导入后需要RENAME表为原来的名字，然后重新导出，最后再导入到原来的数据库中。

这种方法主要是用来针对一些数据量比较大，并且表上的行迁移也比较多的表的行迁移清除。对于这些大表的行迁移的清除，正常来说都需要停应用一段较长时间才能够清除掉，让人感觉比较的头疼，对于7*24小时的应用来说，down机的时间越长损失则越大，当然是要尽量的减短down机的时间。但是因为表本身比较大，不管怎样做什么操作都是会比较耗费时间和资源的，但是如果应用在某段时间内主要是以插入数据为主，更新数据和删除数据都很少的，因此可以考虑可以采用这么一种方法：先重命名表，然后重新建立一个和原来一样的表，用来保证之后的应用的数据是可以正常插入的，从而使应用不用停很久，因为重建一个没有任何数据的表结构的过程是很短暂的，大概需要几秒钟的时间，而重建好表了后就能保证应用能够正常的写入数据，从而使应用几乎不用停顿，然后把开始重命名的原始表按表模式导出，因为表的名字已经被改变，因此需要一个临时库来导入这些数据，然后重命名回原来的名字，然后按原来的表名导出后再重新导入原始数据库，这样操作起来虽然会比较麻烦，但是却是一种很有效很实际的方法，速度也很快，导出后导入，因为本身表结构已经建立好了，不需要其他任何的多的操作，而且最关键的是这种方法所需要的down机时间是最短的。

SQL>ALTER TABLE USER.PAY RENAME TO PAY_X ;

然后导出PAY_X表;

$ exp USER/USER file=PAY_X.dmp tables=PAY_X

SQL>ALTER TABLE USER.BATCHPAYMENTDETAIL DROP CONSTRAINT FK_BATCHPAYMENTDETAIL_OPAYID ;

SQL>ALTER TABLE USER.DEPOSITCLASSIFY DROP CONSTRAINT FK_DEPOSITCLASSIFY2 ;

SQL>ALTER TABLE USER.DEPOSITCREDITLOG DROP CONSTRAINT FK_DEPOSITCREDITLOG2 ;

SQL>ALTER TABLE USER.DEPOSIT DROP CONSTRAINT SYS_C003423 ;

SQL>ALTER TABLE USER.PAY_X DROP CONSTRAINT SYS_C003549 ;

SQL>DROP INDEX USER.I_PAY_STAFFID ;

SQL>CREATE TABLE USER.PAY

(

PAYID NUMBER(9),

ACCOUNTNUM NUMBER(9),

TOTAL NUMBER(12,2),

PREVPAY NUMBER(12,2),

PAY NUMBER(12,2),

STAFFID NUMBER(9),

PROCESSDATE DATE,

PAYNO CHAR(12),

TYPE CHAR(2) DEFAULT '0',

PAYMENTMETHOD CHAR(1) DEFAULT '0',

PAYMENTMETHODID VARCHAR2(20),

BANKACCOUNT VARCHAR2(32),

PAYMENTID NUMBER(9),

STATUS CHAR(1) DEFAULT '0',

MEMO VARCHAR2(255),

SERVICEID NUMBER(9),

CURRENTDEPOSITID NUMBER(9),

SHOULDPROCESSDATE DATE DEFAULT sysdate,

ORIGINALEXPIREDATE DATE,

ORIGINALCANCELDATE DATE,

EXPIREDATE DATE,

CANCELDATE DATE,

DEPOSITTYPE CHAR(1)

)

TABLESPACE USER

PCTUSED 95

PCTFREE 5

INITRANS 1

MAXTRANS 255

STORAGE (

INITIAL 7312K

NEXT 80K

MINEXTENTS 1

MAXEXTENTS 2147483645

PCTINCREASE 0

FREELISTS 1

FREELIST GROUPS 1

BUFFER_POOL DEFAULT

)

NOLOGGING

NOCACHE

NOPARALLEL;

SQL>CREATE INDEX USER.I_PAY_STAFFID ON USER.PAY

(STAFFID)

NOLOGGING

TABLESPACE USER

PCTFREE 5

INITRANS 2

MAXTRANS 255

STORAGE (

INITIAL 1936K

NEXT 80K

MINEXTENTS 1

MAXEXTENTS 2147483645

PCTINCREASE 0

FREELISTS 1

FREELIST GROUPS 1

BUFFER_POOL DEFAULT

)

NOPARALLEL;

SQL>CREATE UNIQUE INDEX USER.PK_PAY_ID ON USER.PAY

(PAYID)

NOLOGGING

TABLESPACE USER

PCTFREE 5

INITRANS 2

MAXTRANS 255

STORAGE (

INITIAL 1120K

NEXT 80K

MINEXTENTS 1

MAXEXTENTS 2147483645

PCTINCREASE 0

FREELISTS 1

FREELIST GROUPS 1

BUFFER_POOL DEFAULT

)

NOPARALLEL;

SQL>ALTER TABLE USER.PAY ADD (

FOREIGN KEY (STAFFID)

REFERENCES USER.STAFF (STAFFID));

SQL>ALTER TABLE USER.DEPOSITCLASSIFY ADD

CONSTRAINT FK_DEPOSITCLASSIFY2

FOREIGN KEY (PAYID)

REFERENCES USER.PAY (PAYID) ;

SQL>ALTER TABLE USER.DEPOSITCREDITLOG ADD

CONSTRAINT FK_DEPOSITCREDITLOG2

FOREIGN KEY (PAYID)

REFERENCES USER.PAY (PAYID) ;

SQL>ALTER FUNCTION "USER"."GENERATEPAYNO" COMPILE ;

SQL>ALTER PROCEDURE "USER"."ENGENDERPRVPAY" COMPILE ;

SQL>ALTER PROCEDURE "USER"."ISAP_ENGENDERPRVPAY" COMPILE ;

SQL>ALTER PROCEDURE "USER"."SPADDCREDITDEPOSIT" COMPILE ;

SQL>ALTER PROCEDURE "USER"."SPADDDEPOSITWITHOUTCARD" COMPILE ;

SQL>ALTER PROCEDURE "USER"."SPADJUSTLWDEPOSIT" COMPILE ;

……

然后将导出的表PAY_X的dmp文件导入一个临时的数据库中，然后在临时数据库中将其表名重新命名为PAY，再按表模式将其导出。

imp USER/USER file= PAY_x.dmp tables=PAY ignore=y

SQL>rename PAY_X to PAY;

$ exp USER/USER file=PAY.dmp tables=PAY

最后将这个dmp文件导入正式的生产数据库中即可。

以上的过程在重建好PAY表后整个应用就恢复正常了，而重命名表后重建表的时间是非常之短的，我测试的时间大概是在几分钟之内就可以做完了，新数据就可以插入表了，剩下的工作就是将旧的数据导入数据库，这个工作的时间要求上就没有那么高了，因为应用已经正常了，一般来说利用晚上业务不忙的时候都可以把一张表的数据导入完成的。

以上的六种清除行迁移的方法各有各自的优缺点，分别适用于不同的情况下使用，利用以上的几种清除行迁移的方法基本上就能完全清除掉系统中的存在的行迁移了，当然，具体的生产环境中还需要具体问题具体分析的，针对不同类型的系统，系统中不同特点的表采用不同的清除方法，尽量的减少停数据库的时间，以保证应用的不间断稳定运行。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16573/viewspace-440351/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16573/viewspace-440351/

cjd851205
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值