数据迁移中的数据库检查和建议(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    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)完整的日志和报告
在数据迁移,数据升级的时候,一定要保留完整的日志记录,这样如果稍候有问题,也可以及时查验,也可以避免很多不必要的纷争。如果有争议,可以找出日志来,一目了然。

提前准备好一些awr,ash之类的报告,作为一些备份和适当的参考材料

TinyMind推荐课程:CNN卷积神经网络(Python深度学习实战系列)

腾英科技董事长周北老师亲授,学习地址:点此进入学习


长按二维码向我转账

受苹果公司新规定影响,微信 iOS 版的赞赏功能被关闭,可通过二维码转账支持公众号。

    阅读
    好看
    已推荐到看一看
    你的朋友可以在“发现”-“看一看”看到你认为好看的文章。
    已取消,“好看”想法已同步删除
    已推荐到看一看 和朋友分享想法
    最多200字,当前共 发送

    已发送

    朋友将在看一看看到

    确定
    分享你的想法...
    取消

    分享想法到看一看

    确定
    最多200字,当前共

    发送中

    网络异常,请稍后重试

    微信扫一扫
    关注该公众号