Welcome to deploying Oracle RAC 10g for Mac OS X Server. I'd like to introduce you to... Barb Lunhild from Oracle Corporation. Barb. Thanks, Chris. Good morning, everyone, and thank you for sticking around for the last session of the conference. I appreciate it. My name, as Chris said, is Barb Lunhild. I'm currently product manager for Oracle Real Application Clusters. How many people in the audience use Oracle at all? Barb Lunhild.

Oh, good. Okay. And how many of you have used real application clusters? So a few of you know what it is. And how many of you who've tried it on your Apple Mac OS platform? So even a few of you have done that. So great. So I've worked at Oracle.

I just had my 10th anniversary there. I started out as a field consultant. If you notice the accent somewhere along the way, I originally started in Canada and worked there in consulting, moved into the sales consulting organization, and now work at headquarters and in product manager for the real application clusters option.

So for a lot of my career at Oracle, I've dealt a lot with the high availability side of database and trying to make your applications. And your database very highly available. And that's what real application clusters brings to the table. It's an option of your Oracle database that allows you to have flexible scalability and very high availability.

So what I'm going to talk to you about this morning is what Oracle Real Application Clusters is, just to make sure we're all on the same page and we understand what the product is. And then give you some best practices around deploying RAC in your organization. And then after that, my colleague Jeff Needham is going to come up. And Jeff's been doing some work with the Real Application Clusters on the Mac OS platform. And he's going to give you some tips specifically aimed at the Mac OS platform.

So to start off with, I just thought I'd give you a quote from Noel Yohanna. Noel is one of the analysts from Forrester Research, and he did a review of Oracle real application clusters, talked to many of our customers, and produced a document, which is available to you on the oracle.com website. But his summary out of the document was that really, Oracle real application clusters should be part of anybody's Oracle database strategy.

So here's my standard slide for what is real application clusters. What's the architecture behind it? Because really it's a single Oracle database. So for those of you who are familiar with the Oracle database and know what it is, then RAC is just bringing it a step further. And one of the things you have to think about slightly differently when you start talking about RAC is the fact that we have a single database.

It's one database, so we have our files sitting out there on storage, but we have multiple instances. And when I say an Oracle instance, what I'm talking about is the memory structures and the processes that sit on the server that allow you to access that data that you have stored in there. So in a RAC environment, we have one to many instances.

So if we look at the picture here, we start at the bottom. We've got the database, and we've got the Oracle instance. So we've got the Oracle database, and we've got the Oracle instance. And then we have the data structures sitting out there on disk. And because it's a single database, then you must have it on shared storage.

So usually what that means to people is that they have it on some type of storage area network device, like your X-rayed server that you have in your Apple environment. And that is attached to the different servers that are making up your cluster. It can also be a network-attached storage if that's what you choose to use. So that's connected into Oracle.

So we need a cluster-supported file system. In Oracle, we have introduced the automatic storage management option of the database that allows you to do that. It's a volume manager and a file system that works in a single server, single instance Oracle environment, or a clustered environment. So you don't have to go out and pay extra for a third party. You can also use what we call raw devices.

Or raw partitions. Or you can use certified clustered file systems as well. So these are connected into your servers. And instead of just having one server where we have our database instance, we can have many. And Oracle supports up to 100 nodes in the cluster and 100 instances in the RAC database.

Reality is, today, the biggest clusters that we have in production are probably around 16 nodes. Although there's a lot of data. There's a lot of people out there. We just helped a customer in Australia who's installing a 32-node cluster. Last year at Oracle World, if any of you attended Oracle World, Chuck Rosewatt, our senior executive VP, he had a demonstration of a 100-node cluster. So it's possible. There's people out there testing 40, 60 nodes in their cluster. But most people are around 16 today. Now, your users.

You're connecting into your Oracle database. Whether that's an end user connecting directly to the database or whether that's an application that's connecting as an application server layer, that connects in through your public network. In a cluster environment, we also have a second network in our environment. So you have to have at least two network interfaces. If you want high availability, you're probably going to have more than two network interfaces. So the second network interface and the second network is what we call the interconnect.

It's a private network used just by the nodes in the cluster. The cluster software uses that to talk and do a heartbeat, to know who the group membership is, who's a part of the cluster. And RAC uses it as well to have what we call shared memory, the global cache or the shared cache across all the instances. What that means is when you use an Oracle database, you select data, you insert data. Generally, that data gets interlinked. So we bring the data into memory first. So we bring the data into memory and manipulate it.

Well, if I've already got the data in memory on one of the nodes in the cluster and somebody else on another node needs that data, instead of forcing that Oracle instance to do an IO down to disk, IOs can be costly operations for us in our Oracle environment. I know I've already got it in memory.

And it's much faster for me to ship directly from memory to memory, the SGA to the SGA, than it is to ship directly to the SGA. So I can ship that block, whether it's just a shared block that's selected or a dirty block that's been updated, and go directly from one cache to another.

So we have our two network interfaces. We have our public network. We have our private network for the interconnect. This can be all managed from a single point. Just because you have six nodes, ten nodes, a hundred nodes in your cluster, doesn't mean you have to do a hundred Oracle installs.

All of the utilities that Oracle provides, the Oracle Universal Installer, the Database Configuration Assistant, the Network Configuration Assistant, Grid Control, all are cluster aware. So they allow you a central point of control for your cluster. And you also have command line interfaces such as the SRV CTL command line to allow you from any point in the cluster to manage the environment.

So what are best practices for deploying it? If you're going to start on a project to deploy RAC in your environment, here's some of the things you need to think about. And really what I want to say up front is successfully deploying RAC isn't all about technology. It's pretty cool technology. I like it.

I've been using it ever since it started back in 9i release 1. But a lot of the times the problems we see people having isn't just the RAC technology, but it's their whole environment. And yes, clusters are a little bit more complex than a single instance Oracle environment is.

So you need to have some good operating procedures. You need to have a test environment. Don't have a single node test environment if a cluster is where you're deploying it in production. You want to test these things before you go live. And you've got to have change control. A lot of times if you start throwing fixes in there and not knowing what the right hand and left hand are doing, you'll end up with a problem. your cluster's down and you're in trouble.

So let's look at a few of the things that we want to do. Often when people are deploying RAC, the reason they're doing it is either to scale their application. And the nice thing about RAC is it allows you to take advantage of more commodity type hardware. You can take a whole bunch of two CPU boxes, cluster them together, and support a very large application. You can take advantage of the lower costs that these smaller servers provide you.

Now, if you're doing high availability or even any application that's mission critical to your organization, you usually have a service level. And if you're doing it with RAC, we really want you to start up front and define that service level with your customer. If it's a third party, if it's your business organization, understand what your objective you're achieving with this cluster is, what their expectations are, and be realistic.

I mean, you have to, if you want very high availability, RAC is a piece of the technology that allows you to get there. But it is not the be all and end all story. You have to have the right hardware underneath it. No single point of failure in your environment. So there's a lot of pieces around it. So link your objectives as a technology person to what the business is looking for and make sure everybody's on the same page up front. To avoid disappointment when you go live. a few months later.

I mentioned this before and I'll mention it again. Automatic storage management, it's a feature of your Oracle database, no extra cost to you. You can use it whether you're a single instance Oracle environment or a clustered environment. And it's really there to make manageability of your database easy.

We're growing in databases. I don't know anybody who shrinks their data in their database and has less data this year than they did last year. We all have more data to manage. And most of us don't have another DBA sitting beside us. In fact, a lot of us have less in our team than we did last year. So what ISM is all about is automating the best practices for managing the storage behind your Oracle database.

We've been professing for years, stripe and mirror everything, the same technology it's called. So we take the data, we stripe it across all the disks you give us, and mirroring for high availability. So that's what Oracle's doing is automating those best practices with ASM. It provides excellent support as far as performance. And it makes it easy. You add disks, you remove disks, you don't have to worry about it.

So really, automatic storage management, as long as the operating system sees the disk, you tell Oracle, here's the disk, and we manage where all the files that are part of the Oracle database are put on the disk. You don't have to think about it anymore. You don't have to have a storage administrator spend time going, oh, this index file's hot, let's move it over here. We take care of that. So it provides load balancing of the IO.

If you need more storage, it's easy to add disk. You can add capacity on demand. As long as the OS sees the new disk, you tell ASM, here's the new disk, and what ASM does behind the scenes is it spreads the data across this new disk. It does it real time. You don't have to take an outage. We do it behind the scenes while the database is still working.

Oracle Virtual IPs. With Oracle Database 10g, we introduced the concept of a virtual IP. A virtual IP is just another IP that is on the same subnet as your public network, so where your users are connecting in. Each instance or each node in your cluster will have a virtual IP, and that is what your client should be using to connect to the Oracle instances.

So we give it the virtual IP on each node, the listener listens on that address, the users connect via that address. During normal operations, it works exactly the same as your public LAN ID or your host name of your environment. The reason we put it in there is if we have a failure in the cluster, our goal in a RAC environment is to recover as fast as possible.

And the virtual IP helps us to do that. We don't have to wait for network timeouts. Depending on the platform, these network timeouts can be 5-10 minutes. That's not going to make your system highly available. So what happens is if we lose a node, the virtual IP for that node fails over to another instance in the cluster or another node in the cluster. But when it's on another node, not its home node, all it's doing is sending a NAC.

Sending an error back to the client immediately so the client can try another address in its address list to connect into the RAC database. So we don't have to wait for TCP IP to clean up those ports. So please, your clients, your server, your listener need to have the virtual IP in its addresses.

Automatic workload management. This is some features that we started in 9i and we extended in 10g. And that's the concept of having a service. So traditionally your database was a single service to your application and your application connected to the database. Well in 10g you can create services which are a logical structure that can be a subset of workload against your RAC environment. So I could divide my workload based on modules of my application. I could do it online versus batch.

I could do it reporting versus online users. Because sometimes there's pieces of work that I want to isolate and manage within the workload that I'm running against my RAC database. For example, if I'm running a service that's a 10g workload, I could do it online versus batch. I could do it reporting versus online users.

For example, batch. During the day we may want to isolate it down to one instance so that only that instance is affected if somebody submits a batch job. But at night if I have lots of batch work I have to get done, I may open up that service across other instances. So you as the administrator can define where a service runs at any given time and it's dynamically altered. You can change it at any time and it'll take effect immediately.

The nice thing about a service is that if I offer a service on an instance and that instance fails, I can give it a backup location. So that we automatically bring it up on an alternate instance so that we're always supplying the service your users can connect. Nothing changes at the client.

They say connect me to this service and we find out where the service is currently active and provide a connection to that service. It's linked into some of the other services that we have. So you can have a service that's connected to your database. You can have a service that's connected to your database. You can have a service that's connected to your database. And the scheduler in the Oracle database allows you to map a service directly to a job class and manage your batch that way.

Here's an example of one customer who consolidated many of their databases into a 10g RAC cluster. It's a six-node cluster they're running. In their environment, they have four OLTP services that they run on the first two instances. They have a reporting service, a batch service, and a data warehousing service. So this allowed them to consolidate many workloads and manage them within their six-node RAC cluster.

Fast connection failover. If you're using JDBC for your application, if it's a Java application connecting into the Oracle database, we've provided extra integration to the JDBC driver from Oracle. So that again, this network timeout that can make your application unavailable is eliminated. If anything changes in the configuration of your RAC cluster, we alert the application tier.

So Oracle RAC sends out what we call a FAN event. FAN stands for Fast Application Notification. That event is published. The Oracle clients have then integrated with this technology and they subscribe to these FAN events. So your JDBC connection pool will receive the event. If it's a down event like a down instance, then it will clean up any connections in its pool that were to that instance. So when your application is doing a get connection from the connection pool, it's going to get a connection to an instance that's currently available, not to the failed instance.

We're not waiting for TCP IP to close off those ports. So it's easy for your application to take advantage of it as long as you're using the Oracle JDBC driver. You just turn on a data source parameter and you can immediately take advantage of faster failover for your client. Now, if your client is actively executing a transaction from the connection, we will abort that transaction immediately because it's eventually going to happen because that instance went down where it was running.

Your application still has to have its error management. We're not taking over that function. But what we're doing is giving your application an alert immediately, hey, this instance went down, this transaction failed. And if you've written your application for high availability, you can immediately do another get connection and retry the transaction.

In fact, I've got a customer running their Java application with this functionality in 10G. And for their cluster, no matter what happens in the cluster, node goes down, instance goes down, network goes down, their application transaction, which is normally a transaction's milliseconds, but maximum the transaction takes is seven seconds or less.

So they've hardened their environment and managed it so that they retry their transaction. And even if it's not a transaction, they're still going to have to retry it. And even if an instance has gone down and nodes crashed, they can recover and the application still only ever sees less than seven seconds for the transaction time. So it's an easy way to make a very highly available application.

Another way you can take advantage of these fan events is what we call a notification callout. So this is a script that you run on the server. You put it in a directory, and the directory is up there on the screen, and it's in the Oracle cluster where home. And we execute it every time one of these events occurs.

So you can do things like send a page to your DBA whenever something happens in the cluster. Log a trouble ticket if you have a trouble ticket system. Log some status information. And this example up here is basically doing that. It's just logging trouble ticket information on the system.

There's also other samples on the Oracle technology network. We've got a sample code page. If you go to Sample Code, Real Application Clusters, and there's examples of different types of callouts that you can take advantage of. Testing. I've got it down there three times because it's imperative that you test your environment. And I mean testing functionality as well as testing what we call destructive testing.

So that's what happens when a node dies? What happens if the network dies? What happens if the interconnect dies on your cluster? Test these type of things so that you know what happens and you and your operating procedures are written so that you know what to do in production when that happens. difference. So you build a knowledge base within your organization of how the cluster works, how to debug things, how to manage things in your environment.

It's also a good idea to try to get a realistic workload against your cluster. If you can do that, you're way far ahead in making a successful implementation. So that you can test changes, that you can test the workload. What happens when I have a thousand users? It's very different from when I have two users running the application. Because contention in a cluster can hurt you. And it'll hurt you faster than in a single instance.

So you've got to look for those points of contention and program around it if that's a problem. RAC does great for scalability. We have a lot of applications that scale very well in their clusters. I've got thousands of people using it around the world. But if you've written a poorly scaling application, I'm not going to solve the problem of your application with RAC.

Change control. Big, big thing in your life. And I know we all hate it, but it's necessary. Understand your environment. Adhere to the lifecycle disciplines of testing things QA before they go production. Especially if you're getting into a very mission critical, highly available environment, and RAC often gets put into those environments.

Support procedures. Make sure that you and everybody else knows who is doing what and how to do that. And how to work with your partners such as Apple and Oracle. Are you aware of how to work with us? MetaLink is a good source of information. That's Oracle's support. If you have an Oracle license and a support agreement, you get a MetaLink account. And that's where there's a huge amount of information.

That's where you open your trouble tickets. How do you escalate it if you've got a mission critical problem? Make sure you know how to do these before you have the problem and it's 3am and your system's down and the VP's looking over your shoulder. That's not the time to try to figure out what's going wrong or how do you close it. call Oracle to get some help.

Performance. Monitor your performance and start out with a baseline. Know what you're expecting so when things start to go bad that you can turn around and compare and figure out where things went wrong. Oracle 10g has a lot of functionality to manage it, such as our automatic workload repository.

We take snapshots of the system and store it so you can go back and figure out what's going on in your environment. We also have the automatic database diagnostic monitor that analyzes these snapshots of workload and gives you hints and tips on how to fix things. In a cluster, there's also StatsPack. So if you use StatsPack in 9i, you can use StatsPack in 10g as well.

For a cluster environment, there's things like false node evictions. That's where we kick out a node because something went wrong and you're not sure why. Well, you've got to monitor your system because we have these heartbeats. We have a heartbeat on the network. We also have what we call a voting disk that has a heartbeat. So if we get into what we call a split brain, that means we've lost the network so the nodes don't talk to each other. We need to figure out who's alive.

So if we can't talk across the network, we go to the disk. And if each instance has updated the disk, then we know they're alive. And we're going to eventually kill half of the cluster because we can't have nodes updating the database who can't talk to each other.

We can't have Oracle instances who can't talk to each other updating the database. So the disk heartbeat. Well, if I can't talk to the disk and get that heartbeat, we have what we call a miscount in there. And if we run over that miscount, by default that's 30 seconds, then we're going to evict whoever we couldn't talk to.

So if you're going to have I/O errors, or if you have multi-pathing software or something that allows us not to talk to the disk for over 30 seconds, be careful because you're going to get a node eviction. So that's what I mean when I say avoid false node evictions.

You've got to check your logs and check for things like this. So if you start having errors on your network, if the interconnect can't talk, then you're going to have problems in a cluster. So you need to monitor the network and make sure that you're not getting errors on it and we're not losing bits as we send them across the network.

Here's an example of the automatic database diagnostic monitor and the type of report that you get. So it's looking at the system and giving you hints of where things could have gone wrong in your system. In this environment, it's identifying SQL that have contention for you. So it's pointing you in the right direction and giving you hints on how to fix things to make your system run better. And generally, with the events that we publish, we give you an impact rating. So that you know if this has got a high impact, it's something I want to fix right away. Low impact, I may put it off for an outage that I have down the road.

So some tuning best practices for your application. Things like sequences. If you're using Oracle sequences, sequence numbers, that can be a single point of contention in a cluster. So we recommend that you cache them so that you have a number of sequences cached on each instance. Of course, this means that you can't order the cache or the sequences. So if you have to have an ordered sequence, you may want to look at an alternative way to generate that.

SQL. You want to make sure you're using bind variables. You want to look at your packages, your Oracle PL/SQL procedures, your functions. Those are often better than instead of anonymous PL/SQL blocks. Look at your execution plans for your SQL. Make sure your developers are checking that out before they put things into production.

Space management. It's become pretty well best practice or automatic practice these days, but still like to mention it. Things like what we call automatic segment space management and locally managed table spaces. Those make a big difference in a rack environment, so make sure you use them. And also the temporary table space that you can use for your temp table space.

Application. DDL can be costly in a RAC environment. So look at places where you don't need it and see if you can program around it. Block contention. That is really in a cluster environment the thing that can cause you the biggest grief. If everybody in the application has to update a single block of data, then in a cluster environment that piece of data is going to be shipped everywhere back and forth.

So if there's a high contention on a single block, and we are talking about a block, we're not talking about a block of data, we're talking about a block of data. We're talking about a whole object. But you then need to look at alternatives. Having a smaller block size, partitioning, things like that allow you to spread the contention across multiple blocks so it doesn't cause you time in your application.

And that is, indexes are often a big problem and the same goes for data in your environment. So small tables with densely packed data can be a real issue. So at this point, I'm going to hand it over to Jeff, and Jeff's going to talk to you a little bit more about RAC and specifically on the Mac OS platform.

Hi, I've been working with Apple and Oracle for the last little while, and I've been doing specifically RAC certification on Tiger. So one of the things that I'm going to talk to you a bit about is the upcoming certification release of 10g on Tiger. And while I go along, I'm going to try and incorporate some of the best practices ideas that Barb has been talking about for the last few minutes in order to show you where you make decision points about configuring the platform.

Because like Barb says, this is about platform engineering best practice. The application has to be designed well, but so does the hardware platform and how you construct actually the physical pieces in order to reduce single points of failure, certainly, but also to reduce the complexity as you deploy larger and larger clusters. The complexity is a factor, and you want to be able to have a good solid philosophy towards the platform engineering.

Currently, RAC runs on the G5 XServe, and it is-- is going to typically require at least 4GB of RAM. And the certified configuration that we're using for testing right now in the lab is a dual CPU configuration with at least 2GHz. That's the minimum that we recommend. The 4GB of RAM is probably sufficient for most modest clusters. As I go through this, what I'll be showing you is sort of a modest mid-level cluster where there are a lot of platform issues around hardening that complicate larger clusters.

But I wanted to keep sort of a basic, simple cluster that's a good sample so you sort of get the essence of where the critical platform engineering choices can be made. Like Barb said, you need a shared storage array, and in that case, that's going to be, for us, X-rayed storage. That storage is 2-gigabit fiber channel, and because of that, you have to have a PCI fiber channel card in each node of the cluster.

There are a couple other options that you can do because you have two PCI slots. They're PCI X 133 and there are a couple of other cards you might consider. One of them is the PCI RAID card. This card is used for locally mirroring the disk in the X Serve node. This provides more mirroring capability for the installation media for Tiger.

or Panther if you're still using Panther. And this is going to provide The other alternative, because you only have one slot left, so you kind of have to make a decision about whether you want to harden the interconnect network or if you want to harden the local mirror. Generally, my advice is probably to go with the gigabit card and harden the interconnect network. If, for some reason, the root disk does fail on the node, then the node will fail, and then that's okay because RAC is architected to handle that situation perfectly.

If you harden the interconnect network, then back to Barb's advice about minimizing node eviction circumstances, this minimizes the number of circumstances where you might get into a situation where you have to go out to the voting disk and figure out whether or not you've got split brain. But you have these two choices to put in the other slot. The first slot, of course, has to hold the fiber channel card.

One interesting thing that I found out in the last month or so was that if you put a PCI video card in, and you might put one into the first node, that video card will clock down the PCI X bus to the speed at which that card runs. And so that might impact the performance of how fast the PCI fiber channel card runs. Most people will probably put a video card in node 1 in order to install Oracle using the Java-based Oracle installation.

And then the other three nodes in an example cluster where you have four nodes don't need a video card anyway. But you might want to have video cards during integration and testing. And then the production cluster might not have them at all. Or they could be removed during the final stages of integration testing as you move the integration cluster closer to the production cluster. Again, like Barb said, it's very important that the integration cluster physically match the production cluster. A lot of people do integration and staging QA on maybe a couple of nodes just to make sure the thing functionally works.

You have to integrate and test what you deploy. And I'm repeating that, and it seems redundant, but it's very important because the application may change slightly if you test it on two nodes and then deploy six. So you have this option where you can populate the second PCI slot card, but before you stage into production, you might want to pull it out. And you certainly should do that before you pull the trigger on the production cluster.

The shared storage is the X RAID, X Serve RAID configuration. Oracle databases and databases in general, generally do a lot of I/O. And what that really means is spindles. And one of the things we see a lot is people often buy storage based on capacity. or megabytes per second.

For database applications, these are almost certainly not the metric you should be focusing on. The metric that's the most important for configuring a storage array for databases of any kind is IOs per second that you can get off the disk. The current generation of storage that's the current generation of spindles that are provided with the X-Ray are 7200 RPM, ATA drives. Depending on circumstances, they do about 60 to 80 IOs per second. This is important to know because this will drive the performance of your storage array when it's doing database queries.

Another trick, because you don't always order the storage array with batteries, because if you purchase the SAN, you don't have to buy the batteries. If you don't buy the batteries, you can't turn on the write-back cache, and that's pretty important. Typical X-rays come with a half a gig of memory, and if that's enabled as write-back cache, then having the two batteries as an option, which you would have to order as a configuration option when you purchase the array, or order them later if you already have X-rays installed, then it gets you a half a gigabyte of write-back cache. The other cool thing about the X-ray is that unlike traditional ATA drives that don't support tagged queuing, the X-ray does this, which improves the IOP performance of an individual ATA spindle.

So it's very likely, I have not tested this specifically, I'm sure Apple performance groups internally have, but I don't have the data in front of me. It's very likely that with tagged queuing support in the X-ray, you're probably on the upper end of the 60 to 80 range IOP.

So that's pretty good. Again, RAID 0 plus 1 is probably the best option. I'll talk a little more about that in the context of when you deploy ASM, because ASM might give you, a good option for striping because it's more aware of the workload. And, There's some trade-offs there that I want to talk about in a minute. But generally speaking, for instance, if you wanted to deploy a rack on raw partitions, then it's best to do RAID 0 plus 1. RAID 0 plus 1 is mirrored pairs of disks that then constitute the stripe. And that's probably the best performance, certainly for utilizing IOPS.

It does waste a lot of space, but the name of the game here is IOs per second, and that's a spindle count. In a RAID 0 plus 1 configuration, you are able to lose any drive and not compromise the stripe. Getting the X-RAID to do the replacement re-silvering is probably going to be faster and transparent to the operating system and transparent to Oracle. and will probably do it much faster.

The software configuration that I've been working on lately is getting ready to release and certify Oracle 10g on Tiger.7, 10.4.7. Some minimum software configurations apply to both 10.3.9 Panther and 10.4.7, the version of Java. The version of Oracle and the C compiler that's required in order to link them.

Depending on how you install the software and how many How many SDKs you choose to install, and many people might just install all of Xcode. At the bare minimum, you have to make sure that the X11 SDK is there, or parts of the Oracle installer will not work. But other than that, everything else that you would think to need, like the BSD SDK and the base SDKs, need to be there in order to link.

When Oracle installs, it copies the binaries off the release media, and then it relinks it all for the environment in question, your local environment. And so in order to do that, it needs a functional link environment with all the libraries. It also needs some source headers in order to compile bits and pieces prior to a full linking of the entire binary set.

ASM, along with raw partitions, will be the certified file systems that are supported by 10g. And that certification should be done momentarily within the next month or so. There are a couple of things that you need to be aware of when you use raw partitions or ASM, and that's allocating storage for the Oracle clusterware. Clusterware used to be called CRS, which stands for Cluster Ready Services, and you might see that in the documentation. CRS and clusterware are the same product. Clusterware requires dedicated partitions for the voting disk and the registry disk.

These can be about 256 megabytes. The actual files that are consumed is a little bit smaller, but that's an easy number to remember. At least it was an easy number for me to remember. And those two files should be on a dedicated LUN and not shared physically with any of the media that you decide to either allocate for raw partition databases or as a pool of LUNs that you've allocated on the X-ray in order to give to ASM.

So in our case, we would take a mirrored pair, and unfortunately that would be a 230 gig drive, and we'd carve up two 256 megabyte partitions. You don't want to put anything else on this partition, because when things get critical and Oracle has to figure out whether or not the cluster has gone into an indeterminate state or it needs to detect for split brain, it does that by reading and writing the voting disks, and it needs to do that quickly, and it needs to do that a lot. And that's combined with the interconnect technology. That's how the cluster keeps itself aware.

That pair of disks which constitute that single LUN, which contains two 256 megabyte partitions, is very important and needs to be set aside. If you're familiar with doing admin in Tiger or Panther, then you would use the PDISC and the disk label tools to do that. Disk label is a tool that allows you to be a step removed from the raw inodes that are in /dev.

So it gives you a little more administrative abstraction from the raw inodes. And then the disk label inodes that end up in /dev once you run the command are actually owned by Oracle and not by root. And that usually makes the administrator a little more comfortable, because then the actual underlying inodes are still owned by the system.

Currently, Oracle 10g on Panther and Tiger is a 32-bit version of Oracle. As you might know from using Oracle on other platforms, it's available in 32- and 64-bit configurations. This version, in order to maintain compatibility with Panther, is a 32-bit version. The limit of the shared memory, SGA, on each instance or each node, instance and node are being used interchangeably in that case, is 1.7 gig. There is an old trick that used to be done in Solaris and on 32-bit versions of Linux that is resurrected, again, for this port. And this would allow you to relink the binary.

And change the attach address of where the shared memory region attaches in the process space. And that can give you up to 3.7 gig of shared memory per node. So, again, if you had a 4 gig node and you could relink using Gen KSMS, which is the tool that relocates the attach address... Once you relink, then the new attach address takes effect in the Oracle binary.

Then you can have up to 3.7 gig. At that point, you'd probably want to have more than 4 gig per node, because you're going to need room for foreground processes to connect to Oracle. And if you had all 3.7 gig allocated on a 4 gig machine, you'd probably start swapping. So that wouldn't be very handy.

Sysctl is probably the most tweaking you have to do in terms of tweaking the Panther or Tiger kernel in order to support or to change the defaults in order to run a rack comfortably on a system. Again, kern.shemmax, and there's a whole bunch of shared memory parameters that are in the install guide that go with that.

But shemmax is sort of the big money shared memory parameter. This sets the upper limit of how big a segment can be, and the value here shown is 1.7. Again, Barb mentioned that if you had a production license, with that production license, you get a MetaLink account. And with that MetaLink account, you are able to look up application notes on how to do specific changes regarding this remapping operation. Global Cache Services, this is the interconnect that allows nodes to talk to each other.

You can use instances to talk to each other. This interconnect runs over UDP, and so the standard UDP buffer defaults in Tiger and Panther are not quite sufficient for the kind of traffic load that you might expect in a rack cluster. And again, making these defaults higher is towards minimizing the node eviction probabilities.

Process limits, I believe the default is 200. It's quite low. And so on a typical Oracle cluster, there's at least 30 or 40 background processes that Oracle starts up without anybody even logging in. So depending on the number of connected users or connected sessions, which could map back to the application tier, which could support multiple application tier connections, but the number of actual foreground connections combined with the number of background connections Oracle starts up certainly will exceed 100. By setting it to 2,000, that's probably going to be more than enough for that given node.

I think I will hand it back to Barb at this time, and she'll wrap it up, and then we're going to have a Q&A session at the end. Thanks, Jeff. Okay, just to summarize, just so you know, you can run Oracle RAC 10g on your Mac OS platform. And it's there to provide you with a flexible scalability and high availability option for your Oracle database. Remember, if you're going to implement it, change control, testing, a good test environment is huge in helping you make that project a successful one for you.

And really, Oracle Metalink is an excellent source of information, as well as the Oracle Technology Network. If you go otn.oracle.com slash rack, you'll get to the rack page. Here's some list of different URLs of different information that are useful to you when you're going to rack. So have a look at them. Go look. Most of those are publicly available to you other than Metalink. Metalink. This is the one that you have to have your support account for. But otherwise, it's all public information.