数据迁移中的数据库检查和建议

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

关于数据迁移,在之前也讨论过一些需要注意的地方,可能林林总总列了不少,都是在数据迁移迁移前和迁移时需要注意的。
http://blog.itpub.net/23718752/viewspace-1195364/
http://blog.itpub.net/23718752/viewspace-1254945/
我在这些帖子的基础上进行更多的总结和补充。

数据库级的检查和建议
1)参数检查

有些参数是需要在数据迁移前临时做变更的,有些是性能相关的,需要考虑。
log_buffer在数据导入的过程中会有极高的消耗,如果并发数够多,对控制文件的scn更新也有一定的影响,根据测试情况抓取addm报告,得到一个比较适合的lob_buffer值

àDB parameters

SQL> show parameter log_buffer

NAME                                 TYPE        VALUE

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

log_buffer                           integer     31252480

关于pga的调整可以根据系统的情况适当加大,在数据迁移完成之后改回原值也可以。

SQL> show parameter pga

NAME                                 TYPE        VALUE

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

pga_aggregate_target                 big integer 6G

关于buffer_cache的调整可以根据系统的情况适当加大,一般最好能在sga的范围之内尽可能加大,在数据迁移完成之后改回原值也可以。

SQL> show parameter db_cache

NAME                                 TYPE        VALUE

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

db_cache_advice                      string      ON

db_cache_size                        big integer 11872M

关于异步io在11g是默认开启的,不过filesystem_options一般都建议开启

SQL> show parameter filesys

NAME                                 TYPE        VALUE

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

filesystemio_options                 string      SETALL

SQL> show parameter asy

NAME                                 TYPE        VALUE

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

disk_asynch_io                       boolean     TRUE

tape_asynch_io                       boolean     TRUE

2)表空间评估
表空间的情况,根据数据分布预估数据空间的情况,保留一定的额外空间。最好能富裕30%以上,毕竟数据迁移的过程中没空间了还是很要命的。
3)归档频率
归档的频率也是衡量系统负载的一个很直观的方法。
查看归档的在一个小时内切换多少次,可以查看最近两周左右的情况,这样在数据迁移的时候能够有一个很清晰的评估。
比如下面的库,切换频率还是比较低的,日志为1G大小,在半夜的时候因为备份,会有比较多的日志切换。

DBNAME    TIME_STAMP
--------- --------------------
CUST01    2014-Aug-19 23:46:03

    GROUP#    THREAD#  SEQUENCE#    MEMBERS    SIZE_MB ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
         1          1      23289          2       1024 YES INACTIVE
         2          1      23290          2       1024 YES INACTIVE
         3          1      23291          2       1024 YES INACTIVE
         4          1      23292          2       1024 NO  CURRENT

Redo Switch times per hour                                             xxxxxx                                                    2014-Aug-19 23:46:03
MON DA   00   01   02   03   04   05   06   07   08   09   10   11   12   13   14   15   16   17   18   19   20   21   22   23
--- -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
08  05    3   25    1    1    6    8    1    1    3    1    1    3    5    2    1    3    2    3    2    3    1    1    7    0
08  06    0    0    0    0    0    0    0    0    0    1    0    1    1    3    6    3    4    2    2    2    2    1   12    0
08  07    0    2    2    2   12   19    2    1    3    3    4    2    2    2    2    3    5   20   14    3   11    2    4    0
08  08    5    1   11   25    4    2    2    2    3    3    2    4   12    3    6   13    2    2    2    3    1    1    3    1
08  09    0    5    0    1    0    3    3    1   21    3    3    2    1    2    2    2    1    2    2    1    1    1    1    1
08  10    2    0    0   17    0    4    0    1    1    2    1    1    2    1    2    2    1    2    2    1    1    4    1    1
08  11    2    1   16    3    0    0    0    1    1    1    1    2    2    1    2    2    2    2    2    2    1    1    2    2
08  12    5    2   17    1    0    1    0    1    1    1    2    2    2    2    1    2    2    2    2    1    1    2    1    2
08  13    2    0    1   20    0    1    0    1    1    3    2    2    3    2    1    3    2    8    5    2    1    1    1    6
08  14    2    1    0   17    0    2    1    1    2    6    1    7    1    2    1    4    1    2    2    3    1    1    4    2
08  15    1    2    0    7    0    1    0    1    1    2    3    4    2    3    1    2    3    6    2    2    1    1    4    1
08  16    2    2    5    6   22    1    0    1    1    5    1    2    1    2    2    6   10    4    1    5    2    1    1    1
08  17    3    6    1    1    0    1    0    1    1    2    2    1    2    3    1   25   10    4    2    2    1    2    0    1
08  18    0    0    2   55    0    1    0    1    3    2    2    2    2    2    2    2    2    2    1    3    1    1    1    1
08  19    2   18    0    1    0    1    0    1    3    2    1    3    1    3    1   13    5    2    3    2    1    0    0    0

看一下数据迁移的时候的情况,在数据迁移的工程中,几乎跑到了极致,一个小时切换300多次。

GROUP#    THREAD#  SEQUENCE#    MEMBERS    SIZE_MB ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
         1          1      23813          2       1024 YES ACTIVE
         2          1      23814          2       1024 NO  CURRENT
         3          1      23811          2       1024 YES INACTIVE
         4          1      23812          2       1024 YES ACTIVE

Redo Switch times per hour                                              CUST01                                                    2014-Aug-20 02:08:17
MON DA   00   01   02   03   04   05   06   07   08   09   10   11   12   13   14   15   16   17   18   19   20   21   22   23
--- -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
08  05    0    0    1    1    6    8    1    1    3    1    1    3    5    2    1    3    2    3    2    3    1    1    7    0
08  06    0    0    0    0    0    0    0    0    0    1    0    1    1    3    6    3    4    2    2    2    2    1   12    0
08  07    0    2    2    2   12   19    2    1    3    3    4    2    2    2    2    3    5   20   14    3   11    2    4    0
08  08    5    1   11   25    4    2    2    2    3    3    2    4   12    3    6   13    2    2    2    3    1    1    3    1
08  09    0    5    0    1    0    3    3    1   21    3    3    2    1    2    2    2    1    2    2    1    1    1    1    1
08  10    2    0    0   17    0    4    0    1    1    2    1    1    2    1    2    2    1    2    2    1    1    4    1    1
08  11    2    1   16    3    0    0    0    1    1    1    1    2    2    1    2    2    2    2    2    2    1    1    2    2
08  12    5    2   17    1    0    1    0    1    1    1    2    2    2    2    1    2    2    2    2    1    1    2    1    2
08  13    2    0    1   20    0    1    0    1    1    3    2    2    3    2    1    3    2    8    5    2    1    1    1    6
08  14    2    1    0   17    0    2    1    1    2    6    1    7    1    2    1    4    1    2    2    3    1    1    4    2
08  15    1    2    0    7    0    1    0    1    1    2    3    4    2    3    1    2    3    6    2    2    1    1    4    1
08  16    2    2    5    6   22    1    0    1    1    5    1    2    1    2    2    6   10    4    1    5    2    1    1    1
08  17    3    6    1    1    0    1    0    1    1    2    2    1    2    3    1   25   10    4    2    2    1    2    0    1
08  18    0    0    2   55    0    1    0    1    3    2    2    2    2    2    2    2    2    2    1    3    1    1    1    1
08  19    2   18    0    1    0    1    0    1    3    2    1    3    1    3    1   13    5    2    3    2    1    1    0    0
08  20  303  212    6    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0

4)重启数据库,释放session,停掉listener
一般在数据迁移之前,最好能够停掉相关的服务,比较直接的方式就是重启数据库,可以很快的清除系统中的一些Inactive session和客户端链接的session
根据自己的情况来评估,如果库的高可用性比较高,可以手工清理session。

5)parallel的选择
这个部分我的感触很深,比如数据库服务器里有40个cpu,那么一般默认一个cpu对应两个并行,那么就能支持大概80多个,还需要考虑系统的负载。
对于比较大的表适用一些并行度较高的操作,如果表本来很小,可以不用开启,或者开启很低的并行,要不得不偿失,对于分区表,还是比较纠结的,因为自身使用并行有一些限制。而且如果做全表插入,会有和分区数相当的锁,开启的并行很可能不会适用。

6)undo的考虑
对于数据迁移来说,对于undo的空间使用来说是极大的挑战,可能在Impdp的时候出了Undo的问题,那就是极为奔溃的问题了。
还要考虑undo_retention的设置,可以在数据迁移之前可以把retention调低一些,保证undo的使用率足够用,然后在升级之后恢复设置。

6)归档空间
数据迁移的时候会有大量的日志产生,一定需要保证归档空间足够大,及时的转移归档文件。排除归档爆了以后数据的问题,使用sqlloader,impdp等数据迁移策略的时候,如果归档出了问题,是很头疼的问题。如果可以的话,可以申请临时加入一些文件空间,在数据迁移之后把空间大小恢复。

7)表级nologging
如果条件允许,可以考虑对一些相关的表开启nologging,在数据迁移之后再设置logging.
对速度有一些的提升,如果使用insert /+append /的时候,那速度就很明显了。

8)index级nologging
数据的insert操作,如果没有index速度很有成倍的提高,但是在生产中可能并不能建议这么做,如果重建索引的时候,也需要一定的时间,还需要一定保证索引和之前一定要没有任何的差错。所以一般来说,如果开启Index的nologging也会有一定的提升。

9)lob级nologging
对于lob数据类型来说,在允许的条件下,可以设置为nologging,速度会有所提升。

10)foreign key
外键的影响需要重视,如果外键存在对于数据的插入顺序无形中对会有一定的约束,所以在大批量的数据并发插入条件下,disable foreign key,可以更加高效,当然在enable foreign key的时候需要花费一些时间,做为数据检查。

11)trigger的影响
tigger在数据的dml操作中都有这潜移默化的影响,所以对于trigger最好和开发部分做确认,是否需要禁用trigger
要不很可能在数据迁移之后发现一些莫名其貌的数据多出来了。

12)materialized view log的影响
有些外部系统可能为了数据同步,可能会在系统中创建一些物化视图日志,可以和他们做一个确认,删除物化视图日志,减少数据插入的时候物化视图日志的影响,
还有一个问题就是物化视图日志会使rename table等操作无法进行。

13)godlengate的影响
goldengate的影响不容小视,需要和部分做一个确认在数据迁移之前停掉goldengate相关的进程。

14)数据统计信息的收集
数据迁移之后会有大量的数据变化,这个时候需要考虑收集统计信息,可以开启多个session做并行的收集。
以下是在做数据迁移的时候,分10个session并行收集统计信息的top信息,cpu的使用率已经达到了极致,收集工作不会持续太久,一般在一个小时的样子。不过可以同时做一些相关的检查了。

top - 02:21:54 up 28 days,  1:19, 21 users,  load average: 37.15, 22.01, 12.09
Tasks: 927 total,  27 running, 897 sleeping,   2 stopped,   1 zombie
Cpu(s): 62.6%us,  3.1%sy,  0.0%ni, 33.5%id,  0.0%wa,  0.2%hi,  0.6%si,  0.0%st
Mem:  371307496k total, 337238216k used, 34069280k free,  1259404k buffers
Swap: 377487328k total,     9440k used, 377477888k free, 266625964k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 4602 oraccbs1  19   0 18.3g 132m  28m R 93.9  0.0   1:53.45 ora_p027_CUST01
 4580 oraccbs1  19   0 18.3g 132m  28m R 91.6  0.0   2:05.36 ora_p026_CUST01
 4612 oraccbs1  16   0 18.3g 132m  28m S 88.3  0.0   2:38.77 ora_p032_CUST01
 4604 oraccbs1  16   0 18.3g 129m  25m R 87.6  0.0   1:59.36 ora_p028_CUST01
 4616 oraccbs1  16   0 18.3g 132m  29m R 84.4  0.0   2:03.56 ora_p033_CUST01
23619 oraccbs1  18   0 18.2g  28m  21m R 82.7  0.0   1:35.33 ora_p042_CUST01
 4606 oraccbs1  16   0 18.3g 132m  28m R 82.4  0.0   2:13.57 ora_p029_CUST01
25504 oraccbs1  18   0 18.2g  28m  23m R 81.4  0.0   1:00.60 ora_p046_CUST01
10342 oraccbs1  18   0 18.3g 129m  26m R 81.1  0.0   0:46.80 ora_p062_CUST01
23621 oraccbs1  18   0 18.2g  38m  32m R 80.4  0.0   1:38.34 ora_p043_CUST01
23600 oraccbs1  18   0 18.2g  31m  25m R 79.4  0.0   1:44.57 ora_p040_CUST01
31081 oraccbs1  17   0 18.2g  33m  20m D 78.7  0.0   2:43.19 ora_p003_CUST01
 4620 oraccbs1  25   0 18.3g 129m  24m R 78.4  0.0   2:33.77 ora_p035_CUST01
 4618 oraccbs1  17   0 18.3g 129m  24m D 78.1  0.0   2:31.58 ora_p034_CUST01
31079 oraccbs1  16   0 18.2g  36m  23m R 77.1  0.0   2:40.58 ora_p002_CUST01
 6167 oraccbs1  18   0 18.3g 132m  28m S 74.5  0.0   0:36.50 ora_p056_CUST01
25506 oraccbs1  18   0 18.2g  26m  20m R 72.2  0.0   0:59.59 ora_p047_CUST01
23602 oraccbs1  18   0 18.2g  28m  21m R 71.2  0.0   1:47.88 ora_p041_CUST01
23623 oraccbs1  18   0 18.2g  28m  21m R 71.2  0.0   0:43.13 ora_p044_CUST01
 6209 oraccbs1  18   0 18.3g 113m  19m D 69.5  0.0   0:38.34 ora_p057_CUST01
23625 oraccbs1  18   0 18.2g  32m  25m R 69.5  0.0   0:44.14 ora_p045_CUST01
10344 oraccbs1  18   0 18.3g 132m  28m S 67.9  0.0   0:46.73 ora_p063_CUST01
30746 oraccbs1  16   0 18.2g  23m  19m R 67.5  0.0   2:16.49 ora_p018_CUST01
25537 oraccbs1  16   0 18.2g  22m  18m R 64.6  0.0   0:49.59 ora_p048_CUST01
30748 oraccbs1  16   0 18.2g  24m  19m D 63.3  0.0   2:16.43 ora_p019_CUST01
25539 oraccbs1  16   0 18.2g  21m  18m D 62.9  0.0   0:49.08 ora_p049_CUST01
19872 oraccbs1  18   0 18.2g  26m  22m R 52.4  0.0   1:23.81 ora_p007_CUST01
19870 oraccbs1  18   0 18.2g  27m  23m R 52.1  0.0   1:43.02 ora_p006_CUST01
30760 oraccbs1  16   0 18.2g  24m  20m D 46.1  0.0   2:02.59 ora_p022_CUST01
25541 oraccbs1  16   0 18.2g  22m  17m R 44.5  0.0   0:53.93 ora_p050_CUST01
25543 oraccbs1  16   0 18.2g  21m  17m D 44.5  0.0   0:55.90 ora_p051_CUST01
30758 oraccbs1  16   0 18.2g  24m  19m R 41.8  0.0   2:07.19 ora_p021_CUST01
30756 oraccbs1  16   0 18.2g  24m  20m R 40.2  0.0   2:09.89 ora_p020_CUST01
30762 oraccbs1  16   0 18.2g  24m  20m R 39.9  0.0   1:52.12 ora_p023_CUST01
22568 oraccbs1  18   0 18.2g  20m  15m R 35.6  0.0   0:01.68 ora_p064_CUST01
 1492 oraccbs1  15   0 18.2g  23m  19m S 28.0  0.0   0:15.01 ora_p053_CUST01
22570 oraccbs1  18   0 18.2g  22m  17m D 27.0  0.0   0:01.51 ora_p065_CUST01

同时及时查看收集的进度,根据日志或者进程情况。

> ps -ef|grep sqlplus
oraccbs1   853 18167  0 02:26 pts/7    00:00:00 grep sqlplus
oraccbs1  1486 18167  0 02:19 pts/7    00:00:00 sqlplus
oraccbs1  6099 18167  0 02:20 pts/7    00:00:00 sqlplus
oraccbs1  9260 25974  0 02:14 pts/5    00:00:00 sqlplus
oraccbs1  9932 18167  0 02:20 pts/7    00:00:00 sqlplus
oraccbs1 15320 18167  0 02:18 pts/7    00:00:00 sqlplus
oraccbs1 19862 18167  0 02:15 pts/7    00:00:00 sqlplus
oraccbs1 23615 18167  0 02:18 pts/7    00:00:00 sqlplus
oraccbs1 25533 18167  0 02:19 pts/7    00:00:00 sqlplus
oraccbs1 30209 18167  0 02:19 pts/7    00:00:00 sqlplus
oraccbs1 30498 18167  0 02:16 pts/7    00:00:00 sqlplus

14)申请较大的mount point

数据迁移的时候往往需要临时的挂载点存放dump文件,这个需要提前申请和准备。
像下面的情况,一定得提前检查保证有足够的权限。

àShared mount point permission:

> touch testfile

touch: cannot touch `testfile': Permission denied

15)查看数据的负载情况
提前查看数据库的运行情况,是否已经有过高的负载,及时进行排查。
以下是数据迁移的时候数据库负载情况。在数据迁移之后就马上恢复了正常。

BEGIN_TIME------------------------- END_TIME--------------------------- ELAPSED_TIME- BTIME----- WORKLOAD_PER--------
----------------------------------- ----------------------------------- ------------- ---------- --------------------

14134 20-AUG-14 12.00.05.845 AM 14135 20-AUG-14 01.00.10.524 AM 60.078 1170.81 1948%

14135 20-AUG-14 01.00.10.524 AM 14136 20-AUG-14 02.00.12.741 AM 60.037 612.2 1019%

14136 20-AUG-14 02.00.12.741 AM 14137 20-AUG-14 03.00.14.846 AM 60.035 745.48 1241%

14137 20-AUG-14 03.00.14.846 AM 14138 20-AUG-14 04.00.16.889 AM 60.034 72.05 120%

14138 20-AUG-14 04.00.16.889 AM 14139 20-AUG-14 05.00.19.070 AM 60.036 50.53 84%

14139 20-AUG-14 05.00.19.070 AM 14140 20-AUG-14 06.00.21.069 AM 60.033 28.27 47%


15)完整的日志和报告
在数据迁移,数据升级的时候,一定要保留完整的日志记录,这样如果稍候有问题,也可以及时查验,也可以避免很多不必要的纷争。如果有争议,可以找出日志来,一目了然。
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
2月前
|
SQL 关系型数据库 MySQL
如何快速在表级别做同构或者异构数据库之间的数据迁移/备份
【8月更文挑战第17天】本文介绍在同构与异构数据库间快速迁移/备份表级数据的方法。同构迁移可利用数据库自带工具(如MySQL的`mysqldump`)或管理软件(如phpMyAdmin);异构迁移则推荐使用ETL工具(如Pentaho Data Integration)或数据库复制工具(如SymmetricDS),亦可通过编程方式实现。实施前需测试以确保数据完整准确,并注意处理兼容性问题。
|
29天前
|
SQL 监控 关系型数据库
MySQL数据库中如何检查一条SQL语句是否被回滚
检查MySQL中的SQL语句是否被回滚需要综合使用日志分析、事务状态监控和事务控制语句。理解和应用这些工具和命令,可以有效地管理和验证数据库事务的执行情况,确保数据的一致性和系统的稳定性。此外,熟悉事务的ACID属性和正确设置事务隔离级别对于预防数据问题和解决事务冲突同样重要。
38 2
|
3月前
|
开发框架 Oracle 关系型数据库
ABP框架使用Oracle数据库,并实现从SQLServer中进行数据迁移的处理
ABP框架使用Oracle数据库,并实现从SQLServer中进行数据迁移的处理
|
3月前
|
存储 Oracle 关系型数据库
|
3月前
|
关系型数据库 MySQL 测试技术
数据库升级是一个涉及数据备份、新版本安装、数据迁移和测试等关键环节的复杂过程
【7月更文挑战第21天】数据库升级是一个涉及数据备份、新版本安装、数据迁移和测试等关键环节的复杂过程
60 1
|
5月前
|
Cloud Native 关系型数据库 分布式数据库
【PolarDB开源】PolarDB数据迁移实战:平滑过渡至云原生数据库
【5月更文挑战第24天】本文介绍了如何平滑迁移数据至阿里云的云原生数据库PolarDB,包括迁移准备、策略选择、步骤、验证及示例代码。通过需求分析、环境准备和数据评估,选择全量、增量或在线迁移策略。使用数据导出、导入及同步工具(如DTS)完成迁移,并在完成后验证数据一致性、性能和安全。正确执行可确保业务连续性和数据完整性。
194 1
|
4月前
|
SQL 关系型数据库 MySQL
MySQL数据库——视图-检查选项(cascaded、local)
MySQL数据库——视图-检查选项(cascaded、local)
88 0
|
4月前
|
关系型数据库 MySQL 5G
Mysql数据迁移3个快速方法与数据库恢复
Mysql数据迁移3个快速方法与数据库恢复
756 0
|
4月前
|
SQL 关系型数据库 数据库
sql检查数据库
在SQL中,要检查数据库的存在、状态或相关信息,你通常需要使用特定于数据库管理系统的系统视图或命令。不同的数据库管理系统(如MySQL、SQL Server、PostgreSQL等)有不同的方法来执行
|
5月前
|
SQL 关系型数据库 数据库
OceanBase数据库常见问题之OAT添加服务器预检查的时候报错如何解决
OceanBase 是一款由阿里巴巴集团研发的企业级分布式关系型数据库,它具有高可用、高性能、可水平扩展等特点。以下是OceanBase 数据库使用过程中可能遇到的一些常见问题及其解答的汇总,以帮助用户更好地理解和使用这款数据库产品。