Discussions

News: Ellison on Grid Computing: It's Invincible, It's Inevitable

  1. While grid computing has been used in scientific research, it hasn't been applied to business software. At OracleWorld this week, Larry Ellison introduced Oracle's 10g family of products that provide grid computing to all tiers of an enterprise app, aiming to run apps with capacity on demand, at a lower cost and higher level of fault tolerance and reliability.

    In related news, Oracle yesterday urged businesses to standardize on Linux, and a bomb threat caused a temporary evacuation of OracleWorld.

    Recordings of all the OracleWorld keynotes, including those from Ellison, Michael Dell, Scott McNealy and others are available here:http://www.oracle.com/oracleworld/online/sanfrancisco/2003/index.html?keynotes.html.

    Related articles:
    OracleWorld Online (contains lots of live conference content).
    Oracle's Grid Bid: New 10g Set to Tap Grid Computing Power.
    Oracle's Linux roadmap: Standardize on 'unbreakable' Linux distros.
    Ellison on Grid Computing: It's Invincible, It's Inevitable.
    Oracle Application Server 10g.
    Bomb Scare Temporarily Halts OracleWorld, Seybold Shows.

    Threaded Messages (18)

  2. Oracle does not do Grid[ Go to top ]

    Reading Oracles announcement http://www.oracle.com/corporate/press/index.html?2292680.html leads me to the conlusion that once again Oracle has jumped on a bandwagon without really implementing any significant technology.

    This is just a packaging excercise. Oracle 10g is a much grid as 8i was internet.All they are really displaying is some slightly better admin tools.

     This isn't grid computing though. The essence of the grid is that you take complex calculations and data processing and split it into atomic parts , then process these conccurently and assemble once they've finished. It's 'borg' computing.

    Oracle does not have this. Even Oracles RAC is not really a RAC, as you still have to partition your data to get any sort of performance out of it.

    Although I'm still reading the Oracle 10g data, I've only seen the marketing bumf, they state;

     "Oracle's ability to run packaged business applications, such as SAP, unchanged, which means that any business can take advantage of the new software without changing code."

    This to me seems to completely miss what grid computing is about. If you don't re-write applications or at least stack level operations to farm out processing to different nodes transparently and on demand then it is not a grid. What they are talking about it just data location transparency, which you can't get with RAC anyway due to the aformentioned partitioning requirements

    In fact Oracle 10g is just some better admin tools for Oracle.
    http://otn.oracle.com/oramag/oracle/03-sep/o5310gcover_2.html

    So typical Oracle. Their like an inverted iceberg. 9/10ths of their announcements are just fluff, with 1/10th of it being real. I can't believe it's given so much space by so many serious authors.

    Justin


    Oracle - Unbreak-
    ..
    -able
  3. Ellison drained some money for NetWork Computing.
  4. That observation by Sakthivel is quite important. I vividly remember the interviews Ellison gave about the NC and how the NC would change everything. In particular, Ellison promised productivity improvements by an order of magnitude or more (all by using a PC without a disk, with centralized software distribution). That promise was either a delusion, or - given the intelligence and experience of Mr. Ellison - simply a plain marketing lie.

    So, until real data pour in, I wouldn't give an RAA about these statements, and am quite disappointed that hardly anybody in the trade press calls this marketing ploy what it is: a marketing ploy, and a stupid and blatant one.

    Cheers,
        Henrik
  5. Oracle does not do Grid[ Go to top ]

    Can't agree more and missed the point to boot.
    They'll start having a go at writing databses next you just watch...
  6. Re: Oracle does not do Grid[ Go to top ]

    Justin,

    I am not sure how much oracle experience you have, but your comments about the Oracle's technology ( at least the database ) are definetely not true.

    "Even Oracles RAC is not really a RAC, as you still have to partition your data to get any sort of performance out of it. "

    How many RAC systems you have done ? I've done a few and I can tell you that data partitionig is not required at all ( I guess you are refering to OPS , back in the time I've done a few of those also and there you had to partition the data ).

    "Oracle's ability to run packaged business applications, such as SAP, unchanged, which means that any business can take advantage of the new software without changing code."

    "This to me seems to completely miss what grid computing is about. If you don't re-write applications or at least stack level operations to farm out processing to different nodes transparently and on demand then it is not a grid. What they are talking about it just data location transparency, which you can't get with RAC anyway due to the aformentioned partitioning requirements "

    Again I would say that your understanding for RAC seems to be related to OPS.

    "In fact Oracle 10g is just some better admin tools for Oracle"
    I am part of the beta testing of Oracle 10g( database ,not the app server ) ( for the last couple of months ) and I can tell you that your statement is not true. There many new options and improvments in the product ( check Oracle Magazine - it's free ). Before you start making general statements it's better to get an idea for the product I would say.

    I don't work for Oracle Corp , I am just DBA who works with Oracle's ( and MS's also ) technology.

    Regards,
    Alex
  7. Still not Grid[ Go to top ]

    Alex.

    I didn't mean to allude that Oracle 10g just includes admin tools, I know it has lots of new functions etc. Just that their claim to being a Grid database resides or seems to reside solely with their admin/tuning improvements. I'm just reading the oracle literature here. Better or lower admin and better self performant tuning does not a grid make.

    "How many RAC systems you have done ? I've done a few and I can tell you that data partitionig is not required at all ( I guess you are refering to OPS , back in the time I've done a few of those also and there you had to partition the data "

    True I have not programmed RAC, but I am reffering to the oracle literature here.

    Oracle RAC is just a newer version of the clustering from 8i with some technology for avoiding disk writes when nodes interchange blocks.

    Quoted the following from Oracle 9i RAC “Deployment and Performance” manual, page 63: “To reduce Real Application Clusters overhead, each instance in a cluster should ideally perform most DML operations against a set of database tables that is not frequently modified by other instances.”.

    This document further describes how to increase scalability at the application level by doing departmental and user partitioning. By doing this, the application need to be aware of the partitioning.

    Hence not grid, and not a 'Real' application cluster.

    My main beef is with the g for grid. It's just hype that delivers nowhere near the functionality promised.
  8. Re: Still not Grid[ Go to top ]

    Justin,

    Cannot comment a lot on the GRID part ( don't have GRID experience ) but I have experience with RAC ( and cluster technologies in general , not just Oracle's ) and I still can say that data partitioning in RAC is not required at all. The documentation that you are quoting just says that if you partition the app you will get better scalability ( Basically you will reduce the interconnect traffic and some of the internal locking contention ). Without data partitioning SAP app gets around 80-85 % scalability and Oracle apps ( financials and etc ) are around 90-95%. If you partition , cache the sequences and etc you may take this further. Without using the data partition the implementations that I am aware of have pretty nice scalability ( within the numbers above ) so the partitioning wasn't ever considered after the scalability testing. So the Real Application Clusters are Real. You can run the apps without changes . Have you ever tried to port single database app to MS Federated DB architecture ? Not fun at all. There you have to repartition the data , create views and etc. So there you have change your app in order to use the architecture. The only architecture that is similar to RAC is DB2 on OS/390 ( It's called Parallel Sysplex if I remember correctly ). Unfortunately it's tied to the specific hardware and so ( only IBM mainframes ).
    For the grid part like I said I cannot comment a lot, but in the cluster part I see a lot of good improvements in 10g

    Regards,
    Alex
  9. Still not Grid[ Go to top ]

    Absolutely agree with you. 1/10th is true, 9/10ths is hype.
  10. Still not Grid[ Go to top ]

    Quoted the following from Oracle 9i RAC “Deployment and Performance” manual, page 63: “To reduce Real Application Clusters overhead, each instance in a cluster should ideally perform most DML operations against a set of database tables that is not frequently modified by other instances.”.

    I cannot find that quote. Firstly, Oracle page numbers are numbered per chapter. Secondly, I did a search for "DML" in the document and that quote did not exist. Where did you get that quote from, or are you really just a troll?

    The quote I *can* find on page Glossary-4 is:

    "The forced writing of a data block to disk by one instance when the data block is requested by another instance for a DML operation. Forced Writes are practically eliminated in Oracle 9i with Cache Fusion, but they remain relevant if you specify 1:1 or 1:n releaseable or fixed resources with the GC_FILES_TO_LOCKS parameter. In this case Cache Fusion is disabled for that tablespace."

    Which basically says if you keep your old OPS settings, you don't take advantage of 9i RAC's features.

    This document further describes how to increase scalability at the application level by doing departmental and user partitioning. By doing this, the application need to be aware of the partitioning.

    The deployment and performance document does nothing of the sort. You are confusing Oracle Parallel Server with 9i RAC. 9i RAC is not a panacea, it still has overhead and requires analysis for hot blocks - but data partitioning problems do not exist with RAC.

    Let's also not forget that every single other database out there uses a shared nothing architecture and requires horizontal partitioning of data across nodes.

    For the record: I don't work for Oracle, but I am an OCP (fwiw). I know what this technology is capable of - it's capable of a lot more than you're giving it credit for.
  11. Still no Grid.[ Go to top ]

    Perhaps oracle has re-written it... A cursory glance for the orgional on google turned up this.

    Oracle9i Real Application Clusters, Deployment and Performance, Release 1 (9.0.1),

    http://www.engin.umich.edu/caen/wls/software/oracle/rac.901/a89870/appscale.htm#17460

    "To reduce Real Application Clusters overhead, each instance in a cluster should ideally perform most DML operations against a set of database tables that is not frequently modified by other instances. However, variables such as CPU and memory use are also important factors. "

    "Functional Partitioning
    Functional partitioning is often the first logical approach to achieve an optimally performing environment in terms of Real Application Clusters overhead.. Modules and functional areas usually share only a small subset of Oracle objects, so contention is limited.

    On the other hand, as you integrate all modules of your application, there will always be common objects for a given set of modules on any workload. In other words, it is impossible to completely eliminate Real Application Clusters overhead. Therefore, the ideal partitioning strategy depends on how the modules interact, as well as on how each module uses system resources."

    And some more instances
    Separating E-Commerce and Data Warehousing Processing
    Departmental and User Partitioning
    Physical Table Partitioning

    And finnaly

    "Scaling-Up and Partitioning in Real Application Clusters
    If you have properly partitioned your application for Real Application Clusters, then as the size of your database increases you can maintain the same partitioning strategy and simultaneously achieve optimal performance. The partitioning method to use when adding new functionality depends on the types of data the new functions access. If the functions access disjoint data, then your existing partitioning scheme should be adequate. If the new functions access the same data as the existing functions, then you may need to change your partitioning strategy.

    If your application attracts more users than you expected, then you may need to add more instances. Adding a new instance can also require that you repartition your application. "

    Their is some technology with Cache fusion which is fine for distributed reads. But and this is the big but, it is not as you agree the panacea, which it was presented by Oracle as. If you believe the literature you can simply put your application on an oracle RAC. Add some servers and never worry about data location etc. When you get to the nitty gritty you have to do a lot of tuning though.

    The Eddie Beans case study which is supplied with this proves the tuning and partioning needed.

    "This case study assumes you have made an initial database design. To optimize your Real Application Clusters design, follow this methodology:

    Develop an initial database design.

    Analyze access to tables.

    Analyze transaction volume.

    Decide how to partition users and data.

    Decide how to partition indexes, if necessary.

    Implement and tune your design. "!!


    To get back to my origional point, this is Oracle writ large. They've added some features to their database and all of a sudden it's a grid database. Well it's not. Supporting infiniband is a good step towards this , but it is only one piece of the grid puzzle.

    "Let's also not forget that every single other database out there uses a shared nothing architecture and requires horizontal partitioning of data across nodes".

    Shared disk subsytems are also a single point of failure. This is a double edged sword. Each setup has it's own merits.

    HA options from other vendors provide comparable benefits to the Oracle RAC. I wouldn't say Oracles RAC is better than the other leading vendors methodologys.

    I do work for a competitor and I use to be a DBA for a different Oracle competitor. I have always taken exception to Oracle HypeTM however. This is me talking at a personal level. It is one of the reasons why IT consistently fails to live up to expectations. It is hyped, the next big thing is promised. This fails to live up to expectations and we all get burned because of it.

    The biggest thing in IT in 40 years is not Oracle 10g, it is Larrys mouth.
  12. Re: RAC[ Go to top ]

    I'm thinking...

    Who should I believe, two persons who have done it before, or a person who has NOT done it before who also happens to be an Oracle competitor.

    Hmmm...
  13. Mea culpa[ Go to top ]

    Who do you beleive an Oracle competitor, or two people who make money from configuring oracle products! We are all biased in some way.

    J
  14. Can you tell me more[ Go to top ]

    Hi Alexander.

    I am interested , in the setups neccesary for the RAC systems you did. How do you take advantage of multiple nodes? What is the trade off between a plain RAC system versus a partitioned system? Were these oltp systems where you had many read/writes or was it more a dss system where you were reading large volumes of data?

    If you want to make some modifications to the schema how do you adjust for them . Is the maintenance of the schema higher?

    Just fyis for me, this is an intersting subject and knowing how this stuff pans out in the field . I am reading up about the Blue Gene/c at the moment so being able to extrapolate current technology can help me get a roadmap for this.

    TIA
    Justin
  15. Re: Can you tell me more[ Go to top ]

    Hi Justin,

    I will try to answer your questions:

    "I am interested , in the setups necessary for the RAC systems you did. How do you take advantage of multiple nodes? What is the trade off between a plain RAC system versus a partitioned system? Were these oltp systems where you had many read/writes or was it more a dss system where you were reading large volumes of data? "

    The RAC implementations that I've been part of are mainly OLTP systems. ( many relatively short transactions ). It's actually kind of interesting trend. In the beginning ( relase 9.0.1 - 9i relase 1 ) most of the people implementing RAC use to cluster two( or some cases more ) big boxes just for the HA purpose . You will get better HA ( time wise ) on the server level that using cold failover type of cluster ( Veritas Cluster for example ). In this type of a setup your are only getting HA ( and you are paying big time for it - Oracle licenses, two big servers and etc ). After a while the implementations shifted more in direction of scalability and reducing the cost of the system ( Instead of one 16 CPU UNIX box 4 boxes ( Linux/UNIX/Windows ) with 4 CPUS each - the price of the h/w and support is lower , some of those savings you are spending on Oracle licensing but it's still a good picture ( at least this what the clients told me because I wasn't the one buying the hardware ). This way you are getting the HA and scalability on server level at lower price.
    The connections to the nodes are load balanced using the load balancing that comes with RAC ( based on the load of each node ). So all of the nodes participate in the processing . If you use a lot of sequences ( to generate your primary keys for example ) it's a good idea to cache them ( so SEQ$ table are not going to be a hot spot between the nodes ). If partition the system ( and you can do this on the database level or application level ) you may reduce the exchange of the blocks between the nodes via the interconnect ( cache fusion ) so your scalability will go up. The was a must in OPS because most of the exchanges of the blocks had to go through the disks ( pings ) and that was major disadvantage of OPS ( in the latest OPS the contention read/write was resolved but in OPS write/write contention was never resolved ). In RAC the exchange goes through the interconnect which is way faster. For example of one of the nodes needs a block that is not present in the local cache it may get it from some of the other nodes if it's available there instead of doing disk i/o. Basically the idea is that you will have the collective caches of all of the nodes to satisfy the database requests ( you will do i/o mainly when the blocks are not in any of the caches ). If you use 32 bit Oracle there is a restriction of the SGA for UNIX and windows ( around 1.7Gb for Solaris for example ). So having multiple nodes will create bigger cache( at least twice you go for 2 nodes and etc ) that single system( here comes the nice pricing of the Intel based hardware and o/s such Linux ). In 64 bit Oracle there is no such restriction .

    "If you want to make some modifications to the schema how do you adjust for them . Is the maintenance of the schema higher? "
    Like I said in my prior postings the schema design is the same like single instance . The only common change is the caching of the sequences( in rare cases use of reverse key indexes ) .

    Just to finish because is getting kind of long posting I am not saying the RAC is the best solution for everything ( it will be when it gets to 100% scalability which is not going to be easy ) I am just saying that in my experience with this technology it produced the results that were advertised ( OPS did not ). May be there some people that have negative experience with RAC just mine is ok .

    Regards,
    Alex
  16. thanks for the reply[ Go to top ]

    Thanks Alex, that has answered my question.

    Cheers
    Justin
  17. Here we go again...

    I guess "g" is the evolution from "i", what's with the lower case - doesn't Oracle9G10 look cooler. Wow, imagine all those PL/SQL cursors running on grids, so Oracle is not just the "network' or the "internet" anymore. Oracle is the computer!!

    So, it took Oracle 10 years to finally improve their admin console. Perhaps, they used grid computing to accomplish this.
  18. Sometimes I think Ellison feels he has to have a new gimmick every few years.
  19. Oracle 10 is out with grid support. Larry Ellison recently mentioned CERN as a customer and remarked:

    "It's capacity on demand. Plug another server into the grid and the application runs faster and more reliably..."

    He alluded to the grid having "ultimate reliability", which intuitively makes sense maybe in a RAID-like way. Especially on a data grid I could imagine a database machine crashing and not affecting the online retrievability of any data.

    I also suppose grids generally enhance Reliability, Availability, and Serviceability. Farms such as Condor or Jini are a good example of increasing reliability and availavility. The only implementation of the Global Grid Forum's Open Grid Service Architecture standard is a servlet. J2EE has superior serviceability. Since servlets easily tunnel through firewalls and can be arranged into interesting portals, the grid is usefully available at home and on the road. That should suit an over achiever. So right of Oracle to say "It's inevitable."