Archive for 九月, 2008

db file scattered read

星期三, 九月 24th, 2008

This is another very common Wait Event.
It occurs when Oracle performs multiblock reads from disk into non-contiguous
(’scattered’) buffers in the Buffer Cache. Such reads are issued for up to
DB_FILE_MULTIBLOCK_READ_COUNT blocks at a time.
These typically happen for Full Table Scans and for Fast Full Index scans.

If this Wait Event is a significant portion of Wait Time then a number of
approaches are possible:

o Find which SQL statements perform Full Table or Fast Full Index scans and
tune them to make sure these scans are necessary and not the result of a
suboptimal plan.

- Starting with Oracle9i the new view V$SQL_PLAN view can help:
(ignore data dictionary SQL in the output of these queries)
For Full Table scans:
select sql_text from v$sqltext t, v$sql_plan p
where t.hash_value=p.hash_value and p.operation=’TABLE ACCESS’
and p.options=’FULL’
order by p.hash_value, t.piece;
For Fast Full Index scans:
select sql_text from v$sqltext t, v$sql_plan p
where t.hash_value=p.hash_value and p.operation=’INDEX’
and p.options=’FULL SCAN’
order by p.hash_value, t.piece;

- In Oracle8i a possible approach is to find sessions performing multiblock
reads by querying V$SESSION_EVENT for this Wait Event and then SQL Tracing
them. Alternatively, the Top SQL statements for Physical Reads can be
investigated to see if their execution plans contain Full Table or Fast
Full Index scans.

o In cases where such multiblock scans occur from optimal execution plans
it is possible to tune the size of multiblock I/Os issued by Oracle by
setting the instance parameter DB_FILE_MULTIBLOCK_READ_COUNT so that

DB_BLOCK_SIZE x DB_FILE_MULTIBLOCK_READ_COUNT = max_io_size of system

Starting with Oracle10g Release 2 the DB_FILE_MULTIBLOCK_READ_COUNT
initialization parameter is now automatically tuned to use a default value
when this parameter is not set explicitly. This default value corresponds
to the maximum I/O size that can be performed efficiently.
This value is platform-dependent and is 1MB for most platforms.
Because the parameter is expressed in blocks, it will be set to a value that
is equal to the maximum I/O size that can be performed efficiently divided by
the standard block size.

o As blocks read using Full Table and Fast Full Index scans are placed on the
least recently used end of the Buffer Cache replacement lists, sometimes
it may help to use Multiple Buffer Pools and place such segments in the KEEP
pool. For more information please refer to
Note 76374.1 Multiple Buffer Pools

o Partitioning can also be used to reduce the amount of data to be scanned
as Partition Pruning can restrict the scan to a subset of the segment’s
partitions.

o Finally, you can consider reducing the data held in the most frequently
accessed segments (by moving older unneeded data out of the database) or
moving these segments to new faster disks to reduce the response time on
their I/Os.

log file parallel write

星期三, 九月 24th, 2008

The LGWR background process waits for this event while it is copying redo
records from the memory Log Buffer cache to the current redo group’s member
logfiles on disk.

Asynchronous I/O will be used if available to make the write parallel, otherwise
these writes will be done sequentially one member after the other.
However, LGWR has to wait until the I/Os to all member logfiles are complete
before the wait is completed.
Hence, the factor that determines the length of this wait is the speed with
which the I/O subsystem can perform the writes to the logfile members.

To reduce the time waited for this event, one approach is to reduce the amount
of redo generated by the database:

o Make use of UNRECOVERABLE/NOLOGGING options.

o Reduce the number of redo group members to the minimum necessary to ensure
not all members can be lost at the same time.

o Do not leave tablespaces in BACKUP mode for longer than necessary.

o Only use the minimal level of Supplemental Logging required to achieve
the required functionality e.g. in LogMiner, Logical Standby or Streams.

Another approach is to tune the I/O itself:

o Place redo group members on storage locations so that parallel
writes do not contend with each other.

o Do not use RAID-5 for redo logfiles.

o Use Raw Devices for redo logfiles.

o Use faster disks for redo logfiles.

o If archiving is being used setup redo storage so that writes for the current
redo group members do not contend with reads for the group(s) currently being
archived.

patch 6273339

星期四, 九月 11th, 2008

今天在HP-UX 11.23 IA64下打了个小PATCH,记录如下:主要用来解决因为crs reboot_toc 引起主机重启的问题
注意区分下CRS和DB的脚本区别
一 ROOT用户执行:
cd /u01/app/oracle/product/10.2.0/crs/OPatch

custom/scripts/prerootpatch.sh -crshome /u01/app/oracle/product/10.2.0/crs -crsuser oracle

二 ORACLE用执行
cd $ORA_CRS_HOME/OPatch
custom/scripts/prepatch.sh -crshome /u01/app/oracle/product/10.2.0/crs

custom/server/6273339/custom/scripts/prepatch.sh -dbhome /u01/app/oracle/product/10.2.0/db

opatch apply -local -oh /u01/app/oracle/product/10.2.0/crs
opatch apply custom/server/6273339 -local -oh /u01/app/oracle/product/10.2.0/db

custom/scripts/postpatch.sh -crshome /u01/app/oracle/product/10.2.0/crs

custom/server/6273339/custom/scripts/postpatch.sh -dbhome /u01/app/oracle/product/10.2.0/db
三 以ROOT用户执行

cd /u01/app/oracle/product/10.2.0/crs/OPatch
custom/scripts/postrootpatch.sh -crshome /u01/app/oracle/product/10.2.0/crs

四 验证

$ opatch lsinventory -detail -oh /u01/app/oracle/product/10.2.0/crs

验证DB
opatch lsinventory -detail -oh /u01/app/oracle/product/10.2.0/db

回滚:

opatch rollback -id 6273339 -local -oh /u01/app/oracle/product/10.2.0/crs

opatch rollback -id 6273339 -local -oh /u01/app/oracle/product/10.2.0/db

hp-ux 11.23 patch

星期四, 九月 11th, 2008

HP-UX 11.23 FOR 10G ORACLE RAC
系统上需要的补丁:
系统包
o PHCO_32426
o PHKL_32646 替换为:PHKL_36103
o PHKL_32632 s/b PHKL_33656 s/b PHKL_33807 替换为PHKL_36749
o PHKL_32645 替换PHKL_34479 PHKL_37106
o PHKL_33552 s/b PHKL_33563 替换 PHKL_37653
o PHSS_31850 s/b PHSS_34040 替换PHSS_34444 PHSS_36347
o PHSS_31851 s/b PHSS_34043 替换PHSS_34859
o PHSS_31854 s/b PHSS_33357 s/b PHSS_34045 替换 PHSS_34445
o PHSS_31855 s/b PHSS_33350 s/b PHSS_34041 替换 PHSS_35055 PHSS_38140
o PHSS_33275 s/b PHSS_33349 s/b PHSS_34040 替换 PHSS_38134
o PHSS_33276 s/b PHSS_34042 PHSS_36344 PHSS_38136
For PL/SQL native compilation and installation of Pro*C/C++, Oracle Call Interface, Oracle C++ Call Interface, or Oracle XML Developer’s Kit (XDK) , the following patches are required:
o PHSS_33278
o PHSS_33277 PHSS_33279
The following JDK patches:
o PHCO_31553 s/b PHCO_33675 替换PHCO_37940
o PHKL_31500
o PHSS_32213 s/b PHSS_32502 s/b PHSS_34201 替换为PHSS_32502
Note: Refer to the following Web site for information about additional patches that may be required by JDK 1.4.2:

IP=FIRST?

星期五, 九月 5th, 2008

今天群里一个兄弟问RAC里的监听配置IP=FIRST意义,虽然以前经常看见,但是也没考虑过为什么?不过从字面含义看是首先使用IP,查了些文档确认了下,
What is IP=FIRST in the LISTENER.ORA file ?
The (IP=FIRST) statement will make the listener create a listening endpoint on the IP address to which the given HOST resolves. By default, without (IP=FIRST), the listener will listen on all network interfaces
也就说如果你指定了IP=FIRST那么,那么会首先在IP地址上建立监听,即使有HOSTNAME的也是
LISTENER_HP101 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = hp101-vip)(PORT = 1521)(IP = FIRST))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.51.101)(PORT = 1521)(IP = FIRST))
)
)

ORACLE的解释

You may use the following schema in order to interpret the listener behavior when it comes to binding to a TCP protocol address:

(1) If you provide an IP address, the listener will listen on that IP address

(2) If you provide a hostname:

(a) Oracle does a gethostbyname() on that hostname; potentially more than one IP address is returned.

The gethostbyname() library function may query the DNS server(s), the /etc/hosts file, the NIS service and perhaps other methods, based on the system configuration. How this works exactly depends on the operating system type, but usually the /etc/host.conf, /etc/nsswitch.conf and /etc/resolv.conf files are governing the functionality on the UNIX platforms.

You can find the value that is expected to be given by using the ping tool (e.g. “ping ” or “ping -s ” and see what IP address will the hostname resolve to). Do not use host, nslookup or dig to find this information, since these tools will query only the DNS service and may give wrong answers in certain situations.

Be careful that even the ping utility may not disclose you all the information, e.g. it will not show all the addresses associated with a hostname, if there are more than one. Best choice is to use the check-lsnrbind program, attached to this note (see below section “Checking tool”).

(b) Oracle does a gethostname() which will return the system’s configured hostname.

The gethostname() library function (notice the missing by particle) will return the standard hostname set for the system (or current processor, per manual pages); this is usually done at system startup.

You can find the value that is expected to be given by using the hostname tool, without any parameters (e.g. simply run “hostname”).

(c) Oracle does a gethostbyname() on the system’s hostname found in the previous step (2b).

(d) Oracle compares the first IP returned in (2a) to all of the IPs returned in (2c). If no match is found, then the listener will bind to the resolved IP address. The IP address is registered in the listening endpoints list.

— OR —

(e) If a match is found in (2d), the listener binds on all (working) network interfaces. The fully qualified system hostname is registered in the listening endpoints list.

You may recognize that the listener has bound to all interfaces from the “netstat -an” output: if the listener is bound to all interfaces then the IP address 0.0.0.0 will be shown — it programmers’ slang this is known as the INADDR_ANY address
(全文…)