Re: Recipe for application design to run on RAC
Thanks a lot, Tim. Enjoyable reading. Much appreciated. Just to clarify what data modeling vendor might mean by RAC-aware model: In one of the draft suggestions they had activity class tables that would record all major steps in the system like registration, signing a contract, inventory replenishment etc. This class of tables would be inevitably DMLed from different nodes in active/active deployment and it would probably present bottleneck much like AOL or FND schemas in your example with Oracle Apps Another thing that I saw on the draft ERD was event entity with exclusive arc to 7 (seven!) others. Same thing. On the final one it's broken down into two event_sales and event_inventory. While it's easily can be abstracted to a single entity (similar attributes) they separated them into two presumably to minimize data shuffles over interconnect. Isn't it kind of segregation (if I am not mistaken the term Oracle doco seems to use is application segmentation http://download-west.oracle.com/docs/cd/A97630_01/rac.920/a96598/ebizapps.htm#22163)? Tim, I appreciate your mutual failover suggestion, but I am afraid it wouldn't work here as these 30+ apps would be totally merged and at these point cease to exist as separate schemas. Now to the cool stuff :) Your idea of the middle tier data-routing seems very interesting. Is it like app server having two data sources defined (one for each node) and issuing DMLs based on some sort of criteria? Would it be too much to ask you elaborate on this? Is it one table gets rows inserted from one node with even ids (assuming sequence based artificial PK) and rows with odd ids from another node type of scenario (or something similar like based on type/group/code/whatever but the same table DMLed from different nodes based on data ranges)? Or am I totally off base here? Tim, thanks again for your help! --- Tim Gorman [EMAIL PROTECTED] wrote: comments inline... __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Recipe for application design to run on RAC
Thanks, Raj. --- Jamadagni, Rajendra [EMAIL PROTECTED] wrote: Boris, the example I gave you is 9012 RAC and I have 5 other production systems that are 9202 RAC. BTW remember if you have cluster_database is true, then no matter how many instances, you will see GC traffic and boy those numbers are crooked .. it is a generic problem hopefully there will be patch for it to fix the GC timing.. I think that advise should have been prefixed with something like ... Following statement is issued so that in case your application fails to scale contrary to our well publicized claim that RAC is extensible and scalable, we can always blame on your not-so-well-thought-rac-incompatible design. This way we will be safe and no one in media can blame us. I am pretty sure it is hidden somewhere ... BTW 9202 ... make sure you get all the patches ... this upgrade is a painful story (at-least for us). Raj __ Rajendra JamadagniMIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! -Original Message- Sent: Wednesday, December 04, 2002 9:19 PM To: Multiple recipients of list ORACLE-L On a more serious note the following guidelines look interesting: http://download-west.oracle.com/docs/cd/A97630_01/rac.920/a96600/migrate.htm #1013313 Migrate to RAC ... unless your application was specifically designed to not use cluster database processing. I wonder why would somebody do that? This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*2 __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Recipe for application design to run on RAC
Title: RE: Recipe for application design to run on RAC Boris, the example I gave you is 9012 RAC and I have 5 other production systems that are 9202 RAC. BTW remember if you have cluster_database is true, then no matter how many instances, you will see GC traffic and boy those numbers are crooked .. it is a generic problem hopefully there will be patch for it to fix the GC timing.. I think that advise should have been prefixed with something like ... Following statement is issued so that in case your application fails to scale contrary to our well publicized claim that RAC is extensible and scalable, we can always blame on your not-so-well-thought-rac-incompatible design. This way we will be safe and no one in media can blame us. I am pretty sure it is hidden somewhere ... BTW 9202 ... make sure you get all the patches ... this upgrade is a painful story (at-least for us). Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! -Original Message- From: Boris Dali [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 9:19 PM To: Multiple recipients of list ORACLE-L Subject: RE: Recipe for application design to run on RAC On a more serious note the following guidelines look interesting: http://download-west.oracle.com/docs/cd/A97630_01/rac.920/a96600/migrate.htm#1013313 Migrate to RAC ... unless your application was specifically designed to not use cluster database processing. I wonder why would somebody do that? This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*2
RE: Recipe for application design to run on RAC
Hey Tim... In case we haven't said it lately, we appreciate all the effort you put forth on the list... This is a fantastic thread... Thanks again Tim -Original Message- Sent: Wednesday, December 04, 2002 11:34 PM To: Multiple recipients of list ORACLE-L comments inline... - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, December 04, 2002 8:53 AM Whoa! Tim, thanks a lot for sharing this. Quite an insight. So SELECTs are not a concern. Well, not directly. They do not directly cause buffers to move around. But they can cause a PCM lock to be downgraded from exclusive to shared, thus forcing the instance which had the lock in exclusive-mode to request that it be returned to exclusive. Thus, while the block doesn't leave the Buffer Cache while it's lock is downgraded, it still induces some fiddling back and forth between the instances... INSERTs are a come and see DBA thing (physical design issue). Yes. Prior to 9i, the mechanisms to use are FREELIST GROUPS. Very much eliminates inter-instance contention during INSERTs in OPS... Though I haven't had a chance to play with it yet, the bitmap-oriented 9i replacement for freelists and freelist groups, called automated segment-space mgmt or ASSM, is apparently still only half-baked, purportedly producing all kinds of unexpected results in space wastage and other things. So, in 9iRAC, you might still want to consider using FREELIST GROUPS over ASSM. Again, just my uninformed opinion based on hearsay... DELETEs are relatively infrequent and many get translated into UPDATE (logical as opposed to physical delete). Well, both DELETEs and UPDATEs have the same characteristics from a cache-coherency perspective, so it's six-of-one, half-dozen-the-other... Application partitioning as you clearly explained in your email... Would it be closer to a logical or physical design? I've always tried to use the word segregation as opposed to partitioning, though I slip up occasionally. The word partitioning makes people think about the Partitioning option, which is definitely not intended. There is no relationship between Oracle's Partitioning option and the type of application segregation I'm trying to describe. There are two ways to avoid the latency resulting from OPS pinging or RAC cache-fusion: by happenstance or by planning. Well, actually there are three ways: use OPS/RAC on OpenVMS and neither OPS pinging nor RAC cache-fusion will result in latency. But let's assume that is not an option for you and consider just the other two ways... By happenstance, I mean just hoping that relatively random activity from multiple instances against the same datafiles avoids two (or more) instances wanting the same block for insert, update, or delete. This is pretty rare, but I'm sure it can happen. After all, even a blind dog finds a bone occasionally... By planning, essentially you want your application to somehow enforce that sessions on a database instance only UPDATE or DELETE rows that were INSERTed by that instance. That way, the block buffers are never pinged or cache-fusion shipped to another database instance. There may be some fiddling of the parallel cache-management (PCM) locks if other instances want to read those blocks, but that is less of a concern. So, however your application logic or business practices can ensure that blocks are UPDATEd or DELETEd by the instance from which they were INSERTed, that is what is necessary. Perhaps you can dedicate certain database sessions to specific groups of data (i.e. application module or groups of customers). That doesn't necessarily work all the time; take Oracle Apps as an example, where all application modules inevitably meet in the Application Object Library (AOL) and Foundation (FND) schemas. The surest way I've seen to segregate parts of an application is by making use of data routing capabilities in the middle-tier application-server or transaction-processing monitor layer. If the middle-tier is capable of data-routing, then you can identify each user transaction by the data values and route the transaction to a session connected to one database instance or the other. This is the surest way to accomplish perfect segregation of different database blocks to different instances, when the end-users can't do it. This is usually the case with interactive, OLTP environments. Of course, another way to route transactions is by forcing such rules of application segregation during INSERT, UPDATE, and DELETE by careful data-routing during batch processing. This is the way that it can be implemented for data warehouses... Seems like something that data modeler/architect should be aware of. So in a sense all modeler needs to worry about is UPDATEs as far as future physical implementation for RAC is concerned? Both should be aware, but the decision to include middleware capable of data-routing when designing
Re: Recipe for application design to run on RAC
Whoa! Tim, thanks a lot for sharing this. Quite an insight. So SELECTs are not a concern. INSERTs are a come and see DBA thing (physical design issue). DELETEs are relatively infrequent and many get translated into UPDATE (logical as opposed to physical delete). Application partitioning as you clearly explained in your email... Would it be closer to a logical or physical design? Seems like something that data modeler/architect should be aware of. So in a sense all modeler needs to worry about is UPDATEs as far as future physical implementation for RAC is concerned? The reason I get stuck on phys vs logical here is because client I am with has a clear separation between the two. It's not only different people that deal with it, but in fact different vendors. soapbox Some background (I probably should've included it in my original post): Mission critical system to replace around 30 small in-house developed apps and do some business re-engineering as we go :( Data modeling is done by one vendor, development by another (don't ask), DB support and maintenance are left for internal DBA staff One of the conditions that CTO office mentioned to the modeling company is to keep HA requirements (not really defined yet - but that's another story) in mind. Ok, they turn around bring the data model and declare that they not only kept it in mind, but in fact their model is RAC aware. Well I can't describe how happy damanagement is - such a successful choice they made (to pick this particular company)! But the curious side of me wonders how this data model is different from the one designed for a single node DB? /soapbox And another thing. Tim, you explained clearly how application should be assessed for non-RAC to RAC migration. In my case however application exists mostly on paper (not taking into account these 30 micky mouse apps - the new system suppose to cover much more than that). 1) I guess simulation would be one way to estimate SQL statements of the app and make a decision on whether it can scale on RAC well or not. (And BTW simulation might be worth the trouble irrespective of whether we use RAC or we don't) But frankly so far I've seen prototyping or simulation for the sake of sizing, capacity planning, understanding DML and query profiles, critical tx, memory footprint required etc, etc... only in James Moorle book :( That is not prototyping for the sake of getting client involved at the early development stages - that's been done with all new apps here. And not benchmarking of already existing application, but the one that hasn't been developed yet. 2) More importantly simulation is obviously the most expensive of all alternatives. Analytical modeling of some sort would be much more welcomed by damanagement. What would be your take on this? How new essentially designed from scratch app can be assessed if it can scale well on RAC? Thanks again for your help! --- Tim Gorman [EMAIL PROTECTED] wrote: To be more precise, the real problems in application-partitioning for OPS/RAC are UPDATE, SELECT ... FOR UPDATE, and DELETE statements due to their WHERE clauses... A SELECT statement does not force exclusive access to a database block and so does not directly cause contention for a block in OPS/RAC. An INSERT statement also does not cause contention on tables because the use of FREELIST GROUPS can keep blocks utilized by different instances separate from one another. If the INSERT is inserting a monotonically-ascending data value into an associated index, then contention on the highest-value leaf block can be reduced by using REVERSE indexes. If the INSERT is not inserting monotonically-ascending data values into any indexes, then contention during parallel cache management between indexes should be minimal. So SELECTs are inherently benign and INSERT operations can be controlled with mechanisms to prevent inter-instance contention for blocks. It is the UPDATE, SELECT ... FOR UPDATE, and DELETE statements which truly require consideration in making an OPS/RAC-based application scaleable. If these statements, which operate on database blocks according to their respective WHERE clauses generated by application logic, do not have some form of awareness of assignment of certain data values to specific database instances, then one can expect problems in scaling. Neither OPS nor RAC has any mechanism to minimize contention between instances for block buffers (as with INSERT statements), so it is up to the application itself (which controls the generation of the WHERE clause) to segregate the application somehow. Whether it is by major application module (i.e. sales and marketing versus order entry and inventory versus general ledger, etc) as Boris had illustrated, or by some other mechanism (i.e. all customers whose names start with A-M on one node, all whose names start with N-Z on the other node, etc), the application
RE: Recipe for application design to run on RAC
Title: RE: Recipe for application design to run on RAC H... it is probably not an good example but we too have a (couple of) mission critical app (affects on air production) running on 9i RAC. One of which has two major schema. We logically partitioned the application such that, for two groups of people 9accessing one schema each) we gave them a preference. Schema1 users have tns entry for db1 and fail over to db2 Schema2 users have a preference for db2 with a fail over to db1 This effectively allows us to do load balance, they don't share too much data, so traffic through interconnect is manageable. If need be, we just shutoff listener on one side, and everyone fails over to the other side while we can perform maintenance. All their applications are written in VB, JAVA so they handle fail over from within application. None of the people involved in the design worried about which side of RAC they will be on and how the DML activity affects etc etc. They designed a plain application with a good design and it is working fine. Like I mentioned this is not a good example ... but this is how we did it in one of our major application. Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! *This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*1
RE: Recipe for application design to run on RAC
Title: RE: Recipe for application design to run on RAC So when I access the fantasy football league on the espn web site-I go to schema2 because my team(s) are losing :-) I guess thats what I get when I picked a group of guys that are all on the injured reserve Seriously though--What if 50% of the blocks of data for schema1 are "owned" by db2? do you eventually see where ownership is transferred to the "active" node, reducedcache fusion activity and then transfer of blocks? Do the users on schema1 have to use the data on schema2 at all? I'm trying to see if not only are the users logically partitioned-but if your schemas offer any data partitioning to align with the schema1 and schema2 thanks! Greg -Original Message-From: Jamadagni, Rajendra [mailto:[EMAIL PROTECTED]]Sent: Wednesday, December 04, 2002 2:05 PMTo: Multiple recipients of list ORACLE-LSubject: RE: Recipe for application design to run on RAC H... it is probably not an good example but we too have a (couple of) mission critical app (affects on air production) running on 9i RAC. One of which has two major schema. We logically partitioned the application such that, for two groups of people 9accessing one schema each) we gave them a preference. Schema1 users have tns entry for db1 and fail over to db2 Schema2 users have a preference for db2 with a fail over to db1 This effectively allows us to do load balance, they don't share too much data, so traffic through interconnect is manageable. If need be, we just shutoff listener on one side, and everyone fails over to the other side while we can perform maintenance. All their applications are written in VB, JAVA so they handle fail over from within application. None of the people involved in the design worried about which side of RAC they will be on and how the DML activity affects etc etc. They designed a plain application with a good design and it is working fine. Like I mentioned this is not a good example ... but this is how we did it in one of our major application. Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art!
RE: Recipe for application design to run on RAC
I know I know (he says jumping up and down) Just did the 9i New Features class. The answer is lazy dynamic remastering. Over time, resources are gradually moved to the instance that is using them. More quotes from the manual: Should an instance leave the group, the background processes only remaster resources from the departing instance. Similarly, when a new instance joins the group, the resources are gradually remastered, adapting to the cluster workload. Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- Sent: Wednesday, December 04, 2002 2:30 PM To: Multiple recipients of list ORACLE-L So when I access the fantasy football league on the espn web site-I go to schema2 because my team(s) are losing :-) I guess thats what I get when I picked a group of guys that are all on the injured reserve Seriously though--What if 50% of the blocks of data for schema1 are owned by db2? do you eventually see where ownership is transferred to the active node, reduced cache fusion activity and then transfer of blocks? Do the users on schema1 have to use the data on schema2 at all? I'm trying to see if not only are the users logically partitioned-but if your schemas offer any data partitioning to align with the schema1 and schema2 thanks! Greg -Original Message- Sent: Wednesday, December 04, 2002 2:05 PM To: Multiple recipients of list ORACLE-L H... it is probably not an good example but we too have a (couple of) mission critical app (affects on air production) running on 9i RAC. One of which has two major schema. We logically partitioned the application such that, for two groups of people 9accessing one schema each) we gave them a preference. Schema1 users have tns entry for db1 and fail over to db2 Schema2 users have a preference for db2 with a fail over to db1 This effectively allows us to do load balance, they don't share too much data, so traffic through interconnect is manageable. If need be, we just shutoff listener on one side, and everyone fails over to the other side while we can perform maintenance. All their applications are written in VB, JAVA so they handle fail over from within application. None of the people involved in the design worried about which side of RAC they will be on and how the DML activity affects etc etc. They designed a plain application with a good design and it is working fine. Like I mentioned this is not a good example ... but this is how we did it in one of our major application. Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Recipe for application design to run on RAC
Title: RE: Recipe for application design to run on RAC Greg, FantasyFootball is a different beast and is not hosted on this database. This one deals with live scores and the bottomline ... g. There are only few tables that are shared by both schema, 50% ownership .. hasn't happened yet. We used to see huge global CR issues, but then it turned out to be a AIX issue and Oracle has a workaround for that (most unlikely parameter db_file_multiblock_read_count needs to be reduced). So far what we have seen is undeniably there is global cache traffic, but it isn't like some of our other instances. This way, each side of RAC gets a nice powerful machine to itself, all the resources to itself and is capable of handling at-least 5 times the load we put on it before it breaks a sweat. Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! -Original Message- From: Loughmiller, Greg [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 3:30 PM To: Multiple recipients of list ORACLE-L Subject: RE: Recipe for application design to run on RAC So when I access the fantasy football league on the espn web site-I go to schema2 because my team(s) are losing :-) I guess thats what I get when I picked a group of guys that are all on the injured reserve Seriously though--What if 50% of the blocks of data for schema1 are owned by db2? do you eventually see where ownership is transferred to the active node, reduced cache fusion activity and then transfer of blocks? Do the users on schema1 have to use the data on schema2 at all? I'm trying to see if not only are the users logically partitioned-but if your schemas offer any data partitioning to align with the schema1 and schema2 thanks! Greg *This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*1
RE: Recipe for application design to run on RAC
Dennis, I hate to see do all this jumping up and down but the dynamic re-mastering feature was not implemented in 9i. There is a view called V$GCSPFMASTER_INFO that is supposed to show which node was the master, which node is currently the master and how many times the resource has been re-mastered, but the view is never populated. This is one those if it's in the Doc. it may have been true in the past, It may be true now or it may true in the future. This one of those in the future features. Scott --- DENNIS WILLIAMS [EMAIL PROTECTED] wrote: I know I know (he says jumping up and down) Just did the 9i New Features class. The answer is lazy dynamic remastering. Over time, resources are gradually moved to the instance that is using them. More quotes from the manual: Should an instance leave the group, the background processes only remaster resources from the departing instance. Similarly, when a new instance joins the group, the resources are gradually remastered, adapting to the cluster workload. Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- Sent: Wednesday, December 04, 2002 2:30 PM To: Multiple recipients of list ORACLE-L So when I access the fantasy football league on the espn web site-I go to schema2 because my team(s) are losing :-) I guess thats what I get when I picked a group of guys that are all on the injured reserve Seriously though--What if 50% of the blocks of data for schema1 are owned by db2? do you eventually see where ownership is transferred to the active node, reduced cache fusion activity and then transfer of blocks? Do the users on schema1 have to use the data on schema2 at all? I'm trying to see if not only are the users logically partitioned-but if your schemas offer any data partitioning to align with the schema1 and schema2 thanks! Greg -Original Message- Sent: Wednesday, December 04, 2002 2:05 PM To: Multiple recipients of list ORACLE-L H... it is probably not an good example but we too have a (couple of) mission critical app (affects on air production) running on 9i RAC. One of which has two major schema. We logically partitioned the application such that, for two groups of people 9accessing one schema each) we gave them a preference. Schema1 users have tns entry for db1 and fail over to db2 Schema2 users have a preference for db2 with a fail over to db1 This effectively allows us to do load balance, they don't share too much data, so traffic through interconnect is manageable. If need be, we just shutoff listener on one side, and everyone fails over to the other side while we can perform maintenance. All their applications are written in VB, JAVA so they handle fail over from within application. None of the people involved in the design worried about which side of RAC they will be on and how the DML activity affects etc etc. They designed a plain application with a good design and it is working fine. Like I mentioned this is not a good example ... but this is how we did it in one of our major application. Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Scott INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Recipe for application design to run on RAC
Thanks, Raj. H... it is probably not an good example ... Why not? On the contrary. I am sure damanagement here would love to here this. Besides it fully supports Oracle's statement that application can be migrated to RAC as is (as I think Hemant mentioned). Wait... did you say 9i? release 2? recently? - may be it's a Christmas magic that made it happen for you? (although those sceptical might say that it had to do with your careful app partitioning/segmentation rather than a festive season) On a more serious note the following guidelines look interesting: http://download-west.oracle.com/docs/cd/A97630_01/rac.920/a96600/migrate.htm#1013313 Migrate to RAC ... unless your application was specifically designed to not use cluster database processing. I wonder why would somebody do that? --- Jamadagni, Rajendra [EMAIL PROTECTED] wrote: H... it is probably not an good example but we too have a (couple of) mission critical app (affects on air production) running on 9i RAC. One of which has two major schema. We logically partitioned the application such that, for two groups of people 9accessing one schema each) we gave them a preference. Schema1 users have tns entry for db1 and fail over to db2 Schema2 users have a preference for db2 with a fail over to db1 This effectively allows us to do load balance, they don't share too much data, so traffic through interconnect is manageable. If need be, we just shutoff listener on one side, and everyone fails over to the other side while we can perform maintenance. All their applications are written in VB, JAVA so they handle fail over from within application. None of the people involved in the design worried about which side of RAC they will be on and how the DML activity affects etc etc. They designed a plain application with a good design and it is working fine. Like I mentioned this is not a good example ... but this is how we did it in one of our major application. Raj __ Rajendra JamadagniMIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! *This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*1 __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Recipe for application design to run on RAC
comments inline... - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, December 04, 2002 8:53 AM Whoa! Tim, thanks a lot for sharing this. Quite an insight. So SELECTs are not a concern. Well, not directly. They do not directly cause buffers to move around. But they can cause a PCM lock to be downgraded from exclusive to shared, thus forcing the instance which had the lock in exclusive-mode to request that it be returned to exclusive. Thus, while the block doesn't leave the Buffer Cache while it's lock is downgraded, it still induces some fiddling back and forth between the instances... INSERTs are a come and see DBA thing (physical design issue). Yes. Prior to 9i, the mechanisms to use are FREELIST GROUPS. Very much eliminates inter-instance contention during INSERTs in OPS... Though I haven't had a chance to play with it yet, the bitmap-oriented 9i replacement for freelists and freelist groups, called automated segment-space mgmt or ASSM, is apparently still only half-baked, purportedly producing all kinds of unexpected results in space wastage and other things. So, in 9iRAC, you might still want to consider using FREELIST GROUPS over ASSM. Again, just my uninformed opinion based on hearsay... DELETEs are relatively infrequent and many get translated into UPDATE (logical as opposed to physical delete). Well, both DELETEs and UPDATEs have the same characteristics from a cache-coherency perspective, so it's six-of-one, half-dozen-the-other... Application partitioning as you clearly explained in your email... Would it be closer to a logical or physical design? I've always tried to use the word segregation as opposed to partitioning, though I slip up occasionally. The word partitioning makes people think about the Partitioning option, which is definitely not intended. There is no relationship between Oracle's Partitioning option and the type of application segregation I'm trying to describe. There are two ways to avoid the latency resulting from OPS pinging or RAC cache-fusion: by happenstance or by planning. Well, actually there are three ways: use OPS/RAC on OpenVMS and neither OPS pinging nor RAC cache-fusion will result in latency. But let's assume that is not an option for you and consider just the other two ways... By happenstance, I mean just hoping that relatively random activity from multiple instances against the same datafiles avoids two (or more) instances wanting the same block for insert, update, or delete. This is pretty rare, but I'm sure it can happen. After all, even a blind dog finds a bone occasionally... By planning, essentially you want your application to somehow enforce that sessions on a database instance only UPDATE or DELETE rows that were INSERTed by that instance. That way, the block buffers are never pinged or cache-fusion shipped to another database instance. There may be some fiddling of the parallel cache-management (PCM) locks if other instances want to read those blocks, but that is less of a concern. So, however your application logic or business practices can ensure that blocks are UPDATEd or DELETEd by the instance from which they were INSERTed, that is what is necessary. Perhaps you can dedicate certain database sessions to specific groups of data (i.e. application module or groups of customers). That doesn't necessarily work all the time; take Oracle Apps as an example, where all application modules inevitably meet in the Application Object Library (AOL) and Foundation (FND) schemas. The surest way I've seen to segregate parts of an application is by making use of data routing capabilities in the middle-tier application-server or transaction-processing monitor layer. If the middle-tier is capable of data-routing, then you can identify each user transaction by the data values and route the transaction to a session connected to one database instance or the other. This is the surest way to accomplish perfect segregation of different database blocks to different instances, when the end-users can't do it. This is usually the case with interactive, OLTP environments. Of course, another way to route transactions is by forcing such rules of application segregation during INSERT, UPDATE, and DELETE by careful data-routing during batch processing. This is the way that it can be implemented for data warehouses... Seems like something that data modeler/architect should be aware of. So in a sense all modeler needs to worry about is UPDATEs as far as future physical implementation for RAC is concerned? Both should be aware, but the decision to include middleware capable of data-routing when designing an OLTP application is usually up to the architect more than the data modeler, I think. Setting up batch processes to perform the data-routing functionality for DW applications is usually up to application developers, I think. The data modeler might have some say
RE: Recipe for application design to run on RAC
No one here [including me !] knows Oracle Names or OID. There's a profusion of TNSNAMES.ORA files for various databases and applications but not Oracle Names. I've been thinking and thinking of Oracle Names for a year and haven't got around to it . [I guess you'll think twice before hiring me as a DBA : ] Hemant At 09:14 AM 27-11-02 -0800, you wrote: The first thing to do is quit using tnsnames.ora on the client PC's. Use Oracle names or Oracle Internet Directory. Jared Hemant K Chitale [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/27/2002 07:28 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:RE: Recipe for application design to run on RAC Hmm. Oracle says that with the improved Cache Fusion in 9i, any current application can be taken as is and run on 9iRAC. But yes, you are right. It really depends on the speed at which the two instances can share the same block and this can never be the same as two sessions accessing the same block in one instance [one SGA]. We are currently running and 8.1.5 OPS [ouch !] environment and testing 9iR2 RAC. The 8.1.5 OPS runs such that the Application Servers [Pro*C servers which get transactions from remote devices through a message bus] all connect to one node and direct PCs using VB/MSQuery connect to the other. Time and again I've asked for the PCs also to connect to the same node but no ... the effort to update the TNSNAMES.ORA and ODBC setup on the PCs would be too much I am told. In 9iRAC we are testing both BASIC and PRECONNECT Failover for TAF and will most certainly be using both nodes of the cluster for transactions. Even the Application Servers will be connecting across both nodes. Cross-fingers, touch-wood and wish me luck ! Hemant At 03:59 PM 26-11-02 -0800, you wrote: If two or more RAC instances will be trying to cache the same data blocks, then this causes the performance problems that you'll see show up as lots of time spent on the event called global cache cr request. If you can partition your application so that RAC nodes don't have to share blocks very often through the cache fusion mechanism, then your system will scale a lot better. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - Hotsos Clinic 101, Jan 7-9 Knoxville - Steve Adams's Miracle Master Class, Jan 13-15 Copenhagen - 2003 Hotsos Symposium, Feb 9-12 Dallas -Original Message- Sent: Tuesday, November 26, 2002 3:34 PM To: Multiple recipients of list ORACLE-L Dear List, Number of times I've seen that one of prerequsites for switching from single node DB to OPS/RAC is to have an application specifically designed / architectured to run on RAC. Can somebody elaborate? Is it something visible on ERD? That is by looking at the model can RAC guru tell that it wouldn't work well on RAC? Or put it another way can one conclude based on the ERD that app was modeled to run on RAC? What's the recepie for app design for RAC? TIA __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Cary Millsap INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Hemant K Chitale My web site page is : http://hkchital.tripod.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hemant K Chitale INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT
RE: Recipe for application design to run on RAC
No. Multiple application servers are for redundancy and load balancing at the ApplicationServer level. Thus, all 4 application servers do the same job and transactions coming in to them are load balanced' by the application. However, all 4 come in to the one database. The idea is to use both nodes of the database server in the same manner as using all 4 application server nodes -- concurrently, instead of keeping one idle. Hemant At 07:59 AM 27-11-02 -0800, you wrote: Couldn't you partitioned your database to accomplish the same thing and thus still be application-independent? - costs $$ licensing but ... -Original Message- From: Hemant K Chitale [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 10:29 AM To: Multiple recipients of list ORACLE-L Subject: RE: Recipe for application design to run on RAC Hmm. Oracle says that with the improved Cache Fusion in 9i, any current application can be taken as is and run on 9iRAC. But yes, you are right. It really depends on the speed at which the two instances can share the same block and this can never be the same as two sessions accessing the same block in one instance [one SGA]. We are currently running and 8.1.5 OPS [ouch !] environment and testing 9iR2 RAC. The 8.1.5 OPS runs such that the Application Servers [Pro*C servers which get transactions from remote devices through a message bus] all connect to one node and direct PCs using VB/MSQuery connect to the other. Time and again I've asked for the PCs also to connect to the same node but no ... the effort to update the TNSNAMES.ORA and ODBC setup on the PCs would be too much I am told. In 9iRAC we are testing both BASIC and PRECONNECT Failover for TAF and will most certainly be using both nodes of the cluster for transactions. Even the Application Servers will be connecting across both nodes. Cross-fingers, touch-wood and wish me luck ! Hemant At 03:59 PM 26-11-02 -0800, you wrote: If two or more RAC instances will be trying to cache the same data blocks, then this causes the performance problems that you'll see show up as lots of time spent on the event called global cache cr request. If you can partition your application so that RAC nodes don't have to share blocks very often through the cache fusion mechanism, then your system will scale a lot better. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - Hotsos Clinic 101, Jan 7-9 Knoxville - Steve Adams's Miracle Master Class, Jan 13-15 Copenhagen - 2003 Hotsos Symposium, Feb 9-12 Dallas -Original Message- Sent: Tuesday, November 26, 2002 3:34 PM To: Multiple recipients of list ORACLE-L Dear List, Number of times I've seen that one of prerequsites for switching from single node DB to OPS/RAC is to have an application specifically designed / architectured to run on RAC. Can somebody elaborate? Is it something visible on ERD? That is by looking at the model can RAC guru tell that it wouldn't work well on RAC? Or put it another way can one conclude based on the ERD that app was modeled to run on RAC? What's the recepie for app design for RAC? TIA __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Cary Millsap INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Hemant K Chitale My web site page is : http://hkchital.tripod.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hemant K Chitale INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services
RE: Recipe for application design to run on RAC
If you're thinking of going ONAMES, consider OID. There are downsides to each, however, that you'll need to consider. 1) There is no mechanism in ONAMES to modify an alias. As per Oracle Support, you'll need to drop and recreate the alias instead. (Or you can modify the repository directly, but that's not encouraged) 2) Replication on OID is one huge PAIN! Because of the way OID works, the two OID DBs are not fully replicated. Instead, it's an AR hack. As of 9.0.1 at least, replication was unstable enough for us to dump OID completely. That and the fact that Oracle Support was of very little help, the documentation is HORRIBLE, and apparently RH 7.1 Linux isn't the best platform for OID 9.0.1. Just some things to consider... Rich Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -Original Message- From: Hemant K Chitale [mailto:[EMAIL PROTECTED]] Sent: Friday, November 29, 2002 9:54 AM To: Multiple recipients of list ORACLE-L Subject: RE: Recipe for application design to run on RAC No one here [including me !] knows Oracle Names or OID. There's a profusion of TNSNAMES.ORA files for various databases and applications but not Oracle Names. I've been thinking and thinking of Oracle Names for a year and haven't got around to it . [I guess you'll think twice before hiring me as a DBA : ] Hemant -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Recipe for application design to run on RAC
To be more precise, the real problems in application-partitioning for OPS/RAC are UPDATE, SELECT ... FOR UPDATE, and DELETE statements due to their WHERE clauses... A SELECT statement does not force exclusive access to a database block and so does not directly cause contention for a block in OPS/RAC. An INSERT statement also does not cause contention on tables because the use of FREELIST GROUPS can keep blocks utilized by different instances separate from one another. If the INSERT is inserting a monotonically-ascending data value into an associated index, then contention on the highest-value leaf block can be reduced by using REVERSE indexes. If the INSERT is not inserting monotonically-ascending data values into any indexes, then contention during parallel cache management between indexes should be minimal. So SELECTs are inherently benign and INSERT operations can be controlled with mechanisms to prevent inter-instance contention for blocks. It is the UPDATE, SELECT ... FOR UPDATE, and DELETE statements which truly require consideration in making an OPS/RAC-based application scaleable. If these statements, which operate on database blocks according to their respective WHERE clauses generated by application logic, do not have some form of awareness of assignment of certain data values to specific database instances, then one can expect problems in scaling. Neither OPS nor RAC has any mechanism to minimize contention between instances for block buffers (as with INSERT statements), so it is up to the application itself (which controls the generation of the WHERE clause) to segregate the application somehow. Whether it is by major application module (i.e. sales and marketing versus order entry and inventory versus general ledger, etc) as Boris had illustrated, or by some other mechanism (i.e. all customers whose names start with A-M on one node, all whose names start with N-Z on the other node, etc), the application must be able to partition. --- In Oracle7 OPS and Oracle8 OPS and Oracle8i OPS, the mechanism (i.e. pinging performed through the I/O subsystem) was quite slow on most platforms, resulting in huge latencies. The major exception to this rule was DEC/Compaq/HP OpenVMS, where the performance of the pinging mechanism is so fast as to be quite unnoticeable. Not surprising if one considers the history of VMS and OpenVMS... Beginning with pieces of the cache-coherency mechanisms in Oracle8i OPS and fully implemented in Oracle9i RAC, the cache-fusion mechanism still performs the same locking and data-transfer of database block buffers between instances, only faster. How much faster is dependent on the OS and configuration. But the additional latency is still there. Obviously, if the inter-connect mechanism between nodes is not fast or misconfigured, then cache-fusion cannot be fast either... --- When Oracle states that applications can be migrated to RAC without modification, they are saying so in the faith that the reduced latencies in the cache-fusion mechanism and other improvements in the sharing/modification of global enqueues will result in almost-zero latency, or at least latency that is within the tolerance of the end-users. As the old saying goes, your mileage may vary or YMMV. As OpenVMS and its near zero-latency pinging mechanism shows, the choice and configuration of platform really matters also! --- In order to assess if an application is likely to scale effectively when migrating from non-RAC to RAC, I would pay close attention the nature, frequency, and volume of UPDATE, SELECT ... FOR UPDATE, and DELETE statements generated by the application. While still in its non-RAC implementation, I would recommend collecting and examining such SQL statements generated by application and understanding what program modules are generating each statement and why. I would then prioritize these statements by their volume and the business criticality of the generating program module. Last, according to this prioritization, I would examine how the WHERE clauses and the data values used in them can be controlled by application logic. For example, if a business-critical online form is generating lots of UPDATE and SELECT ... FOR UPDATE statements, is it possible to determine whether those statements are generated against rows previously INSERTed by the same session? Or, does that online form perform UPDATE and SELECT ... FOR UPDATE operations against any data in the database at all? Some applications are really quite partitionable under the covers, and only a small amount of such analysis can assure you that RAC is feasible. Other applications are so dreadfully complex that only by load-testing with real-world data values can the scalability be determined... Oracle has correctly identified all of the major bottlenecks in inter-instance contention and has improved each of these areas in RAC since OPS. The question is whether the improvements are sufficient for your
RE: Recipe for application design to run on RAC
Hmm. Oracle says that with the improved Cache Fusion in 9i, any current application can be taken as is and run on 9iRAC. But yes, you are right. It really depends on the speed at which the two instances can share the same block and this can never be the same as two sessions accessing the same block in one instance [one SGA]. We are currently running and 8.1.5 OPS [ouch !] environment and testing 9iR2 RAC. The 8.1.5 OPS runs such that the Application Servers [Pro*C servers which get transactions from remote devices through a message bus] all connect to one node and direct PCs using VB/MSQuery connect to the other. Time and again I've asked for the PCs also to connect to the same node but no ... the effort to update the TNSNAMES.ORA and ODBC setup on the PCs would be too much I am told. In 9iRAC we are testing both BASIC and PRECONNECT Failover for TAF and will most certainly be using both nodes of the cluster for transactions. Even the Application Servers will be connecting across both nodes. Cross-fingers, touch-wood and wish me luck ! Hemant At 03:59 PM 26-11-02 -0800, you wrote: If two or more RAC instances will be trying to cache the same data blocks, then this causes the performance problems that you'll see show up as lots of time spent on the event called global cache cr request. If you can partition your application so that RAC nodes don't have to share blocks very often through the cache fusion mechanism, then your system will scale a lot better. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - Hotsos Clinic 101, Jan 7-9 Knoxville - Steve Adams's Miracle Master Class, Jan 13-15 Copenhagen - 2003 Hotsos Symposium, Feb 9-12 Dallas -Original Message- Sent: Tuesday, November 26, 2002 3:34 PM To: Multiple recipients of list ORACLE-L Dear List, Number of times I've seen that one of prerequsites for switching from single node DB to OPS/RAC is to have an application specifically designed / architectured to run on RAC. Can somebody elaborate? Is it something visible on ERD? That is by looking at the model can RAC guru tell that it wouldn't work well on RAC? Or put it another way can one conclude based on the ERD that app was modeled to run on RAC? What's the recepie for app design for RAC? TIA __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Cary Millsap INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Hemant K Chitale My web site page is : http://hkchital.tripod.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hemant K Chitale INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Recipe for application design to run on RAC
Thanks for taking time to reply, Cary. Much appreciated. Did I understand it correctly that in active/active setup it would be beneficial to give each node it's own virtual empire so to speak. Like one node to service say marketing and sales, while the other to deal with say inventory and automation and minimize interdependencies between the two? I was thinking more along the lines of equally distributing/balancing the utilization across the nodes (which presumably makes it easier to re-route db calls to surviving node in case of instance/node failure after remastering, since all nodes are peers) I obviously need to do some serious RTFMing here. So if the key is to have application partitioned (by probably functional/business areas?), is it at the logical design stage that this needs to be accounted for? Assuming enterprise framework in place, like Zachman's (http://www.zifa.com/framework.html) would it be at the system model/logical level (or using Oracle Designer terminology I guess at the system analysis stage) that design for RAC comes to the picture for a first time? Thanks again. --- Cary Millsap [EMAIL PROTECTED] wrote: If two or more RAC instances will be trying to cache the same data blocks, then this causes the performance problems that you'll see show up as lots of time spent on the event called global cache cr request. If you can partition your application so that RAC nodes don't have to share blocks very often through the cache fusion mechanism, then your system will scale a lot better. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - Hotsos Clinic 101, Jan 7-9 Knoxville - Steve Adams's Miracle Master Class, Jan 13-15 Copenhagen - 2003 Hotsos Symposium, Feb 9-12 Dallas -Original Message- Sent: Tuesday, November 26, 2002 3:34 PM To: Multiple recipients of list ORACLE-L Dear List, Number of times I've seen that one of prerequsites for switching from single node DB to OPS/RAC is to have an application specifically designed / architectured to run on RAC. Can somebody elaborate? Is it something visible on ERD? That is by looking at the model can RAC guru tell that it wouldn't work well on RAC? Or put it another way can one conclude based on the ERD that app was modeled to run on RAC? What's the recepie for app design for RAC? TIA __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Cary Millsap INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Recipe for application design to run on RAC
Title: RE: Recipe for application design to run on RAC Couldn't you partitioned your database to accomplish the same thing and thus still be application-independent? - costs $$ licensing but ... -Original Message- From: Hemant K Chitale [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 10:29 AM To: Multiple recipients of list ORACLE-L Subject: RE: Recipe for application design to run on RAC Hmm. Oracle says that with the improved Cache Fusion in 9i, any current application can be taken as is and run on 9iRAC. But yes, you are right. It really depends on the speed at which the two instances can share the same block and this can never be the same as two sessions accessing the same block in one instance [one SGA]. We are currently running and 8.1.5 OPS [ouch !] environment and testing 9iR2 RAC. The 8.1.5 OPS runs such that the Application Servers [Pro*C servers which get transactions from remote devices through a message bus] all connect to one node and direct PCs using VB/MSQuery connect to the other. Time and again I've asked for the PCs also to connect to the same node but no ... the effort to update the TNSNAMES.ORA and ODBC setup on the PCs would be too much I am told. In 9iRAC we are testing both BASIC and PRECONNECT Failover for TAF and will most certainly be using both nodes of the cluster for transactions. Even the Application Servers will be connecting across both nodes. Cross-fingers, touch-wood and wish me luck ! Hemant At 03:59 PM 26-11-02 -0800, you wrote: If two or more RAC instances will be trying to cache the same data blocks, then this causes the performance problems that you'll see show up as lots of time spent on the event called global cache cr request. If you can partition your application so that RAC nodes don't have to share blocks very often through the cache fusion mechanism, then your system will scale a lot better. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - Hotsos Clinic 101, Jan 7-9 Knoxville - Steve Adams's Miracle Master Class, Jan 13-15 Copenhagen - 2003 Hotsos Symposium, Feb 9-12 Dallas -Original Message- Sent: Tuesday, November 26, 2002 3:34 PM To: Multiple recipients of list ORACLE-L Dear List, Number of times I've seen that one of prerequsites for switching from single node DB to OPS/RAC is to have an application specifically designed / architectured to run on RAC. Can somebody elaborate? Is it something visible on ERD? That is by looking at the model can RAC guru tell that it wouldn't work well on RAC? Or put it another way can one conclude based on the ERD that app was modeled to run on RAC? What's the recepie for app design for RAC? TIA __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Cary Millsap INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Hemant K Chitale My web site page is : http://hkchital.tripod.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hemant K Chitale INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Recipe for application design to run on RAC
The first thing to do is quit using tnsnames.ora on the client PC's. Use Oracle names or Oracle Internet Directory. Jared Hemant K Chitale [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/27/2002 07:28 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:RE: Recipe for application design to run on RAC Hmm. Oracle says that with the improved Cache Fusion in 9i, any current application can be taken as is and run on 9iRAC. But yes, you are right. It really depends on the speed at which the two instances can share the same block and this can never be the same as two sessions accessing the same block in one instance [one SGA]. We are currently running and 8.1.5 OPS [ouch !] environment and testing 9iR2 RAC. The 8.1.5 OPS runs such that the Application Servers [Pro*C servers which get transactions from remote devices through a message bus] all connect to one node and direct PCs using VB/MSQuery connect to the other. Time and again I've asked for the PCs also to connect to the same node but no ... the effort to update the TNSNAMES.ORA and ODBC setup on the PCs would be too much I am told. In 9iRAC we are testing both BASIC and PRECONNECT Failover for TAF and will most certainly be using both nodes of the cluster for transactions. Even the Application Servers will be connecting across both nodes. Cross-fingers, touch-wood and wish me luck ! Hemant At 03:59 PM 26-11-02 -0800, you wrote: If two or more RAC instances will be trying to cache the same data blocks, then this causes the performance problems that you'll see show up as lots of time spent on the event called global cache cr request. If you can partition your application so that RAC nodes don't have to share blocks very often through the cache fusion mechanism, then your system will scale a lot better. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - Hotsos Clinic 101, Jan 7-9 Knoxville - Steve Adams's Miracle Master Class, Jan 13-15 Copenhagen - 2003 Hotsos Symposium, Feb 9-12 Dallas -Original Message- Sent: Tuesday, November 26, 2002 3:34 PM To: Multiple recipients of list ORACLE-L Dear List, Number of times I've seen that one of prerequsites for switching from single node DB to OPS/RAC is to have an application specifically designed / architectured to run on RAC. Can somebody elaborate? Is it something visible on ERD? That is by looking at the model can RAC guru tell that it wouldn't work well on RAC? Or put it another way can one conclude based on the ERD that app was modeled to run on RAC? What's the recepie for app design for RAC? TIA __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Cary Millsap INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Hemant K Chitale My web site page is : http://hkchital.tripod.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hemant K Chitale INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network
RE: Recipe for application design to run on RAC
If two or more RAC instances will be trying to cache the same data blocks, then this causes the performance problems that you'll see show up as lots of time spent on the event called global cache cr request. If you can partition your application so that RAC nodes don't have to share blocks very often through the cache fusion mechanism, then your system will scale a lot better. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Dec 9-11 Honolulu - Hotsos Clinic 101, Jan 7-9 Knoxville - Steve Adams's Miracle Master Class, Jan 13-15 Copenhagen - 2003 Hotsos Symposium, Feb 9-12 Dallas -Original Message- Sent: Tuesday, November 26, 2002 3:34 PM To: Multiple recipients of list ORACLE-L Dear List, Number of times I've seen that one of prerequsites for switching from single node DB to OPS/RAC is to have an application specifically designed / architectured to run on RAC. Can somebody elaborate? Is it something visible on ERD? That is by looking at the model can RAC guru tell that it wouldn't work well on RAC? Or put it another way can one conclude based on the ERD that app was modeled to run on RAC? What's the recepie for app design for RAC? TIA __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Cary Millsap INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
