Tuesday, September 22, 2009

Learning ASM: Installing a Database


In my previous posts I logged my experience installing the 11gR2 Grid Infrastructure and getting familiar with ASM. At this point I have a working ASM instance, as well as Oracle High Availability and Cluster Services running, and an ACFS file system, for kicks.

My ASM Disk groups available are:

ASMDATA - Where my database files will go
FRA - Where my Flash Recovery Area will go
FS - Hosts my ACFS partition, where database files will go that wouldn't normally go on an ASM disk.

My goal in this post is not to reproduce the steps in the manual, but to record my own notes of things that are interesting or troublesome along the way. I'm following the steps as documented in the Database Installation Guide 11g Release 2 (11.2) for Linux.

I already configured the kernel parameters and made sure the necessary libraries were installed, and I already created a separate user account (oracle11r2) to host all my files. ASM was installed under the user oragrid, to keep the installations distinct.


First note of "something new" in the install guide is the enhanced Secure Configuration option. I'm a security nut, so I'll be taking this option, especially since it gives more opportunity to learn.

Files are unzipped, X DISPLAY is verified, let's do this...

$ ./runInstaller
You do not have sufficient permissions to access the inventory '/u01/app/oraInventory/orainstRoot.sh.ASMbackup'...

Hit the first issue sooner than I thought.

$ ls /u01/app/oraInventory/orainstRoot.sh.ASMbackup
-rwxr-x--- 1 oragrid oinstall 1623 Sep 8 23:08 /u01/app/oraInventory/orainstRoot.sh.ASMbackup

This one's my own fault. I made a backup of the ASM root.sh script after the ASM install. It does not have group write permissions. Apparently runInstaller checks to see if all directories are accessible, not just specific directories that it will use. I changed the group write permission on the directory, since I don't expect it to be touched anyway. Now runInstaller is able to move onto the prerequisites, and we get the spiffy new 11gR2 Installer GUI.

Note: I'm posting this blog on a different machine, so I'm not taking screen shots as I go. There may be typos since I'm re-typing instead of copy-and-pasting. If you find one, please let me know so I can fix the post.


I'm not setting this up for a connection to MetaLink so I uncheck that, and leave the email blank for now. I get a dialog box letting me know that Uncle Larry won't be looking over my shoulder to inform me of security updates now. That's fine with me for this project.


I'm selecting "Create and configure a database". I can always create another later for the DBCA experience. I'm more curious what this installer does on autopilot.


Even though I am using a desktop class machine, in power, I have been treating it as a server, in function. ASM features are only available under this option, so I'm choosing "Server Class" here.


While I would really like to play with RAC features here at home, I know I don't have the infrastructure for it, so I won't risk confusing myself with a single-node RAC-ish installation. I'm sticking with "Single instance database installation" for this option.


The whole point of this exercise is to learn ASM, so I need to choose "Advanced Install" here, for the opportunity to install on ASM. (Of course I could start with non-ASM and convert to ASM as another exercise, but I have not layed out my partitions to do so).




Enterprise, Standard, or Standard Edition ONE? Here is where licensing would come into play. Since this is under an OTN "get familiar, non-production" license, I'm going with EE with all the options, including Database Vault.


Oracle Base: /u01/app/oracle11r2
Software Location: /u01/app/oracle11r2/product/11.2.0/dbhome_1

I'll take the defaults here, since I expect most places I go will install things in the default layouts. If they don't I'll be able to spot the difference right away.

Since the Oracle Inventory was created when I installed Grid Infrastructure, I'm not given that option here. I like this. I have enough ways to shoot myself in the foot. If Oracle can prevent me from a confusing multiple-inventory situation, I appreciate it.


For now I'm interested in "General Purpose / Transaction Processing".


Global Database Name: ora11r2.localdomain
SID: ora11r2

Normally I would change the localdomain to something appropriate, but I'm not worried about that for this machine. I left it at that default in the Infrastructure install, so that's what the Listener is expecting. I'll leave localdomain here, too.



Enable Auto Memory Management. Yes, please. I'll start with the default 40% of memory (604MB in my case). In the real world I would do some capacity planning beforehand and size this based on a more educated guess, then tune as needed over time.


I'm taking the default here. I'll play with UNICODE in another instance, another time.


Assert All New Security Settings. I'm not upgrading an older database, and I am interested in learning new features, so I'll stick to the default here, which is yes... use the new security settings.


Good, the default is unchecked. I like that. I'll check it here, but for an application database I prefer to not have the sample schemas - less to secure or clean up.


I don't have a Grid Control installation, or agent here, so that's grayed out. That leaves DB Control, which is fine. I'm skipping email notifications for now.


Here's where we get interesting. ASM is selected by default. I put in the password I created for ASMSNMP during the ASM installation. There were fewer options than I expected here.


I haven't allocated space for multiple backups, so I'll leave the automated backups disabled. 11gR2 RMAN features and backup strategies will be an exercise for another time.


Here is the option I expected to see earlier. My database files will go on ASMDATA.






I ran into the same prerequisite failure here on pdksh that I did on the Infrastructure installation. I know I have ksh available, even if it is not pdksh, so I'm Ignoring this issue and continuing. I wouldn't ignore this on a system that needs to remain stable.


I'll save a response file (ora11r2.rsp) to use or review later.


Now we wait while OUI does it's thing.

For status freaks like me, who like to know more than just watching the checklist of what's been done so far, the Details window lets me watch the install log and scroll back through the history without 'tail'ing it in a separate window. Nice touch.

I didn't keep a timer, but for a full EE install on an underpowered machine, the install process moves along pretty well. I'm eager for the opportunity to see it on some bigger iron.

DBCA, on the other hand, is really pokey, but I don't blame DBCA. Now we're hitting the expected performance problems of my machine.

My system is CPU-bound. CPU is pegged at 100% for extended periods. No surprise on this box.
Memory is in good shape - hovering around 30% used.
top shows the database being created using more resources than the ASM database.
iostat DOES show activity spread out across the various partitions representing my ASM disks.

At this point I am seeing ASM get its first workout and I see the load spreading across what would normally be multiple devices. If you didn't read my first post on learning ASM, you missed the fact that I'm simulating 10 disks using 10 partitions on a single physical drive. High Speed anything was never a goal in this exercise.

dbca finished, root.sh run.

The root.sh script complained about dbhome, oraenv, and coraenv already existing in /usr/local/bin. I made backup copies of these and allowed root.sh to overwrite them. diff showed the new files identical to the old, and permissions are such that oragrid won't have a problem, so it appears to be OK to just overwrite what the Grid Installation installed.


This screen simply reminds us of the URL for DB Control. Closed the installer.


Start FireFox, browse to the EM URL, accept the security certificate, and ... waiting ...

DB Control reports the database components are unavailable.
Attempting to connect via sqlplus also fails, with a TNS error.

Clearly, something is misconfigured at this point. Before banging my head and making things worse, I turn the page to the Post-Installation Tasks.

I reboot just to clean things up a bit, and start a piece at a time. I notice my network interface failed on boot - that explains a number of things. I corrected the networking issue and lsnrctl status under oragrid responded as expected.

I login as oracle11r2, set ORACLE_HOME and ORACLE_SID as needed.

Now sqlplus works, and I see the database is already up. This is odd, t me, since the startup flag in /etc/oratab for this instance is 'N'. Oracle Restart is coming into play here. The startup configuration I already did for ASM laid the groundwork for the new instance "ora11r2" being started automatically.

$ ./emctl start dbconsole

DB Console appeared to come up, but crashed upon first login attempt.

I set up the .bash_profile for oracle11r2 to have the proper ORACLE_HOME and ORACLE_SID, created a DBA ID for myself in the database (so I didn't have to login as SYS), then I restarted the DB Console.

When DB Console is running, it appears to be the big CPU hog on this machine. CPU and disk I/O is moderate and acceptable when DB Console is not running.


I followed the relevant steps for post-installation tasks that applied to my instance.

Via DB Console, I found my way to the Flash Recovery Area setting. I changed this from +ASMDATA to +FRA and increased the size to make use of more of the ASM disk group allocated to flash recovery.

At this point Oracle 11g Release 2 is up and running on a tiny machine, with ASM.
Let the learning continue...

No comments:

Post a Comment