Part IV – Fixing the Mess
When the 10g installer completes you will have an Oracle 10g install, a Clusterware Service and no database.
With the logical 32GB partition now stamped for ASM, it is now possible to use DBCA to create a new empty database, and DBCA will allow you to specify ASM as the storage medium, whereupon DBCA will also create the ASM instance for you.
However by default on Windows 7 this process will fail, with errors in the Clusterware Service.
Part III – Stamping the Logical Disk
Okay, so we partitioned the disk and we installed Oracle 10g. We now need to stamp our 32GB logical partition for ASM to use. To do this Oracle provides a helpful tool called asmtoolg.exe in the Oracle Home bin directory.
Launching this under Windows 7 results in the following:
Part II – Installing Oracle 10gR2
I had a spare Windows 7 32-bit PC with a 300GB SATA hard disk and this surplus hardware is what I wanted to use to create my ASM sandbox. My initial thought was to download and install Oracle 11gR2 for Windows 32-bit, but this is not an option. When trying to use DBCA to create a database using ASM, the assistant helpfully informs you:
Cannot use ASM for database storage due to following reason: Grid infrastructure or Clusterware home not found. ASM should be running under this home
This is due to Oracle removing Clusterware support in the Windows 32-bit release:
Part I – Partition the Disk
Once upon a time when you purchased Oracle software, they gave you something called a manual. A lot in fact, I fondly remember an entire bookshelf of Oracle 7.1 manuals back when I worked for BP.
Later Oracle decided to save themselves the money, and you the shelf space, and started shipping documentation on CD.
Now everything is online which is both a blessing and a curse.
One of the occupational hazards of being a production DBA is the proverbial 2am call when the production Oracle database crashes.
Oracle has steadily gotten better at self-correcting the issues that cause crashes, and in a well maintained environment with properly sized servers, UPS power, solid backups and Change Control, such outages are mercifully rare.
When they do occur however, it will quickly expose hitherto unforeseen gaps in the production support plan and test the professionalism of all concerned.
The following is a summary of a recent production outage, the symptoms, the causes and the resolutions. Although Oracle’s Metalink system and Oracle Support Services assisted in the identification of the solution, a great deal of work was required from the production DBA staff, and so some of these notes may prove useful for others either as study or worst-case, as verification for anyone facing the same scenario.
Last week a former client experienced a severe hardware failure.
The original incident occurred when a disk subsystem failed. This client uses a very old Solaris system running Solaris 2.6 and much of the hardware is long past its original expected life span.
The database is Oracle 8.1.7.3, and as expected it crashed with the hardware error.
Deciding they could not recover the system themselves, we agreed to to assist them. We were presented with a database with a missing data file – file 204 which we knew to be rlmd01.dbf. The file existed on the disk in the correct location, but Oracle refused to recognize it.
The alert log showed the following errors:
Mon Oct 5 14:04:14 2009 Errors in file /orabin/PROD/comn/admin/bdump/prod_lgwr_16110.trc: ORA-01157: cannot identify/lock data file 204 - see DBWR trace file ORA-01110: data file 204: '/oradata/PROD/data04/rlmd01.dbf'
Checking the UNIX disk we see this:
$ls –al rlmd01.dbf -rw-r--r-- 1 oracle dba 10497461 Oct 5 16:40 rlmd01.dbf
Examining the trace file that accompanied the error, we could that Oracle was really complaining that the data file in question was not a multiple of the logical block size – which is Oracle error 27046.
I put this article together back in 1999, after trying to debug problems with a Beckman Coulter LIMS system running against a VMS database.
The Log Miner feature makes this work obsolete today, but the article might still be of interest to DBAs who want to look under the covers.
the gruffdba 