So what was the answer, part III
Continuing the four questions thread I am now one RAC (Real Application Clusters), ASM (Automatic Storage Management) and Grid. Most of the question revolved around “is RAC Grid, is Grid RAC”. General confusion over the terms arose.
RAC is not Grid.
Grid is not RAC.
You can do “Grid” without RAC. RAC can be part of your “Grid” – (the use of many computers together as if they were more or less one larger computer). It doesn’t have to be – but it can be.
ASM can be part of your Grid. Slide storage in, slide storage out, move storage around if you need to. Transportable Tablespaces can be part of your Grid. Enterprise Manager Grid control – obviously (the name should help give it away) can be part of your Grid. Identity Management with centralized control over user identities, passwords, authorizations – can be part of it. In short, anything that helps you achieve the goal of “using many computers together as if they were more or less one larger computer” is part of it.
That seemed to help most people, as they assumed RAC is Grid is RAC is Grid. Simply understanding that RAC is not “Grid” and vice versa helped to clear up lots of confusion.
Then, we got down to talking about RAC and ASM. Why might the individual want to use RAC, what it would provide for them. It always came back to
ASM on the other hand, that was somewhat easier. It seems that the biggest user of disk is – well, the database. Having a bit more control over that resource doesn’t hurt. From the small system, where the DBA doesn’t know how to best utilize their six direct attach disks to a large system with dozens or hundreds of devices – ASM does make sense. The biggest confusion however was again “what is it”. I try to explain things simply – and the easiest way I’ve come up with for describing this is simply
“this is a database file system, it is a file system like any other file system – it is a file system that only contains database stuff however, it is a database file system. It is a database file system that provides redundancy if you need it, as well as database knowledgeable striping of data over all of your available devices”.
That is it – it is a file system. It has file system “drivers”, just like anything else. Once that was understood – it was easier to discuss the ins and outs of ASM.
In short, most of the time spent talking about ASM, RAC, Grid was spent defining terms. Which is actually quite important if you ask me.
RAC is not Grid.
Grid is not RAC.
You can do “Grid” without RAC. RAC can be part of your “Grid” – (the use of many computers together as if they were more or less one larger computer). It doesn’t have to be – but it can be.
ASM can be part of your Grid. Slide storage in, slide storage out, move storage around if you need to. Transportable Tablespaces can be part of your Grid. Enterprise Manager Grid control – obviously (the name should help give it away) can be part of your Grid. Identity Management with centralized control over user identities, passwords, authorizations – can be part of it. In short, anything that helps you achieve the goal of “using many computers together as if they were more or less one larger computer” is part of it.
That seemed to help most people, as they assumed RAC is Grid is RAC is Grid. Simply understanding that RAC is not “Grid” and vice versa helped to clear up lots of confusion.
Then, we got down to talking about RAC and ASM. Why might the individual want to use RAC, what it would provide for them. It always came back to
- Ability to scale in a different way – instead of bigger and bigger machine, with more machines
- Availability, the capability to keep on running when a node in the cluster fails
- Flexibility in resource deployment, the ability to assign or reassign specific nodes to specific services (tasks)
ASM on the other hand, that was somewhat easier. It seems that the biggest user of disk is – well, the database. Having a bit more control over that resource doesn’t hurt. From the small system, where the DBA doesn’t know how to best utilize their six direct attach disks to a large system with dozens or hundreds of devices – ASM does make sense. The biggest confusion however was again “what is it”. I try to explain things simply – and the easiest way I’ve come up with for describing this is simply
“this is a database file system, it is a file system like any other file system – it is a file system that only contains database stuff however, it is a database file system. It is a database file system that provides redundancy if you need it, as well as database knowledgeable striping of data over all of your available devices”.
That is it – it is a file system. It has file system “drivers”, just like anything else. Once that was understood – it was easier to discuss the ins and outs of ASM.
In short, most of the time spent talking about ASM, RAC, Grid was spent defining terms. Which is actually quite important if you ask me.
posted by Thomas Kyte at 6:32 PM
29 Comments:
This comment is for the post a few days ago where you suggest making the network redundant instead of the databases. I am posting here so it gets noticed since I just read it and want your thoughts on my idea.
I agree with your thinking. However I have an idea of how to balance it in my real world. I work for an organization with 25 remote sites all using the same DB via the WAN (all sites are "remote" from the DB and it is geographically wide). They have a front end system to schedule and process customers and when it goes down they can't help customers and lose $. Even with redundant network and central application if anything happens (even at application layer) it would be good to have a way for them to keep working effectively (downtime procedures). My idea was instead of going to paper... to create a crude supplementary application for downtime procedures at the local sites that gets fed data from the production system each 15 minutes (does not slow down production) and lets the staff do downtime procedures with some system support (not just paper) and multi-user for things like a downtime scheduling system on their local segment if needed... it also has a way (likely via the IT department) to "resync" with the mothership in a recovery. This is all just a concept and thought but FYI. It would only get turned on if the "mothership" was down for a considerable time like we know it will be down for at least 30 minutes. What are your thoughts? Of course the less moving parts the better....but this may be a good model for us.
Hi,
You answered the question why you might want to use RAC. Why do you might want to use Grid? What questions should you ask yourselfe (and provide answers to) in order to find out if you need RAC or Grid or both?
Why do you might want to use Grid?
anytime you want to make use of a grid of computers/resources as if they were one thing.
Grid is a collection of technologies - from grid control to manage a bunch of machines, to ASM to manage a bunch of disk, to transportable tablespaces, datapump and so on - to share information.
You don't "use Grid" in as much as you use technologies that enable grid computing to some degree.
Tom, I'd like your thoughts on this pdf concerning RAC.
http://miracleas.dk/WritingsFromMogens/YouProbablyDontNeedRACUSVersion.pdf
hmm that's odd it got snipped
He makes valid points in some cases - as all good arguments do. RAC isn't for everyone - I don't run RAC myself on asktom, but other large sites with needs much larger than mine as far as scale and availability go - they do.
http://miracleas.dk/WritingsFromMogens
/YouProbablyDontNeedRACUSVersion.pdf
hmm that's odd it got snipped take out the return carrage in the url.
So, are there more larger sites or smaller sites?
I've been on job interviews where the interviewer seemed convinced that Grid is RAC, and since I said otherwise, I must not know much about them.
To me, RAC has highlighted the worst of Oracle marketing.
My observation is that most sites can deal much better with Oracle with a fair-sized unix box than a bunch of bleeding edge linii on crappy hardware. I've seen a lot of posts in various places complaining about such hardware - are they representative?
That bit about Dataguard having different pricing than standby - is that documented somewhere?
Word verification: xtcpm (on Valentine's Day, no less)
a bunch of bleeding edge linii on crappy hardware.
I don't know what you mean by that - linux is hardly "bleeding edge", nor is the hardware crappy.
It is less expensive, it cannot hold as many CPU's (major factor in the less expensive), it holds fewer (but significantly faster CPUs than a "big box", can be hooked up to the same sort of storage. I would hardly call it crappy (being the owner of some of that hardware, I definitely know it is not "crappy")
Don't know what you mean about dataguard and standby.
Other than
o dataguard is a feature of enterprise edition
o you can do "your own standby" standby by manually shipping archives with standard edition
but we haven't really talked about data guard on this post?
I don't know what you mean by that - linux is hardly "bleeding edge", nor is the hardware crappy.
A quick google finds things like this. A bit more poking about can find lots of configuration issues about linux.
but we haven't really talked about data guard on this post?
From Mogen's paper:
Note, that Oracle’s pricing policy changed recently regarding standby options (as
pointed out by one alert contributor on the Oracle-L list) so suddenly you now have to
pay full license for the standby nodes if you use them more than 10 days a year. And
always full price for the Data Guard nodes.
I'm not sure if he means this post.
hmm that's odd it got snipped take out the return carrage in the url.
For me, gets snipped in IE, but not in Netscape.
Joel -
I can find postings like that about anything, any OS, any platform. I don't think that means "bleeding edge" (they would be fewer and further between but we can find those for mainframes too I'm sure, it would be harder because less people do it, but most would not consider a mainframe bleeding edge)
I do not believe linux, today, in 2006 is "bleeding edge".
I can find configuration issues with anything.
I don't see that quote, got a page number? couldn't ctl-f for stand and find anything.
I believe the quote is about "if you use some OS based standby stuff - and you fail over for 10 days..." vs "if you use a standby database via data guard - whereby the Oracle software is in fact always running on the failover site"
Just for clarification about the licensing part of this discussion. The official license policy of Oracle with respect to failover was to ALWAYS charge for the licensing of the failover server. In Sep 2002 Oracle added the concept of the 10 day rule for the standby nodes of an active/passive cluster...which in actuality is a lessening of licensing requirements and not an increase.
As far as standby is concerned I cannot find the actual date but it was around the same time frame that Oracle switched from charging a reduced amount for standby licenses (I think 50%) to full price. I suspect this was when DataGuard started to offer physical and logical standby and the standby became actually useable in non-disaster situations for read only operations.
In any event these are not new policies, and are publically documented here: http://www.oracle.com/corporate/pricing/databaselicensing.pdf
Another one to note is the document about how hardware partitioning (LPAR, VMware effect licensing):
http://www.oracle.com/corporate/pricing/partitioning.pdf
Cheers, Greg
P.S. Buy Tom's Books
I think you become to appreciate RAC when you run something like a massive Oracle e-biz instance where you require the ability to fail over between instances with out necessarily failing over to the DR environment.
Obviously this is only one scenario..... it however may enable to chuck out those expensive Sun 25k's and replace with commodity hardware.
Follow up on... “this is a database file system, it is a file system like any other file system – it is a file system that only contains database stuff”.
So going back to the discussion in Part 2 about keeping it simple, what are the pro's of ASM compared to the additional complexity in management.
Your Comment..."It is less expensive, it cannot hold as many CPU'"
Is it really that cheap. I see that the hardware gets cheaper but the Oracle and other licenses bring it back to the same TCO. May be a topic you can cover in detail in the future blog posts.
Oracle King
hat are the pro's of ASM compared to the additional complexity in management.
I don't see "the additional complexity in management"
I see "less complexity", where is the perceived additional complexity?
Having relied on Storage team to do the complex work of managing the diskgroup and redundancy management, I perceive the actvities that need to be planned for ASM as additional complex operations that need to be handled by a DBA.
May be my perception is wrong.. but having 2 VM's ( for root+software and oracle), seems like additional complexity from an overall system perspective..
dba king -
why is managing diskgroup and redundancy "complex"? We (database people) use the vast preponderance of the disk on most systems we are present on. It only makes sense that, well, we know what we need. Maybe the complexity was the impedence mismatch between was the "storage team" knew about database needs and what the dba team knew about storage needs - eg: the inability to communicate with eachother.
the SA's are good at managing file systems.
the DBA's are good at managing their storage needs.
And never shall the two meet really - I don't want software on my database and they don't want database on their software (it is not a reeses peanut butter cup).
You know what is complex - when my storage needs grow next year and the storage team gives me a new mount point. Now what do I do? (spend a week figuring out what to move, what to chop in half, spending a weekend doing it - since moving files is an offline thing - and spending the next week figuring out how many things I got wrong the first week and redoing it.
That is complex, file systems are databases - databases on a database is like a connection pool on a connection pool or a cache of a cache - not necessarily a good thing
Tom, I have a question on this statement:
"You can do “Grid” without RAC."
If so, does it mean the Grid will only have one node?
If so, does it mean the Grid will only have one node?
Grid needs no clusters. You need more than one computer, but you do not need a "cluster of them"
Still do not get it. Do you have any example to show a 10g database grid containing 2 computers without a RAC?
Quote from
http://www.oracle.com/technology/oramag/oracle/03-sep/o53grid.html
"Real Application Clusters. Oracle RAC is the linchpin of a standard grid. RAC is a cluster database with a shared cache architecture that runs on multiple machines, attached through a cluster interconnect, and a shared storage subsystem. An Oracle RAC database not only appears like a single standard Oracle Database 10g to users"
A linchpin is "a piece of", not "the thing"
As I said myself above - Grid is not RAC, RAC is not Grid, RAC *may be part of your grid, but it need not be*
In fact, that very article lists some of the other grid technologies I did (and adds some)
So, I'm confused as to the confusion. RAC can be part of Grid, the article says that - I said that. It (the article) does not say "you are not grid if you are not rac" anywhere.
Ok, here is one example:
two computers.
running application server.
No database, no rac, yet - part of grid.
two computers.
one in the US.
one in the UK.
using streams...
two separate databases, no rac, yet - part of grid.
Grid - a collection of technologies/features/products.
RAC - one of those products that has features that makes one form of grid computing possible
Looks like there has been widespread misunderstaging on grid & cluster. Here is a FAQ on GRID...
http://www.gridcomputing.com/gridfaq.html
Grid is, to my understanding, more a concept then a real thing. It is based on message passing and employs algorithms similar to MPP. I believe that we haven't even begun to understand, much less utilize, things like neural networks.
Once upon a time I had an epiphany when reading a book named "Data Structures + Algorithms = Programs", by N. Wirth. The two most important things in data processing are:
1) What problem are you trying to solve?
2) What algorithm will you use to solve it?
There aren't many algorithms, short of manipulating huge matrices, that could utilize a grid. I have to commend Oracle
for paying attention to the concept of grid at an early stage, while there isn't
much of a practical use for it. This is something that will undoubtedly change in not so distant future. I only hope that not all nodes in the grid will be running
Windows.
Grid is, to my understanding, more a concept then a real thing.
Depends - if you take "research, academia" and apply their definition - maybe.
If you take the definition "lots of computers working together, sharing stuff" - which is close to what I mean when I say grid - you have many tools available to you today.
I know I've said RAC != GRID, GRID != RAC, but RAC is part of GRID and RAC does *not* demand anything even remotely MPP (massively parallel procesing) like.
My RAC/Grid confusion:
Can you provide redundancy and scaling on commodity machines for the DATABASE without using a "RAC cluster".
In other words, Can I have 10 servers in a Grid running Apps and DB, without any of the servers being exclusively used for the DB, like it would be in a traditional RAC.
Can someone point me to a document which will give me some clarity on how the Oracle Grid is licensed, Does it automatically come along with all 10g components? Is the only extra license cost EM Grid Control?
Thanks
Anonym hat gesagt…
My RAC/Grid confusion:
Can you provide redundancy and scaling on commodity machines for the DATABASE without using a "RAC cluster".
This is also what confused me; I really only care about the database, and my understanding was that a database grid could dynamically assign m RAC-instances to n databases, with m > n.
Can you provide redundancy and scaling on commodity machines for the DATABASE without using a "RAC cluster".
redundancy - sure, you can have hot failovers.
scaling - well, no, if you want to scale up a single machine - you'd be getting away from commodity and into "big iron"
This is also what confused me; I really only care about the database, and my understanding was that a database grid could dynamically assign m RAC-instances to n databases, with m > n.
well, what you say disagrees with what the other person said (it cannot be the same thing confusing you - they said "no RAC", you say "RAC")
Yes, you can dynamically add and remove machines from a cluster - sliding them around - as needed.
But if you were in a room where you could do that - you might consider less databases since it is even easier to dynamically reassign the servers to services in a single cluster.
Tom, I have one more question for that...
Grid - a collection of technologies/features/products.
What Oracle does to develope Grid?
Any products (like EM Grid Control) ?
Hi,
Currently our company is firing up the ´ol RAC engine for the main purposes of 99.9% and scalability.
Now what remains unclear to me is the question if our connecting clients will still be facing the problem of just one point of entry.
I admit, I am a real newby on the concept of RAC, but for what I think I know the clients connect to basically one named target (fi. the loadbalancer). What if this first in-line process dies on us?
The main purpose of using Grid technology is that the whole connection stream from point A to B is redundant in my opinion; and I have not seen or heard of requirements (connection redundancy) for the clients when using RAC and this makes me wonder about the availability part.
Currently our company is firing up the ´ol RAC
Your clients can use connect time failover (whereby their tnsnames.ora says "try host1, host2, host3, host3...") - meaning you can have more than one listener.
Your clients can be using an LDAP repository - that points to the right place.
Your clients can be using redudant "big ip" boxes.
There are many ways to provide redundancy for the simple act of "connecting"
POST A COMMENT
<< Home