The Partnership and Status Table (PST) contains the information about all ASM disks in a disk group – disk number, disk status, partner disk number, heartbeat info and the failgroup info (11g and later).
Allocation unit number 1 on every ASM disk is reserved for the PST, but only some disks will have the PST data.
PST count
In an external redundancy disk group there will be only one copy of the PST.
In a normal redundancy disk group there will be at least two copies of the PST. If there are three or more failgroups, there will be three copies of the PST.
In a high redundancy disk group there will be at least three copies of the PST. If thre are four failgroups, there will be four PST copies, and if there are five or more failgroups there will be five copies of the PST.
Let’s have a look. Note that in each example, the disk group is created with five disks.
External redundancy disk group.
DISK ‘/dev/sdc5’, ‘/dev/sdc6’, ‘/dev/sdc7’, ‘/dev/sdc8’, ‘/dev/sdc9’;Diskgroup created.
ASM alert log:
SQL> CREATE DISKGROUP DG1 EXTERNAL REDUNDANCY
DISK ‘/dev/sdc5’, ‘/dev/sdc6’, ‘/dev/sdc7’, ‘/dev/sdc8’, ‘/dev/sdc9’
Sat Aug 31 20:44:59 2013
NOTE: Assigning number (2,0) to disk (/dev/sdc5)
NOTE: Assigning number (2,1) to disk (/dev/sdc6)
NOTE: Assigning number (2,2) to disk (/dev/sdc7)
NOTE: Assigning number (2,3) to disk (/dev/sdc8)
NOTE: Assigning number (2,4) to disk (/dev/sdc9)
…
NOTE: initiating PST update: grp = 2
Sat Aug 31 20:45:00 2013
GMON updating group 2 at 50 for pid 22, osid 9873
NOTE: group DG1: initial PST location: disk 0000 (PST copy 0)
Sat Aug 31 20:45:00 2013
NOTE: PST update grp = 2 completed successfully
…
We see that ASM creates only one copy of the PST.
Normal redundancy disk group
SQL> CREATE DISKGROUP DG1 NORMAL REDUNDANCY
DISK ‘/dev/sdc5’, ‘/dev/sdc6’, ‘/dev/sdc7’, ‘/dev/sdc8’, ‘/dev/sdc9’;
Diskgroup created.
ASM alert log
SQL> CREATE DISKGROUP DG1 NORMAL REDUNDANCY
DISK ‘/dev/sdc5’, ‘/dev/sdc6’, ‘/dev/sdc7’, ‘/dev/sdc8’, ‘/dev/sdc9’
Sat Aug 31 20:49:28 2013
NOTE: Assigning number (2,0) to disk (/dev/sdc5)
NOTE: Assigning number (2,1) to disk (/dev/sdc6)
NOTE: Assigning number (2,2) to disk (/dev/sdc7)
NOTE: Assigning number (2,3) to disk (/dev/sdc8)
NOTE: Assigning number (2,4) to disk (/dev/sdc9)
…
Sat Aug 31 20:49:28 2013
NOTE: group 2 PST updated.
NOTE: initiating PST update: grp = 2
Sat Aug 31 20:49:28 2013
GMON updating group 2 at 68 for pid 22, osid 9873
NOTE: group DG1: initial PST location: disk 0000 (PST copy 0)
NOTE: group DG1: initial PST location: disk 0001 (PST copy 1)
NOTE: group DG1: initial PST location: disk 0002 (PST copy 2)
Sat Aug 31 20:49:28 2013
NOTE: PST update grp = 2 completed successfully
…
We see that ASM creates three copies of the PST.
High redundancy disk group
SQL> CREATE DISKGROUP DG1 HIGH REDUNDANCY
DISK ‘/dev/sdc5’, ‘/dev/sdc6’, ‘/dev/sdc7’, ‘/dev/sdc8’, ‘/dev/sdc9’;
Diskgroup created.
ASM alert log
SQL> CREATE DISKGROUP DG1 HIGH REDUNDANCY
DISK ‘/dev/sdc5’, ‘/dev/sdc6’, ‘/dev/sdc7’, ‘/dev/sdc8’, ‘/dev/sdc9’
Sat Aug 31 20:51:52 2013
NOTE: Assigning number (2,0) to disk (/dev/sdc5)
NOTE: Assigning number (2,1) to disk (/dev/sdc6)
NOTE: Assigning number (2,2) to disk (/dev/sdc7)
NOTE: Assigning number (2,3) to disk (/dev/sdc8)
NOTE: Assigning number (2,4) to disk (/dev/sdc9)
…
Sat Aug 31 20:51:53 2013
NOTE: group 2 PST updated.
NOTE: initiating PST update: grp = 2
Sat Aug 31 20:51:53 2013
GMON updating group 2 at 77 for pid 22, osid 9873
NOTE: group DG1: initial PST location: disk 0000 (PST copy 0)
NOTE: group DG1: initial PST location: disk 0001 (PST copy 1)
NOTE: group DG1: initial PST location: disk 0002 (PST copy 2)
NOTE: group DG1: initial PST location: disk 0003 (PST copy 3)
NOTE: group DG1: initial PST location: disk 0004 (PST copy 4)
Sat Aug 31 20:51:53 2013
NOTE: PST update grp = 2 completed successfully
…
We see that ASM creates five copies of the PST.
PST relocation
The PST would be relocated in the following cases
- The disk with the PST is not available (on ASM startup)
- The disk goes offline
- There was an I/O error while reading/writing to/from the PST
- Disk is dropped gracefully
In all cases the PST would be relocated to another disk in the same failgroup (if a disk is available in the same failure group) or to another failgroup (that doesn’t already contain a copy of the PST).
Let’s have a look.
SQL> CREATE DISKGROUP DG1 NORMAL REDUNDANCY
DISK ‘/dev/sdc5’, ‘/dev/sdc6’, ‘/dev/sdc7’, ‘/dev/sdc8’;
Diskgroup created.
ASM alert log shows the PST copies are on disks 0, 1 and 2:
NOTE: group DG1: initial PST location: disk 0001 (PST copy 1)
NOTE: group DG1: initial PST location: disk 0002 (PST copy 2)
Let’s drop disk 0:
where group_number = (select group_number from v$asm_diskgroup_stat where name=’DG1′);DISK_NUMBER NAME PATH
———– —————————— —————-
3 DG1_0003 /dev/sdc8
2 DG1_0002 /dev/sdc7
1 DG1_0001 /dev/sdc6
0 DG1_0000 /dev/sdc5
SQL> alter diskgroup DG1 drop disk DG1_0000;
Diskgroup altered.
ASM alert log
SQL> alter diskgroup DG1 drop disk DG1_0000
…
NOTE: initiating PST update: grp 2 (DG1), dsk = 0/0xe9687ff6, mask = 0x6a, op = clear
Sat Aug 31 21:04:37 2013
GMON updating disk modes for group 2 at 96 for pid 24, osid 16502
NOTE: group DG1: updated PST location: disk 0001 (PST copy 0)
NOTE: group DG1: updated PST location: disk 0002 (PST copy 1)
NOTE: group DG1: updated PST location: disk 0003 (PST copy 2)
…
We see that the PST copy from disk 0 was moved to disk 3.
Disk Partners
A disk partnership is a symmetric relationship between two disks in a high or normal redundancy disk group. There is no disk partnership in an external disk groups. For a discussion on this topic, please see the post How many partners.
PST Availability
The PST has to be available before the rest of ASM metadata. When the disk group mount is requested, the GMON process (on the instance requesting a mount) reads all disks in the disk group to find and verify all available PST copies. Once it verifies that there are enough PSTs for a quorum, it mounts the disk group. From that point on, the PST is available in the ASM instance cache, stored in the GMON PGA and protected by an exclusive lock on the PT.n.0 enqueue.
As other ASM instances, in the same cluster, come online they cache the PST in their GMON PGA with shared PT.n.0 enqueue.
Only the GMON (the CKPT in 10gR1) that has an exclusive lock on the PT enqueue, can update the PST information on disks.
PST (GMON) tracing
The GMON trace file will log the PST info every time a disk group mount is attempted. Note that I said attempted, not mounted, as the GMON will log the information regardless of the mount being successful or no. This information may be valuable to Oracle Support in diagnosing disk group mount failures.
This would be a typical information logged in the GMON trace file on a disk group mount:
grpNum: 2
grpTyp: 2
state: 1
callCnt: 103
bforce: 0x0
(lockvalue) valid=1 ver=0.0 ndisks=3 flags=0x3 from inst=0 (I am 1) last=0
————— HDR ——————–
next: 7
last: 7
pst count: 3
pst locations: 1 2 3
incarn: 4
dta size: 4
version: 0
ASM version: 168820736 = 10.1.0.0.0
contenttype: 0
————— LOC MAP —————-
0: dirty 0 cur_loc: 0 stable_loc: 0
1: dirty 0 cur_loc: 0 stable_loc: 0
————— DTA ——————–
1: sts v v(rw) p(rw) a(x) d(x) fg# = 0 addTs = 0 parts: 2 (amp) 3 (amp)
2: sts v v(rw) p(rw) a(x) d(x) fg# = 0 addTs = 0 parts: 1 (amp) 3 (amp)
3: sts v v(rw) p(rw) a(x) d(x) fg# = 0 addTs = 0 parts: 1 (amp) 2 (amp)
…
The section marked === PST === tells us the group number (grpNum), type (grpTyp) and state. The section marked — HDR — shows the number of PST copies (pst count) and the disk numbers that have those copies (pst locations). The secion marked — DTA — shows the actual state of the disks with the PST.
Conclusion
The Partnership and Status Table contains the information about all ASM disks in a disk group – disk number, disk status, partner disk number, heartbeat info and the failgroup info (11g and later).
Allocation unit number 1 on every ASM disk is reserved for the PST, but only some disks will have the PST data. As the PST is a valuable ASM metadata, it is mirrored three times in a normal redundancy disk group and five times in a high redundancy disk group – provided there are enough failgroups of course.
Leave a Reply