梦想有多远

弦乐之花@DSI(281613430) 10:35:57
原环境：1、数据库10g+rac+asm
            2、数据库软件安装于本地磁盘上，数据文件位于阵列上
要求：将原阵列上所有文件转移到新的阵列上
方案一：由于数据量不大

                    用IMPDP+DELINK

方案二：利用ASM的特性

blue_prince:

停机时间充裕还不好弄。其实呢，我给你一个停机时间最短的方案。
第一步，停止RAC数据库及各个节点的CRS。然后更改VOTING DISK的路径。
添加一个Voting disk成员：crsctl add css votedisk ‘/dev/raw/raw3’
删除一个Voting disk成员：crsctl delete css votedisk ‘/dev/raw/raw3’
第二步，用ocrconfig添加新的OCR，删除掉的OCR。这样CRS和数据库都可以启动了。
第三步，把新阵列的盘添加新现有的ASM磁盘组中，并且删除原有阵列对应的ASM磁盘。这一步将asm_power_limit参数设置成为11，以使ASM重建能够最快。
这样子迁移完毕。

方案3：如果数据量大的话，全盘DD

昨天看了三少的帖子，关于在生产库进行用户系统或者对象权限的重新授予的风险，今天在群里讨论了下：

结论主要有一下：

重新授予权限将导致 SHARE POOL里的SQL重新解析，也就说重新授于对象权限，将导致缓冲里的涉及到该对象的SQL失效，其实这点很容易里理解，明白SQL执行的过程就能理解，判断：

根据Oracle官方的说法，SQL语句的执行有以下步骤：

l [1] Syntactic                - 语法检查l[2] Semantic                 - 确认所有对象都是存在并且可以访问 

l [3] View Merging             - 进行查询重写优化l [4] Statement Transformation – 将复杂的查询分

l [5] Optimization             - 确定访问方式，选择优化策略

l [6] QEP Generation           - 形成执行计划l [7] QEP Execution            - 执行

可见在第2步时就要重新确认，

具体可以参照白老大的：http://www.oraclefans.cn/forum/showblog.jsp?rootid=5597文章

所以结论就是：

1:如果是系统权限,对运行影响不大

2:如果是对象权限,会导致使用该对象的所有sql重新解析,产生严重的latch free等待,系统越繁忙影响越大.

所以操作时，尽量在事务比较少的时候做，解析主要影响的就是CPU。

原文连接：

http://zhouwf0726.itpub.net/post/9689/159280 

1 数据库的物理结构和逻辑结构之间的关系由后台进程来维护和实现，后台进程由数据库来管理

2 只有当出现问题，才创建跟踪文件。后台进程追踪文件的命令约定和位置随操作系统和数据库版本而定

3 一般而言，追踪文件含有后台进程名和后台进程的操作系统进程ID。通过设定BACKGROUND_DUMP_DEST来指定后台进程追踪文件位置

4 排除数据库故障时，追踪文件是最重要的

(全文…)

HP_UX常用查看系统各项设备信息命令： 

1.      # ioscan -fn

列出各I/O卡及设备的所有相关信息：如逻辑单元号，硬件地址及设备文件名等。

2.      # ps -ef

列出正在运行的所有进程的各种信息：如进程号及进程名等。

3.      # netstat -rn

列出网卡状态及路由信息等。

4.      # lanscan

列出网卡状态及网络配置信息。

5.      # bdf

列出已加载的逻辑卷及其大小信息。

6.      # mount

列出已加载的逻辑卷及其加载位置。

7.      # uname -a

列出系统ID 号，OS版本及用户权限等信息。

8.      # hostname

列出系统网络名称。

9.      # pvdisplay -v /dev/dsk/c*t*d*

显示磁盘各种信息，如磁盘大小，包含的逻辑卷，设备名称等。

10. # vgdisplay -v /dev/vg00

显示逻辑卷组信息，如包含哪些物理盘及逻辑卷等。

11. # lvdisplay -v /dev/vg00/lvol1

显示逻辑卷各种信息，如包含哪些盘，是否有镜像等。

(全文…)