Last week I spent some time with a client installing Oracle on their production servers. I’ve done lots of installs using Unix/Linux, but it had been a long time since I had done anything on Windows. Windows is supposed to be a whole lot easier than Linux, right?

We started by formatting the database storage disks into two sections, using the inner cylinders for our planned Fast Recovery Area (+FRA) and then the outer cylinders for the database data files (+DATA). Of course we formatted the disks and gave them nice descriptive names, only to find out later that although you format the ASM disks on Linux/Unix, you don’t format them on Windows. Windows wants raw disks. Which makes sense because NTFS really isn’t the greatest…

Once we finished formatting the disks the correct way, we went ahead and created the oracle user and added oracle to the Administrators group. We then installed the Grid Infrastructure and created the DATA disk group for ASM. Once the install was finished we went ahead and added the FRA disk group. With everything in place, the next step was to install the database.

There were two tricks during the database install, one we found by reading the release notes and install documentation, and the other we ended up not discovering until the next day. The first trick is that even though the oracle user was a member of the Administrators group, you should still right click on the cmd.exe icon and choose Run as administrator from the context menu. Everything progressed along nicely until we go to the portion where the Database Configuration Assistant tried to create the database. DBCA gave us the following warning:

Database Configuration Assistant: Warning
PRCR-1006: Failed to add resource ora.orcl.db for null
PRCR-1071: Faild to register or update resource ora.orcl.db
CRS-0245: User doesn't have enough privilege to perform the operation.

That seems strange… oracle is a member of the Administrators group and we started dbca from an Administrative command prompt, why are we getting this warning? It doesn’t look like a good warning, but it was just a warning, so let’s continue and see what happens… After a few more warnings dbca completed, but it was obvious that the installation didn’t work correctly. We used the new oracle deinstall command for Windows and gave the install another shot, only to run into the same errors. This time we decided to see what Google had to say. Searching for those errors didn’t turn up much help in the Windows world. Most folks who have seen those errors before were using Linux and they were having problems with the required groups. Nobody else seemed to be running into those errors on Windows… After asking around a bit and doing some more searching, we decided to take a step back and review everything to make sure we on track. Step 1: Make sure oracle is in the Administrators group. Imagine our surprise to find out that oracle wasn’t a member of Administrators! I was positive that we’d done this first thing in the morning, but apparently we hadn’t. Did I click Cancel instead of OK or something? Who knows… but at least we figured out why the install was working. After adding oracle (back?) into the Administrators group, everything worked just fine. We finished up the install and started getting the database ready for the migrated content from the old system which took us to the end of the day.

The next day we logged into Enterprise Manager Database Control (EM) and attempted to create some export directories using EM. We’d already stored the credentials for the oracle user in EM but for some reason they were no longer working. That’s strange, why not? It was working just fine yesterday… We did some testing and found out that we could configure EM with a different Administrator account and things would work, but not oracle. What was going on? It didn’t make any sense at all! OK: Start at the beginning. Step 1: Check to make sure that oracle is a member of the Administrators group. This time I have to say that I wasn’t as surprised as I was the first time when I saw that oracle was no longer a member of the Administrators group, but I was still curious as to what was happening. I turned to the network administrator only to see a very sheepish grin on his face. It turns out that the organization had configured a domain rule to remove administrator privileges from unknown users. This would run a couple of times a day and we had run into in the middle of the day during our first install and again on our second day. Once we fixed this by adding oracle to the list of known administrators, everything worked just fine again.

So, lessons learned:

1. ASM on Windows uses raw storage.
2. Run your cmd commands as administrator.
3. Make sure there are no funky domain rules to remove administrator privileges from oracle!

My hope is that the next person who runs into this on Windows finds this post. Maybe not… but at least I’ll never forget as writing the blog post and having the experience of the install gives me a better chance of remembering this in the future.