PSU dependancy checking with ASM now enforced in 11G
Posted by John Hallas on January 28, 2010
ASM has to be equal to or higher than the highest version of the databases that are using it and the compatability settings have to be correct.
PSU 1 (Oct 2009) did not enforce that requirement. PSU 2 (Jan 2010) does check.
We determined this because we do not always apply the latest PSU against the ASM binaries but we do against the RDBMS code. Today the following sequence of events took place along with the associated error message.
A new server build with ASM 126.96.36.199 (no PSU) and DB 188.8.131.52 (Jan PSU). Create database fails:
DB alert log:
ORA-19510: failed to set size of 594 blocks for file "+DATA/oiddev1a/controlfile/current.256.709337153" (block size=16384)
ORA-17505: ksfdrsz:1 Failed to resize file to size 594 blocks
ORA-15061: ASM operation not supported 
ORA-1501 signalled during: CREATE DATABASE "OIDDEV1A"
ASM alert log:
NOTE: ASM client OIDDEV1A:OIDDEV1A died unexpectedly.
No useful hits on the net. We tried upping the compatability from 184.108.40.206.0 to 220.127.116.11.0 but it failed because the database was at a higher version. Then the realisation that we do not normally patch the ASM database so that was at 18.104.22.168.0, however the dbms had the Jan 2010 PSU 2 patchset applied which made the database version 22.214.171.124.2. The errror message was correct.
More testing confirmed what we had realised, the Oct 09 PSU 1 patchset had never checked the ASM version but PSU 2 was now performing that check and then stopping the database creation.
So if anybody has jumped to this page because of the post I have just written around PSU patching they will be able to see that I could tell patch 9156613 contained the Oct 09 PSU 1 release because I had not caused the ORA-015061 error seen above whereas if PSU 2 had been applied to the rdbms that would have failed because the ASM instance had not been patched yet.