aix5.3 System Installation Oracle 10g using bare device--4k offset issue

Today, friends on the AIX 5.3 system installed Oracle 10g build database is used bare device, DBCA to 2% error exit, observe alert log discovery is the temp table space caused by insufficient space. View the tablespace data file with a bare device capacity of 512M, the data file size given when the database was built is also 512M. Perhaps because the AIX system is calculated in 1000, and the Oracle database compute capacity is a 1024-based gap, then the Oracle data file size is changed to 500M, then normal.

However, in the alert log constantly burst WARNING hint: warning:you is creating DATAFILE/DEV/TEMP01.
Warning:oracle recommends creating new datafiles on devices with zero offset. The command "/usr/sbin/mklv-y lvname- t O -w N-S n-r n vgname numpps" can be used. Please contact Oracle Customer support for more details. By querying the information and the help of friends, finally found the cause of the problem and get the solution.

AIX has 3 VG types available when creating VG, Original Volume group,big Volume Group and scalable Volume Group
For ordinary VG (Original Volume Group), no matter what command you use to create the LV, it is the normal ds_lv type of LV.
For big VG, it is the only VG that allows both LV types to exist, if we specify-t O (Note that this is the uppercase letter O), create a Ds_lvz type of LV, otherwise, create a normal type of LV. Such as
/usr/sbin/mklv-y lvname- t O -w N-S n-r n vgname numpps.
For VG of the Scalable-type VG type, regardless of the command you use to create the LV, it is an extended Ds_lvz type of LV.
Oracle's warning log shows that when Oracle uses raw devices, it is recommended to set the LV with no 4k.

AIX calls this 4k offset LVCB (logical Volume control block), which consumes the first 512 bytes of 4k, similar to the Oracle data file header, retains the creation time of the LV, the image copy information, the file system mount point, and so on.

2 ways to see if the LV has a 4k offset
1, the host level
No 4k offset:

Reference

#lslv jfkdb_2g_044
LOGICAL volume:jfkdb_2g_044 VOLUME group:jfk_dbvg_01
LV identifier:00c3dff400004c00000001217a9d839e.84 Permission:read/write
VG State:active/complete LV STATE:CLOSED/SYNCD
Type:raw WRITE Verify:off
MAX lps:1024 PP size:32 megabyte (s)
Copies:1 SCHED Policy:parallel
Lps:64 pps:64
STALE pps:0 BB policy:relocatable
Inter-policy:maximum Relocatable:yes
Intra-policy:middle UPPER bound:1024
MOUNT point:n/a Label:none
MIRROR WRITE consistency:on/active
Each LP COPY on A separate PV?: Yes
Serialize IO?: NO
Devicesubtype:ds_lvz

There is a 4k offset:

Reference

[Email protected]_p560q/]# LSLV jfkdb_2g_044
LOGICAL volume:jfkdb_2g_044 VOLUME group:jfk_db_vg01
LV identifier:00ce76de00004c00000001134ee6bc51.84 Permission:read/write
VG State:active/complete LV STATE:OPENED/SYNCD
Type:raw WRITE Verify:off
MAX lps:1024 PP size:32 megabyte (s)
Copies:1 SCHED Policy:parallel
Lps:64 pps:64
STALE pps:0 BB policy:relocatable
Inter-policy:maximum Relocatable:yes
Intra-policy:middle UPPER bound:16
MOUNT point:n/a Label:none
MIRROR WRITE consistency:on/active
Each LP COPY on A separate PV?: Yes
Serialize IO?: NO

(2) Oracle Level:
ORACLE provides a small tool dbfsize (under $oracle_home/bin) to see if the LV has a 4k offset
No 4k offset:

Reference

$ dbfsize/dev/rlvsysaux_1g

Database File:/dev/rlvsysaux_1g
Database file Type:raw device without 4K starting offset
Database file size:40960 8192 byte blocks

There is a 4k offset:

Reference

[[Email protected]_p560q/dev]$ dbfsize/dev/rjfkdb_2g_054

Database File:/dev/rjfkdb_2g_054
Database file Type:raw Device
Database file size:262016 8192 byte blocks

If the database uses block size 16k, create a LV with a 4k offset across the PV, with a stripe block size of 64k. This will result in a 4th block spanning 2 PV (striped operation, and the LVCB is also counted into the stripe block). This can cause
The 4th Oracle block across the tape block spans the disk, and aside from performance considerations, if the system goes down abnormally, or if the storage goes down abnormally, it is very easy to cause database block corruption, causing ora-01578 errors. (Metalink ID 261460.1)

Reference

$ oerr ora 01578
01578, 00000, "ORACLE data block corrupted (file #%s, Block #%s)"
*cause:the data block indicated was corrupted, mostly due to software
Errors.
*action:try to restore the segment containing the block indicated. This
May involve dropping the segment and recreating it. If there
is a trace file, report the errors in it to your ORACLE
Representative.

That is, it is not possible to use original Volume group to cancel the 4k Offerset by using parameters, the only way is to set the Oracle database Db_block_size to 4k. (Not recommended)

When using the big VG, you can create a DS_LVZ type of LV by creating the LV join-t-o parameter, which cancels the previous 4K offset. (But the legend of big VG has known bugs, gu is not recommended to use).

The Scalable-type VG type VG, regardless of the creation of the LV is not with a 4K offset, and support more PP, supporting the largest single file capacity. (It is highly recommended)

This article is from the "cultural Rogue dba Life" blog, reprint please contact the author!

aix5.3 System Installation Oracle 10g using bare device--4k offset issue