Linux 环境下Oracle运维手册(二）

最新推荐文章于 2021-04-07 10:09:34 发布

weixin_34049948

最新推荐文章于 2021-04-07 10:09:34 发布

阅读量249

点赞数

文章标签：数据库运维操作系统

原文链接：http://blog.51cto.com/jasonliping/1405025

版权

8.备份

8.1数据逻辑备份

8.1.1exp

将数据库内的各对象以二进制方式下载成dmp文件，方便数据迁移。

1.buffer：下载数据缓冲区，以字节为单位，缺省依赖操作系统

2.consistent：下载期间所涉及的数据保持readonly，缺省为n

3.direct：使用直通方式，缺省为n

4.feeback：显示处理记录条数，缺省为0，即不显示

5.file：输出文件，缺省为expdat.dmp

6.filesize：输出文件大小，缺省为操作系统最大值

7.indexes：是否下载索引，缺省为n，这是指索引的定义而非数据

8.log：log文件，缺省为无，在标准输出显示

9.owner：指明下载的用户名

10.query：选择记录的一个子集

11.rows：是否下载表记录

12.tables：输出的表名列表

下载整个实例

13.exp hs_user/handsome file=oradb.dmp log=oradb.logfull=y consistent=y direct=y

14.user应具有dba权限

下载某个用户所有对象

15.exp hs_user/handsomefile=dbuser.dmp log=dbuser.log owner=dbuser buffer=4096000 feedback=10000

下载一张或几张表

16.exp hs_user/handsomefile=dbuser.dmp log=dbuser.log tables=table1,table2 buffer=4096000feedback=10000

下载某张表的部分数据(query选项)

17.exp hs_user/handsomefile=dbuser.dmp log=dbuser.log tables=table1 buffer=4096000 feedback=10000query=\”where col1=\’…\’ and col2 \<…\”

18.不可用于嵌套表

以多个固定大小文件方式下载某张表

exp hs_user/handsome file=1.dmp,2.dmp,3.dmp,…filesize=1000m tables=emp buffer=4096000feedback=10000

这种做法通常用在：表数据量较大，单个dump文件可能会超出文件系统的限制

直通路径方式

direct=y，则会取代buffer选项。同时，query选项不可用。

有利于提高下载速度

consistent选项

自export启动后，consistent=y冻结来自其它会话的对export操作的数据对象的更新，这样可以保证dump结果的一致性。但这个过程不能太长，以免回滚段和联机日志消耗完

8.1.2imp

将exp下载的dmp文件上载到数据库内。

19.buffer：上载数据缓冲区，以字节为单位，缺省依赖操作系统

20.commit：上载数据缓冲区中的记录上载后是否执行提交

21.feeback：显示处理记录条数，缺省为0，即不显示

22.file：输入文件，缺省为expdat.dmp

23.filesize：输入文件大小，缺省为操作系统最大值

24.fromuser：指明来源用户方

25.ignore：是否忽略对象创建错误，缺省为n

26.indexes：是否上载索引，缺省为n，这是指索引的定义而非数据，如果上载时索引已建立，此选项即使为n也无效，imp自动更新索引数据

27.log：log文件，缺省为无，在标准输出显示

28.rows：是否上载表记录

29.tables：输入的表名列表

30.touser：指明目的用户方

上载整个实例

31.imp hs_user/handsomefile=oradb.dmp log=oradb.log full=y buffer=4096000 commit=y ignore=yfeedback=10000

上载某个用户所有对象

32.imp hs_user/handsomefile=dbuser.dmp log=dbuser.log fromuser=dbuser touser=dbuser2 buffer=2048000commit=y ignore=y feedback=10000

上载一张或几张表

33.impdbuser2/oracle file=user.dmp log=user.log tables=table1,table2 fromuser=dbusertouser=dbuser2 buffer=2048000 commit=y ignore=y feedback=10000

以多个固定大小文件方式上载某张表

imp hs_user/handsome file=$1.dmp,2.dmp,3.dmp,…$filesize=1000m tables=empfromuser=dbuser touser=dbuser2 buffer=4096000 commit=y ignore=y feedback=10000

8.2控制文件备份

Alter system backup controlfile to trace;

8.3初始参数备份

Create pfile=/tmp/pfile20070723.ora’ from spfile;

8.4其它

至于tnsnames.ora，listener.ora 使用操作系统拷贝。

9.常见问题解决

9.1安装后常用参数设置

参数	说明	参考设置
db_writer_processes	配置为CPU内核数的一半	4
open_cursors	根据AS数量及AS连接数，配置为3000 ~ 5000	5000
optimizer_mode	RULE	RULE
pga_aggregate_target	同样，也与根据AS数量及AS连接数相关，一般为1500 ~ 3000。一般1G ~ 3G	3G
processes	进程数，即可以对外提供服务的数据。同样，也与根据AS数量及AS连接数相关，一般为1500 ~ 3000	2000
session_cached_cursors		300
sessions	设置processes后自动调整。	2205
sga_max_size	内存的一半，如果存储使用的是裸设备，可以提高到60%	10G
sga_target	同上；若设置为小于等sga_max_size，可动态修改；否则则需要先设置sga_max_size	10G
shared_pool_size	不超过800M，一般300M到500M就足够了	800M

注意：基于Linux平安的RAC不可设sga太大，否则可能会有问题。具体参见第9章11节。

SQL> sqlplus / as sysdba

当前参数值查看方法如下(open_cursors)：

SQL> show parameter open_cursors;

参数设置方法如下：

SQL> alter system set open_cursors=4000; --非初始参数

SQL> alter system set db_writer_processes=2 scope=spfile; --初始参数，设置后需要重启数据库

9.2杀死僵死连接

有时候由于客户端的异常退出，会出现一些连接的进程一直在运行，从而不能释放资源，影响系统的性能。可用以下方法实现把僵死的连接清除。

查询数据库死锁

selectdistinct *
from (select t2.username,t2.sid, t2.serial#, t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id =t2.sid)
orderby logon_time;

查询出来的结果就是有死锁的session了，

altersystemkillsession'sid,serial#';

一般情况可以解决数据库存在的死锁了，或通过session id 查到对应的操作系统进程，在unix中杀掉操作系统的进程。

SELECT a.username, c.spid ASos_process_id, c.pid AS oracle_process_id
FROM v$session a, v$process c
WHERE c.addr = a.paddr
and a.sid = m
and a.serial# = n;

采用kill （unix/linux）或 orakill（windows ）

kill -9 os_process_id

9.3AIX内存溢出

环境:

AIX平台，任何版本的Oracle

现象：

第一次：小机内核的CPU利用率达到40%，有一个进程占用内存不释放，Paging Space达到100%。重启AS、迪斯杰备份及小机后利用率及Paging Space下降至正常。

第二次：闭市后用SQLPlus连接到RAC1上，做了一些三方存管帐户的批量修改。晚上在清算处理时，在文件标志复位时发现很慢，查看Paging Space利用率为40%,但小机利用率正常。重开AS及迪斯杰备份后，利用率下降到30%，文件标志复位也很快了，在清算过程中利用率也一直在下降，一直到19%点多。清算结束后又重开AS及迪斯杰备份， Paging Space利用率为18.9% ，后将RAC1和rac2的ORACLE数据库重开（shut dowm及start）后，下降到5.6%。

原因：

当Sga，Pga设置过小时，数据库会把不能置于内存中的数据放到交换区去，磁盘的IO速度比内存慢很多，所以会对性能产生较大影响。在极端情况下，如果交换分区全部耗尽，那对系统性能的影响就更大了。

在AIX系统中，内存可以分为两类：计算型内存和文件型内存。类似大量文件类操作，如文件复制、压缩、数据库的dump/load等操作会大量占用文件型内存。如果按照系统缺省的配置，文件型内存最多会占用到内存总量的80%，由于文件型内存占用并不主动释放，从而可能造成内存资源的短缺及Paging Space使用率过高。特别是，由于数据库存储使用的是裸设备，允许文件缓存占用大量的内存是没有必要的。

命令topas可以用来查看文件型内存占用内存情况，在MEMORY一栏中的%Noncomp显示的是文件型内存的占用百分比。

如果文件型内存所占比例很高，而Paging Space使用率居高不下时，可以通过降低minperm、maxperm的参数值来进行调优，减少文件型内存可占用的份额。

解决方法：

在进行调整前，首先通过命令vmo -a来查看目前的参数值；minperm及maxperm的缺省值分别是20%和80%。注意：在调小maxperm%前，请产生同时降低maxclient%的值（即maxclient%的值不得大于maxperm%的参数值）。谨慎起见，可以通过小量多次调整来达到性能优化的目的。如maxperm% 可以依次调整了60，40，20，同时查看性能的性能。

最终可能可以调整为：

vmo -o minperm%=10

vmo -o maxclient%=20

vmo -o maxperm%=20

因为参数maxperm充当的是软限制，所以文件型内存的占用率依旧可以超过maxperm的设定值。如果需要进行强制限制，则需要将参数strict_maxperm的值设为1，该参数的缺省值为0，但此方法需谨慎使用。

其它

交换分区设置过小也可能引起交换分区利用率过高的问题。交换分区的大小与物理内存的大小有关。一般情况下，交换分区可以参照下表设置。

物理内存(RAM)	交换分区(Swap Space)
Between 1024 MB and 2048 MB	2 倍 RAM
Between 2049 MB and 8192 MB	1.5倍RAM
More than 8192 MB	1 倍RAM

9.4某一功能特别慢

取故障生产间的两个快照，然后做一个AWR报靠。同时，也可以用第7部分Troubleshooting提供的语句对数据库进行分析。对抓出来的语句进行分析，如果怀疑是统计信息不正确引起的全表扫瞄，可以先进行统计信息的收集，方法如下。否则则可能需要测试索引。具体联系开发人员。

9.5统计信息失效导致执行计划走全表扫瞄

基于Schema的统计信息收集

begin
dbms_stats.gather_schema_stats(ownname => 'HS_FUTURES',
estimate_percent => 20,
method_opt => 'for all indexed columns size 10',
cascade => true,
degree => 7);
end;

基于表的统计信息收集

Analyzetable hs_secu.entrust computestatistics;

9.6关于DRM

环境:

10g，至少HP-UN

现象：

在2007-05-21 14:42:00 左右，管理员发现报盘系统hang住，AS队列上有大量积压，但未登陆到oracle系统查看等待事件，也未作其他的数据库方面的诊断处理。sqlplus正常登陆但比较缓慢。在操作系统层面，节点1的cpu利用率为0，节点2的cpu利用率为20。管理员在反复关闭并重开报盘系统3分钟左右后，系统正常运行。

事后，HP工程师在主机层面查看了相关的日志信息，并未发现什么异常的情况，同时表示无法在现有资源下监控数据库数据线网络的流量。查看了oracle 的相关日志，发现里面有大量的关于DRM 的信息，根据里面的信息，我猜测可能是由于数据库的对象资源动态管理过于频繁，在两个实例之间来回“震荡”时出现异常的缘故。

原因：

由于在oracle的日志和跟踪文件里未能找到与DRM 相关的以外的其他有用信息。根据Oracle 工程师的反馈，可以对DRM 做一些处理。并表示对系统性能并无什么影响。再者，从Oracle的trace文件里可以看出在两次交易故障发生时，oracle rac的DRM 正在做大量的数据同步信息，可查看pdcrac1_lmon_18807.trc。因此，综合以上的各种信息，有必要现在针对DRM方面做一些处理，修改以下初始化参数。

_gc_affinity_time=0 # defines the frequency in minutes tocheck if remastering is needed.
_gc_undo_affinity=FALSE # defines thenumber of times a node must access an object for it to be a DRM candidate

解决方法：

1．备份当前的数据库服务器参数

SQL> Create pfile=’home/oracle/initsid.ora’from spfile;

2．修改备份出来的数据库参数文件，在文件末尾添加

*._gc_affinity_time=0

*._gc_undo_affinity=false

3．shutdown 当前数据库，已刚才备份修改后的数据库参数文件启动到nomount

SQL> Shutdown immediate (两台机)

SQL> Startuppfile=’/home/oracle/initsid.ora’ nomount;

SQL> Create spfile=’/dev/raw/rspfile’ frompfile=’/home/oracle/initsid.ora’;

4．shutdown 当前数据库并重起数据库

SQL> Startup

其它

下面内容是trace文件的部分内容。

kjfcrfg: DRM windowsize = 0->4096 (min lognb = 15)

*** 2007-05-1915:28:08.141

Reconfigurationstarted (old inc 0, new inc 16)

Synchronization timeoutinterval: 900 sec

List of nodes:

0 1

*** 2007-05-1915:28:08.141

Global Resource Directory frozen

node 0

release 10 2 0 2

node 1

release 10 2 0 2

number of mastership buckets = 128

domain attach calledfor domid 0

* kjbdomalc: domain0 invalid = TRUE

* kjbdomatt: firstattach for domain 0

asby init, 0/0/x1

asby returns, 0/0/x1/false

* Domain maps beforereconfiguration:

* DOMAIN 0 (valid 0): 0

* End of domainmappings

* Domain maps afterrecomputation:

* DOMAIN 0 (valid 0): 0 1

* End of domainmappings

Dead inst

Join inst 0 1

Exist inst

Active Sendback Threshold = 50 %

Communication channels reestablished

sent syncr inc 16 lvl 1 to 0 (16,5/0/0)

sent synca inc 16 lvl 1 (16,5/0/0)

received all domreplay (16.6)

sent master 1 (16.6)

sent syncr inc 16 lvl 2 to 0 (16,7/0/0)

sent synca inc 16 lvl 2 (16,7/0/0)

Master broadcasted resource hash value bitmaps

* kjfcrfg: domain 0valid, valid_ver = 16

Non-local Process blocks cleaned out

Set master node info

sent syncr inc 16 lvl 3 to 0 (16,13/0/0)

sent synca inc 16 lvl 3 (16,13/0/0)

Submitted all remote-enqueue requests

kjfcrfg: Number ofmesgs sent to node 1 = 0

sent syncr inc 16 lvl 4 to 0 (16,15/0/0)

sent synca inc 16 lvl 4 (16,15/0/0)

Dwn-cvts replayed, VALBLKs dubious

sent syncr inc 16 lvl 5 to 0 (16,18/0/0)

sent synca inc 16 lvl 5 (16,18/0/0)

All grantable enqueues granted

sent syncr inc 16 lvl 6 to 0 (16,20/0/0)

sent synca inc 16 lvl 6 (16,20/0/0)

*** 2007-05-1915:28:09.638

Submitted all GCS cache requests

sent syncr inc 16 lvl 7 to 0 (16,22/0/0)

sent synca inc 16 lvl 7 (16,22/0/0)

Post SMON to start 1st pass IR

Fix write in gcs resources

sent syncr inc 16 lvl 8 to 0 (16,24/0/0)

sent synca inc 16 lvl 8 (16,24/0/0)

*** 2007-05-19 15:28:12.962

Reconfigurationcomplete

* domain 0 valid?: 1

*** 2007-05-1915:28:18.377

kjxgrtmc2: mountingmember 0 thread 1

Begin DRM(32)

sent syncr inc 16 lvl 9 to 0 (16,0/31/0)

sent synca inc 16 lvl 9 (16,0/31/0)

...

sent syncr inc 16 lvl 39 to 0 (16,0/36/0)

sent synca inc 16 lvl 39 (16,0/36/0)

*** 2007-05-1915:28:28.459

sent syncr inc 16 lvl 40 to 0 (16,0/38/0)

sent synca inc 16 lvl 40 (16,0/38/0)

End DRM(32)

9.7日志文件太小引起的切换过于频繁

假设现有三个日志组，每个组内有一个成员，每个成员的大小为512MB，现在想把此三个日志组的成员大小都改为1G。

创建2个新的日志组

alter database add logfile group 4 ('/oracle/oradata/redo04_1.log')size 1024M;
alter database add logfile group 5 ('/oracle/oradata/redo05_1.log') size 1024M;

切换当前日志到新的日志组

alter system switch logfile;

删除旧的日志组

alter database drop logfile group 1;

alter database drop logfile group 2;

alter database drop logfile group 3;

操作系统下删除原日志组1、2、3中的文件

重建日志组1、2、3

alter database add logfile group 1 ('/oracle/oradata/redo01_1.log') size 1024M;

alter database add logfile group 2 ('/oracle/oradata/redo02_1.log') size 1024M;

alter database add logfile group 3 ('/oracle/oradata/redo03_1.log') size 1024M;

切换日志组

alter system switch logfile;

删除中间过渡用的日志组4、5

alter database drop logfile group 4;

alter database drop logfile group 5;

到操作系统下删除原日志组4、5中的文件

备份当前的最新的控制文件

SQL> connect internal

SQL> alter database backup controlfile to trace resetlogs

9.8Oracle连接中断问题

环境:

10201，AIX53(据ORACLE称，在任何操作系统版本都有此问题)

现象：

监听器启动后，隔一段时间（长短不定），就会出现无法连接：

若是用10201版本的SQLPLUS，则会出现 NO LISTENER。

若是用9207 版本的SQLPLUS，则会出现：没反应，HANG住。

原因：

10201 版本上的一个BUG：4518443。其会自动创建一个子监听器，当出现此情况时，监听器将会挂起。

检查是否真因为此BUG造成此现象：

$ ps -ef | grep tnslsnr

ora10g8909 1 0 Sep 15 ? 902:44 /u05/10GHOME/DBHOME/bin/tnslsnr sales -inherit

ora10g22685 8909 0 14:19:23 ? 0:00 /u05/10GHOME/DBHOME/bin/tnslsnr sales -inherit

正常情况只有一个监听器，而此BUG则会出现两个监听器。

解决方法：

打补丁4518443 或者在listener.ora 文件里加入：

SUBSCRIBE_FOR_NODE_DOWN_EVENT_<listener_name>=OFF

其中，<listener_name> 是数据库的监听器的名称。如：

默认情况下，监听器名为：LISTENER 。则语句就是：

SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER=OFF

9.9查询委托返回记录不对

环境:

10g，任何平台

现象：

查询语句结果集返回不全，只返回一条或其中几条。

原因：

未知，怀疑为Oracle Bug

解决方法：

收集相关表的统计信息，如：

SQL> Analyze table hs_secu.entrust compute statistics;

如问题仍然存在，使用下面语句：

SQL> Analyze table hs_secu.entrust compute statisticsfor all indexes;

其它

这个问题已经多次出现，与很多Oracle售前人员交流过，没有定论。目前怀疑与下面这个Bug相关。具体内容参见metalink：Wrong Results Possibleon 10.2 When New "HASH GROUP BY" Feature is Used（DocID: Note:387958.1）

lCause

Bug4604970 Wrong Results With 'Hash Group By 'Aggregation Enabled

Any query that displays "HASH GROUP BY" in theexecution plan could hit this bug.

The "HASH GROUP BY" feature is enabled by defaultin 10.2.

lSolution

Patch 4604970 can be downloaded from Metalink for mostplatforms .

Problem is resolved in latest Patchset release 10.2.0.3.

Workaround:

Increase the memory used by hash group by

Disable the use of hash group by

eg: set optimizer_features_enable to "10.1.0"

set "_gby_hash_aggregation_enabled" to FALSE.

9.10Linux + Oracle 10gRAC的平台上，发生节点重启故障

环境:

l服务器硬件平台：

- HP DL580 G4 4CPU（双核）16G内存

- IBM 3950 4CPU（双核）16G内存

l操作系统平台：

- Redhat Linux AS 4 Update4 64bit

l数据库系统：

- Oracle 10g R2(10.2.0.1)RAC (有2节点的，4节点的)

现象：

其中某一结点操作系统重启。经典场景：前一日清算到资金清算汇总时rac节点2自动重启，次日9:10 rac节点1死机，冷启动后恢复正常。

lALERT.LOG日志

Mon Jun 11 16:54:38 2007

Error: unexpected error (6) from the Cluster Service (LCK0)

Mon Jun 11 16:54:38 2007

Errors in file/u01/app/oracle/admin/rac/bdump/rac1_lck0_9207.trc: