数据迁移中的数据库检查和建议(r2笔记71天)
关于数据迁移，在之前也讨论过一些需要注意的地方，可能林林总总列了不少，都是在数据迁移迁移前和迁移时需要注意的。 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 04）重启数据库，释放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)完整的日志和报告 在数据迁移，数据升级的时候，一定要保留完整的日志记录，这样如果稍候有问题，也可以及时查验，也可以避免很多不必要的纷争。如果有争议，可以找出日志来，一目了然。
提前准备好一些awr，ash之类的报告，作为一些备份和适当的参考材料
优质内容筛选与推荐>>1、MYSQL错误用法，有没踩过坑这些坑？
2、linux环境下mongodb启动操作
3、Http协议：彻底弄懂 Http 缓存机制 - 基于缓存策略三要素分解法
4、一键搭建本地yum源
5、python 3.6操作excel