RE: Re: 24 x 7 x 365
Tanel, There's a whole boatload of race conditions in that sort of replication architecture. As murali has pointed out, single-side commits create manual rollback situations - plus what happens when both transactions succeed, but in the delay between the two commits one side begins operating on a just-changed record And then the last problem situation is invalidating one side of the database when a link goes down - how do you bring it back into sync? Do you journal transactions? Thanks, Matt -- Matthew Zito GridApp Systems Email: [EMAIL PROTECTED] Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.com > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Tanel Poder > Sent: Monday, December 15, 2003 6:29 AM > To: Multiple recipients of list ORACLE-L > Subject: Re: Re: 24 x 7 x 365 > > > Jonathan, > Thanks for this valuable information. > However, I'm using regular commits, not "distributed" > two-phased ones and I just have simple code to handle the > situation where servers return different success/error codes. > > Tanel. > > > > > > There is a problem with this approach > > that may only become apparent at high > > concurrency. > > > > Since you are operating with two-phase > > commits, you may come up against the case > > where "writers block readers". > > > > Your client issues a commit to both servers. > > Each server get the PREPARE message, > > and when both have responded, each gets > > the COMMIT message. > > > > Between the PREPARE and COMMIT, > > any blocks updated in the transaction > > cease to be available to ANY query > > that started after the PREPARE arrived. > > > > For the (hopefully) brief interval between > > the prepare and commit, neither database > > knows whether the transaction as a whole > > has prepared or committed, so any process > > that wants to see the current version of the > > data has to wait until there is a known current > > version. > > > > In a high-concurrency system, a problem > > that used to be "buffer busy waits" on updates > > only can turn into enqueue waits on updates > > and queries. > > > > Regards > > > > Jonathan Lewis > > http://www.jlcomp.demon.co.uk > > > > The educated person is not the person > > who can answer the questions, but the > > person who can question the answers -- T. Schick Jr > > > > > > One-day tutorials: http://www.jlcomp.demon.co.uk/tutorial.html > > > > > > Three-day seminar: > > see http://www.jlcomp.demon.co.uk/seminar.html > > UK___November > > > > > > The Co-operative Oracle Users' FAQ > > http://www.jlcomp.demon.co.uk/faq/ind_faq.html > > > > > > - Original Message - > > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > > Sent: Saturday, December 13, 2003 8:19 PM > > > > > > Yep, I also think so. I'm currently developing a small > prototype for this > > kind of transparent proxy, which I'll post here when it's stable... > > > > Tanel. > > > > > Tanel, > > > > > > I think this is a good solution, provided the application > can handle > > > two phased commit protocol across both the databases, else there > > > could be orphan records on one or both these databases. > > > > > > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Jonathan Lewis > > 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.net > -- > Author: Tanel Poder > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > -
Re: Re: 24 x 7 x 365
Tanel, If this is the approach, then quite a bit of code would have to be developed on the front end to handle transaction integrity. For example when one fails and the other has completed the write successfully, they will have to be physically removed. What about if the record that is commited was already read by another session. Basically avoiding any orphan records or avoiding data reconciliation between the two. I also agree with Jonathan, while two phased approach is used for such kind of activities, there could be tremendous overhead depending on how intensive the transaction rates are. Murali Tanel Poder <[EMAIL PROTECTED]> wrote: Jonathan,Thanks for this valuable information.However, I'm using regular commits, not "distributed" two-phased ones and Ijust have simple code to handle the situation where servers return differentsuccess/error codes.Tanel.>> There is a problem with this approach> that may only become apparent at high> concurrency.>> Since you are operating with two-phase> commits, you may come up against the case> where "writers block readers".>> Your client issues a commit to both servers.> Each server get the PREPARE message,> and when both have responded, each gets> the COMMIT message.>> Between the PREPARE and COMMIT,> any blocks updated in the transaction> cease to be available to ANY query> that started after the PREPARE arrived.>> For the (hopefully) brief interval between> the prepare and commit, neither database> knows whether the transaction as a whole> has prepared or committed, so any process> that wants to see the current version of the> data has to wait until there is a known current> version.>> In a high-concurrency system, a problem> that used to be "buffer busy waits" on updates> only can turn into enqueue waits on updates> and queries.>> Regards>> Jonathan Lewis> http://www.jlcomp.demon.co.uk>> The educated person is not the person> who can answer the questions, but the> person who can question the answers -- T. Schick Jr>>> One-day tutorials:> http://www.jlcomp.demon.co.uk/tutorial.html>>> Three-day seminar:> see http://www.jlcomp.demon.co.uk/seminar.html> UK___November>>> The Co-operative Oracle Users' FAQ> http://www.jlcomp.demon.co.uk/faq/ind_faq.html>>> - Original Message - > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>> Sent: Saturday, December 13, 2003 8:19 PM>>> Yep, I also think so. I'm currently developing a small prototype for this> kind of transparent proxy, which I'll post here when it's stable...>> Tanel.>> > Tanel,> >> > I think this is a good solution, provided the application can handle> > two phased commit protocol across both the databases, else there> > could be orphan records on one or both these databases.> >>> -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net> -- > Author: Jonathan Lewis> 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.net-- Author: Tanel PoderINET: [EMAIL PROTECTED]Fat City Network Services -- 858-538-5051 http://www.fatcity.comSan Diego, California -- Mailing list and web hosting services-To REMOVE yourself from this mailing list, send an E-Mail messageto: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and inthe message BODY, include a line containing: UNSUB ORACLE-L(or the name of mailing list you want to be removed from). You mayalso send the HELP command for other information (like subscribing). Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing
Re: Re: 24 x 7 x 365
Jonathan, Thanks for this valuable information. However, I'm using regular commits, not "distributed" two-phased ones and I just have simple code to handle the situation where servers return different success/error codes. Tanel. > > There is a problem with this approach > that may only become apparent at high > concurrency. > > Since you are operating with two-phase > commits, you may come up against the case > where "writers block readers". > > Your client issues a commit to both servers. > Each server get the PREPARE message, > and when both have responded, each gets > the COMMIT message. > > Between the PREPARE and COMMIT, > any blocks updated in the transaction > cease to be available to ANY query > that started after the PREPARE arrived. > > For the (hopefully) brief interval between > the prepare and commit, neither database > knows whether the transaction as a whole > has prepared or committed, so any process > that wants to see the current version of the > data has to wait until there is a known current > version. > > In a high-concurrency system, a problem > that used to be "buffer busy waits" on updates > only can turn into enqueue waits on updates > and queries. > > Regards > > Jonathan Lewis > http://www.jlcomp.demon.co.uk > > The educated person is not the person > who can answer the questions, but the > person who can question the answers -- T. Schick Jr > > > One-day tutorials: > http://www.jlcomp.demon.co.uk/tutorial.html > > > Three-day seminar: > see http://www.jlcomp.demon.co.uk/seminar.html > UK___November > > > The Co-operative Oracle Users' FAQ > http://www.jlcomp.demon.co.uk/faq/ind_faq.html > > > - Original Message - > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Saturday, December 13, 2003 8:19 PM > > > Yep, I also think so. I'm currently developing a small prototype for this > kind of transparent proxy, which I'll post here when it's stable... > > Tanel. > > > Tanel, > > > > I think this is a good solution, provided the application can handle > > two phased commit protocol across both the databases, else there > > could be orphan records on one or both these databases. > > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Jonathan Lewis > 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.net -- Author: Tanel Poder 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: Re: 24 x 7 x 365
There is a problem with this approach that may only become apparent at high concurrency. Since you are operating with two-phase commits, you may come up against the case where "writers block readers". Your client issues a commit to both servers. Each server get the PREPARE message, and when both have responded, each gets the COMMIT message. Between the PREPARE and COMMIT, any blocks updated in the transaction cease to be available to ANY query that started after the PREPARE arrived. For the (hopefully) brief interval between the prepare and commit, neither database knows whether the transaction as a whole has prepared or committed, so any process that wants to see the current version of the data has to wait until there is a known current version. In a high-concurrency system, a problem that used to be "buffer busy waits" on updates only can turn into enqueue waits on updates and queries. Regards Jonathan Lewis http://www.jlcomp.demon.co.uk The educated person is not the person who can answer the questions, but the person who can question the answers -- T. Schick Jr One-day tutorials: http://www.jlcomp.demon.co.uk/tutorial.html Three-day seminar: see http://www.jlcomp.demon.co.uk/seminar.html UK___November The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Saturday, December 13, 2003 8:19 PM Yep, I also think so. I'm currently developing a small prototype for this kind of transparent proxy, which I'll post here when it's stable... Tanel. > Tanel, > > I think this is a good solution, provided the application can handle > two phased commit protocol across both the databases, else there > could be orphan records on one or both these databases. > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis 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: Re: 24 x 7 x 365
Yep, I also think so. I'm currently developing a small prototype for this kind of transparent proxy, which I'll post here when it's stable... Tanel. > Tanel, > > I think this is a good solution, provided the application can handle > two phased commit protocol across both the databases, else there > could be orphan records on one or both these databases. > > Murali Tanel Poder <[EMAIL PROTECTED]> wrote: > When you want true 24x7 without compromises, then you have to step > closer tothe client anyway.This means, you have two databases for > example and your app servermultiplexes all transactions to both > ones.This should be faster than sync standby or sync replication, > because appserver can send requests to both databases in parallel, > unlike withstandby/replication where database itself resends the > requests to otherdatabases, making the "chain" of changes > longer.Tanel.- Original Message - To: "Multiple recipients of > list ORACLE-L" Sent: Wednesday, December 10, 2003 11:24 PM> Hi,>> > Unfortunately I'm gonig to add the negative view, like several > others> have...>> True 24x7x365 (good pick-up Pete on the 7 year > thing) will! > be > limited by> much more than database and operating system > availability. We just did a> major software upgrade last weekend and > part of the upgrade involved the> conversion of 250+ million records > in the database - that takes time no> matter what. Yes, with > unlimited budget and time constraints we could get> the outage down > to nothing but at the end of the day it's easier for the> business to > manage an outage.>> Our system was offline for a total of about 10 > hours yet traffic drives on> our tollroad all the time so: The > roadside is designed to backlog> transactions for several days, our > system has capacity to catch upbacklogs> fairly fast (within a day we > had caught up again), we have an alternative> front-end system that > can backlog feeds, and finally we designed our> conversion process to > do as much as possible before the outage.>> We are also on 8.1.7 > enterprise and! > don't > use OPS/RAC - instead we havethe> alternative processes in place to > ensure the business can function.> Perhaps your company can consider > a similar alternative? As others have> said - it can be VERY > difficult to remove every possible outage and it can> be much easier > to manage a small outage every few months.>> Regards,> Mark.> > "Tracy Rahmlow"> !
Re: 24 x 7 x 365
i was just in the bookstore. are you the one who wrote the new RAC book? you do realize the whole thing word for word is in a .pdf on otn? - Original Message - From: Murali Vallath To: Multiple recipients of list ORACLE-L Sent: Saturday, December 13, 2003 10:09 AM Subject: Re: 24 x 7 x 365 If this is the customer you are talking about, this database supports over 12 million subscribers.. Murali Tim Gorman <[EMAIL PROTECTED]> wrote: As I mentioned a few minutes ago in another thread, there is an application using Oracle Rdb on an HP OpenVMS cluster located at HP in Colorado Springs that has been up and available continuously for the past 11-12 years.on 12/10/03 2:49 PM, Goulet, Dick at [EMAIL PROTECTED] wrote: True 24x365 is just about impossible. No if, ands. or buts about it. Why is because of the number of factors outside your control that affect system availability. Sure your web sever and database are up 24x365, but your ISP has 1 hour down time each month for maintenance. OOPS!! from a customer point of view your NOT 24x365. Also that fiber optic cable running out of your building to the phone pole is available for some heavy equipment operator to slice through while working on the sewer system, OOPS!! So you can't have 24x365 no matter what. What you should do is try to adapt the changes you need into the downtime that's imposed on you. That's what we do & it works very nicely.Besides being completely redundant is extremely expensive, like two of everything, including building, air-conditioning, fiber ! optic cables, etc.Dick GouletSenior Oracle DBAOracle Certified 8i DBA -Original Message-From: Tracy Rahmlow [mailto:[EMAIL PROTECTED]Sent: Wednesday, December 10, 2003 11:44 AMTo: Multiple recipients of list ORACLE-LSubject: 24 x 7 x 365Hello, Our company would like to know whether or not Oracle supports true 24x7x365 availability for an oltp database. We currently are using the 8.1.7 enterprise edition. Does an architecture exist whereby we can upgrade the database and/or operating system and not cause an outage? Will RAC solve this issue? Are there any other areas of concerns that I should be thinking about? For example, analyzing with the validate clause and its impacts on the transaction system. Thanks American Express made the followingannotations on 12/10/2003 09:41:15 AM--**"This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you."**== Murali Vallath Author: Oracle Real Application Clusters Publisher Digital Press http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=2V5D30UGVS&isbn=182885&itm=4#PU Do you Yahoo!?New Yahoo! Photos - easier uploading and sharing
Re: 24 x 7 x 365
If this is the customer you are talking about, this database supports over 12 million subscribers.. Murali Tim Gorman <[EMAIL PROTECTED]> wrote: As I mentioned a few minutes ago in another thread, there is an application using Oracle Rdb on an HP OpenVMS cluster located at HP in Colorado Springs that has been up and available continuously for the past 11-12 years.on 12/10/03 2:49 PM, Goulet, Dick at [EMAIL PROTECTED] wrote: True 24x365 is just about impossible. No if, ands. or buts about it. Why is because of the number of factors outside your control that affect system availability. Sure your web sever and database are up 24x365, but your ISP has 1 hour down time each month for maintenance. OOPS!! from a customer point of view your NOT 24x365. Also that fiber optic cable running out of your building to the phone pole is available for some heavy equipment operator to slice through while working on the sewer system, OOPS!! So you can't have 24x365 no matter what. What you should do is try to adapt the changes you need into the downtime that's imposed on you. That's what we do & it works very nicely.Besides being completely redundant is extremely expensive, like two of everything, including building, air-conditioning, fiber ! optic cables, etc.Dick GouletSenior Oracle DBAOracle Certified 8i DBA -Original Message-From: Tracy Rahmlow [mailto:[EMAIL PROTECTED]Sent: Wednesday, December 10, 2003 11:44 AMTo: Multiple recipients of list ORACLE-LSubject: 24 x 7 x 365Hello, Our company would like to know whether or not Oracle supports true 24x7x365 availability for an oltp database. We currently are using the 8.1.7 enterprise edition. Does an architecture exist whereby we can upgrade the database and/or operating system and not cause an outage? Will RAC solve this issue? Are there any other areas of concerns that I should be thinking about? For example, analyzing with the validate clause and its impacts on the transaction system. Thanks American Express made the followingannotations on 12/10/2003 09:41:15 AM--**"This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you."**== Murali Vallath Author: Oracle Real Application Clusters Publisher Digital Press http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=2V5D30UGVS&isbn=182885&itm=4#PU Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing
Re: 24 x 7 x 365
Tanel, I think this is a good solution, provided the application can handle two phased commit protocol across both the databases, else there could be orphan records on one or both these databases. Murali Tanel Poder <[EMAIL PROTECTED]> wrote: When you want true 24x7 without compromises, then you have to step closer tothe client anyway.This means, you have two databases for example and your app servermultiplexes all transactions to both ones.This should be faster than sync standby or sync replication, because appserver can send requests to both databases in parallel, unlike withstandby/replication where database itself resends the requests to otherdatabases, making the "chain" of changes longer.Tanel.- Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>Sent: Wednesday, December 10, 2003 11:24 PM> Hi,>> Unfortunately I'm gonig to add the negative view, like several others> have...>> True 24x7x365 (good pick-up Pete on the 7 year thing) will! be limited by> much more than database and operating system availability. We just did a> major software upgrade last weekend and part of the upgrade involved the> conversion of 250+ million records in the database - that takes time no> matter what. Yes, with unlimited budget and time constraints we could get> the outage down to nothing but at the end of the day it's easier for the> business to manage an outage.>> Our system was offline for a total of about 10 hours yet traffic drives on> our tollroad all the time so: The roadside is designed to backlog> transactions for several days, our system has capacity to catch upbacklogs> fairly fast (within a day we had caught up again), we have an alternative> front-end system that can backlog feeds, and finally we designed our> conversion process to do as much as possible before the outage.>> We are also on 8.1.7 enterprise and! don't use OPS/RAC - instead we havethe> alternative processes in place to ensure the business can function.> Perhaps your company can consider a similar alternative? As others have> said - it can be VERY difficult to remove every possible outage and it can> be much easier to manage a small outage every few months.>> Regards,> Mark.> "Tracy Rahmlow"> <[EMAIL PROTECTED] Multiplerecipients of list ORACLE-L <[EMAIL PROTECTED]>> xp.com> cc:> Sent by: Subject: 24 x 7 x 365> [EMAIL PROTECTED]> .com>>> 11/12/2003 03:44> Please respond to> ORACLE-L Hello,> Our company would like to know whether or not Oracle supports true24x7x365> availability for an oltp database. We currently are using the 8.1.7> enterprise edition. Does an architecture exist whereby we can upgrade the> database and/or operating system and not cause an outage? Will RAC solve> this issue? Are there any other areas of concerns that I should be> thinking about? For example, analyzing with the validate clause and its> impacts on the transaction system. Thanks>>> American Express made the following> annotations on 12/10/2003 09:41:15 AM> -->>**>>> "This message and any attachments are solely for the intended recipientand> may contain confidential or privileged information. If you are not the> intended recipient, any disclosure, copying, use, or distribution of the> information included in this message and any attachments is prohibited. If> you! have received this communication in error, please notify us by reply> e-mail and immediately and permanently delete this message and any> attachments. Thank you.">>**==><<>>> Privileged/Confidential information may be contained in this message.> If you are not the address! ee indicated in this message (or responsible fordelivery of the message to such person), you may not copy or deliver thismessage to anyone.> In such a case, you should destroy this message and kindly notify thesender by reply e-mail or by telephone on (03) 9612-6999 or (61) 39612-6999.> Please advise immediately if you or your employer does not consent toInternet e-mail for messages of this kind.> Opinions, conclusions and other information in this message that do notrelate to the official business of Transurban Infrastructure DevelopmentsLimited and CityLink Melbourne Limited shall be understood as neither givennor endorsed by them.><< -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net> -- > Author: Mark Richard> INET: [EMAIL PROTECTED]>> Fat City Network Services -- 858-538-5051 http://www.fatcity.com> San Diego, California -- Mailing list and web h
Re: 24 x 7 x 365
Title: Re: 24 x 7 x 365 As I mentioned a few minutes ago in another thread, there is an application using Oracle Rdb on an HP OpenVMS cluster located at HP in Colorado Springs that has been up and available continuously for the past 11-12 years. on 12/10/03 2:49 PM, Goulet, Dick at [EMAIL PROTECTED] wrote: True 24x365 is just about impossible. No if, ands. or buts about it. Why is because of the number of factors outside your control that affect system availability. Sure your web sever and database are up 24x365, but your ISP has 1 hour down time each month for maintenance. OOPS!! from a customer point of view your NOT 24x365. Also that fiber optic cable running out of your building to the phone pole is available for some heavy equipment operator to slice through while working on the sewer system, OOPS!! So you can't have 24x365 no matter what. What you should do is try to adapt the changes you need into the downtime that's imposed on you. That's what we do & it works very nicely. Besides being completely redundant is extremely expensive, like two of everything, including building, air-conditioning, fiber optic cables, etc. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -Original Message- From: Tracy Rahmlow [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2003 11:44 AM To: Multiple recipients of list ORACLE-L Subject: 24 x 7 x 365 Hello, Our company would like to know whether or not Oracle supports true 24x7x365 availability for an oltp database. We currently are using the 8.1.7 enterprise edition. Does an architecture exist whereby we can upgrade the database and/or operating system and not cause an outage? Will RAC solve this issue? Are there any other areas of concerns that I should be thinking about? For example, analyzing with the validate clause and its impacts on the transaction system. Thanks American Express made the following annotations on 12/10/2003 09:41:15 AM -- ** "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." ** ==
Re: 24 x 7 x 365
When you want true 24x7 without compromises, then you have to step closer to the client anyway. This means, you have two databases for example and your app server multiplexes all transactions to both ones. This should be faster than sync standby or sync replication, because app server can send requests to both databases in parallel, unlike with standby/replication where database itself resends the requests to other databases, making the "chain" of changes longer. Tanel. - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Wednesday, December 10, 2003 11:24 PM > > > > > Hi, > > Unfortunately I'm gonig to add the negative view, like several others > have... > > True 24x7x365 (good pick-up Pete on the 7 year thing) will be limited by > much more than database and operating system availability. We just did a > major software upgrade last weekend and part of the upgrade involved the > conversion of 250+ million records in the database - that takes time no > matter what. Yes, with unlimited budget and time constraints we could get > the outage down to nothing but at the end of the day it's easier for the > business to manage an outage. > > Our system was offline for a total of about 10 hours yet traffic drives on > our tollroad all the time so: The roadside is designed to backlog > transactions for several days, our system has capacity to catch up backlogs > fairly fast (within a day we had caught up again), we have an alternative > front-end system that can backlog feeds, and finally we designed our > conversion process to do as much as possible before the outage. > > We are also on 8.1.7 enterprise and don't use OPS/RAC - instead we have the > alternative processes in place to ensure the business can function. > Perhaps your company can consider a similar alternative? As others have > said - it can be VERY difficult to remove every possible outage and it can > be much easier to manage a small outage every few months. > > Regards, > Mark. > > > > > "Tracy Rahmlow" > <[EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > xp.com> cc: > Sent by: Subject: 24 x 7 x 365 > [EMAIL PROTECTED] > .com > > > 11/12/2003 03:44 > Please respond to > ORACLE-L > > > > > > > > Hello, > Our company would like to know whether or not Oracle supports true 24x7x365 > availability for an oltp database. We currently are using the 8.1.7 > enterprise edition. Does an architecture exist whereby we can upgrade the > database and/or operating system and not cause an outage? Will RAC solve > this issue? Are there any other areas of concerns that I should be > thinking about? For example, analyzing with the validate clause and its > impacts on the transaction system. Thanks > > > American Express made the following > annotations on 12/10/2003 09:41:15 AM > -- > > ** > > > "This message and any attachments are solely for the intended recipient and > may contain confidential or privileged information. If you are not the > intended recipient, any disclosure, copying, use, or distribution of the > information included in this message and any attachments is prohibited. If > you have received this communication in error, please notify us by reply > e-mail and immediately and permanently delete this message and any > attachments. Thank you." > > ** > > > > == > > > > > > > > > <<>> > Privileged/Confidential information may be contained in this message. > If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. > In such a case, you should destroy this message and kindly notify the sender by reply e-mail or by telephone on (03) 9612-6999 or (61) 3 9612-6999. > Please advise immediately if you or your employer does not consent to Internet e-mail for messages of this kind. > Opinions, conclusions and other information in this message that do not relate to the official business of Transurban Infrastructure Developments Limited and CityLink Melbourne Limited shall be understood as neither given nor endorsed by them. > <<>> > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Mark
RE: 24 x 7 x 365
True 24x365 is just about impossible. No if, ands. or buts about it. Why is because of the number of factors outside your control that affect system availability. Sure your web sever and database are up 24x365, but your ISP has 1 hour down time each month for maintenance. OOPS!! from a customer point of view your NOT 24x365. Also that fiber optic cable running out of your building to the phone pole is available for some heavy equipment operator to slice through while working on the sewer system, OOPS!! So you can't have 24x365 no matter what. What you should do is try to adapt the changes you need into the downtime that's imposed on you. That's what we do & it works very nicely. Besides being completely redundant is extremely expensive, like two of everything, including building, air-conditioning, fiber optic cables, etc. Dick GouletSenior Oracle DBAOracle Certified 8i DBA -Original Message-From: Tracy Rahmlow [mailto:[EMAIL PROTECTED]Sent: Wednesday, December 10, 2003 11:44 AMTo: Multiple recipients of list ORACLE-LSubject: 24 x 7 x 365Hello, Our company would like to know whether or not Oracle supports true 24x7x365 availability for an oltp database. We currently are using the 8.1.7 enterprise edition. Does an architecture exist whereby we can upgrade the database and/or operating system and not cause an outage? Will RAC solve this issue? Are there any other areas of concerns that I should be thinking about? For example, analyzing with the validate clause and its impacts on the transaction system. Thanks American Express made the followingannotations on 12/10/2003 09:41:15 AM--**"This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you."**==
Re: 24 x 7 x 365
Hi, Unfortunately I'm gonig to add the negative view, like several others have... True 24x7x365 (good pick-up Pete on the 7 year thing) will be limited by much more than database and operating system availability. We just did a major software upgrade last weekend and part of the upgrade involved the conversion of 250+ million records in the database - that takes time no matter what. Yes, with unlimited budget and time constraints we could get the outage down to nothing but at the end of the day it's easier for the business to manage an outage. Our system was offline for a total of about 10 hours yet traffic drives on our tollroad all the time so: The roadside is designed to backlog transactions for several days, our system has capacity to catch up backlogs fairly fast (within a day we had caught up again), we have an alternative front-end system that can backlog feeds, and finally we designed our conversion process to do as much as possible before the outage. We are also on 8.1.7 enterprise and don't use OPS/RAC - instead we have the alternative processes in place to ensure the business can function. Perhaps your company can consider a similar alternative? As others have said - it can be VERY difficult to remove every possible outage and it can be much easier to manage a small outage every few months. Regards, Mark. "Tracy Rahmlow" <[EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> xp.com> cc: Sent by: Subject: 24 x 7 x 365 [EMAIL PROTECTED] .com 11/12/2003 03:44 Please respond to ORACLE-L Hello, Our company would like to know whether or not Oracle supports true 24x7x365 availability for an oltp database. We currently are using the 8.1.7 enterprise edition. Does an architecture exist whereby we can upgrade the database and/or operating system and not cause an outage? Will RAC solve this issue? Are there any other areas of concerns that I should be thinking about? For example, analyzing with the validate clause and its impacts on the transaction system. Thanks American Express made the following annotations on 12/10/2003 09:41:15 AM -- ** "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." ** == <<>> Privileged/Confidential information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such a case, you should destroy t
Re: 24 x 7 x 365
Tracy, both OPS (8i) and RAC (9i)support independent node shutdown. Both support listener based load balancing so that incoming connections will be evenly spread on all nodes. That still doesn't give you the true 24 x 7 x 365 availability. For that, you need two replicated copies of the database, both in OPS/RAC mode. The problem with a single OPS/RAC database is that it has to be shut down for the database upgrade. You cannot have both 8i and 9i instances accessing the same database at the same time, which means that in the case of the database upgrade, all databases in the cluster must be brought down. The only way for production database to remain available after all clustered instances have been brought down is the existence of another copy of your production database, on separate cluster. It is foreseeable that there will be some data discrepancies after the primary configuration is upgraded and brought back online, which means that you must have symmetric replication set up in such a way that your instances can be quickly synchronized. Please, be aware that both configurations, the primary and secondary one must be clustered, because if the secondary database is not clustered, then the instance accessing it becomes the single point of failure, which is what needs to be avoided at all costs. Also, you may decide to limit the meaning of "24 x 7 x 365 availability" and decide that the spare configuration will be available in read-only mode while you are upgrading the primary configuration. That would be the case for a physical standby and playing with EMC BCV-s. In that case, you do not need to set up symmetric replication, because there are no data changes (database is in the read-only mode) but the guys doing upgrade are limited by the time that business may tolerate the database being in the read-only mode. Given the organization you work for, I surmise that a) your database is larger then 10MB and b) that you need it to be fully accessible to the fullest extent of the "24 x 7 x 365" phrase. That probably means that having read-only database for the full two hours is not acceptable. You will need replication. Those two databases should be physically separated in case of catastrophic failure (things that never happen, like big power-grid blackouts, passenger jets crashing into skyscrapers or forest wildfires scorching suburb or two of a major urban area). Of course, network connections must be redundant as well. That would be the true "24 x 7 x 365 availability", but the price tag is really a major number, much more then most companies are willing to spend. Given all the infrastructure and real estate, the price tag probably comes close to 8 zeros range, which is probably what those guys that were hand-picked to test 10g make annually. On 12/10/2003 11:44:25 AM, Tracy Rahmlow wrote: > Hello, > Our company would like to know whether or not Oracle supports true > 24x7x365 availability for an oltp database. We currently are using the > 8.1.7 enterprise edition. Does an architecture exist whereby we can > upgrade the database and/or operating system and not cause an outage? Will > RAC solve this issue? Are there any other areas of concerns that I should > be thinking about? For example, analyzing with the validate clause and > its impacts on the transaction system. Thanks > American Express made the following > annotations on 12/10/2003 09:41:15 AM > -- > ** > > "This message and any attachments are solely for the intended recipient and may > contain confidential or privileged information. If you are not the intended > recipient, any disclosure, copying, use, or distribution of the information included > in this message and any attachments is prohibited. If you have received this > communication in error, please notify us by reply e-mail and immediately and > permanently delete this message and any attachments. Thank you." > > ** > > > == > Mladen Gogala Oracle DBA Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual
Re: 24 x 7 x 365
i was at an oracle group meeting and one of the RAC specialists at oracle was talking. he said that that kind of thing 'can' be done, but is incredibly expensive. you need redundancy and fail safes like crazy. any time you do an upgrade, bad things may happen. > > From: "Tracy Rahmlow" <[EMAIL PROTECTED]> > Date: 2003/12/10 Wed AM 11:44:25 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Subject: 24 x 7 x 365 > > Hello, > Our company would like to know whether or not Oracle supports true > 24x7x365 availability for an oltp database. We currently are using the > 8.1.7 enterprise edition. Does an architecture exist whereby we can > upgrade the database and/or operating system and not cause an outage? Will > RAC solve this issue? Are there any other areas of concerns that I should > be thinking about? For example, analyzing with the validate clause and > its impacts on the transaction system. Thanks > American Express made the following > annotations on 12/10/2003 09:41:15 AM > -- > ** > > "This message and any attachments are solely for the intended recipient and may > contain confidential or privileged information. If you are not the intended > recipient, any disclosure, copying, use, or distribution of the information included > in this message and any attachments is prohibited. If you have received this > communication in error, please notify us by reply e-mail and immediately and > permanently delete this message and any attachments. Thank you." > > ** > > > == > > Hello, Our company would like to know whether or not Oracle supports true 24x7x365 availability for an oltp database. We currently are using the 8.1.7 enterprise edition. Does an architecture exist whereby we can upgrade the database and/or operating system and not cause an outage? Will RAC solve this issue? Are there any other areas of concerns that I should be thinking about? For example, analyzing with the validate clause and its impacts on the transaction system. Thanks American Express made the following annotations on 12/10/2003 09:41:15 AM -- ** "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." ** ==
Re: 24 x 7 x 365
You mean 2004/02/31, the 31st of February? On 12/10/2003 02:19:34 PM, Whittle Jerome Contr NCI wrote: > As 2004 is a Leap Year, in February you have a one day window of opportunity to do > upgrades. ;-) > > Jerry Whittle > ASIFICS DBA > NCI Information Systems Inc. > [EMAIL PROTECTED] > 618-622-4145 > > > -Original Message- > > From: Tracy Rahmlow [SMTP:[EMAIL PROTECTED] > > Sent: Wednesday, December 10, 2003 10:44 AM > > To: Multiple recipients of list ORACLE-L > > Subject:24 x 7 x 365 > > > > > > Hello, > > Our company would like to know whether or not Oracle supports true 24x7x365 > > availability for an oltp database. We currently are using the 8.1.7 enterprise > > edition. Does an architecture exist whereby we can upgrade the database and/or > > operating system and not cause an outage? Will RAC solve this issue? Are there > > any other areas of concerns that I should be thinking about? For example, > > analyzing with the validate clause and its impacts on the transaction system. > > Thanks > > > Mladen Gogala Oracle DBA Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mladen Gogala 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: 24 x 7 x 365
Title: RE: 24 x 7 x 365 As 2004 is a Leap Year, in February you have a one day window of opportunity to do upgrades. ;-) Jerry Whittle ASIFICS DBA NCI Information Systems Inc. [EMAIL PROTECTED] 618-622-4145 -Original Message- From: Tracy Rahmlow [SMTP:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2003 10:44 AM To: Multiple recipients of list ORACLE-L Subject: 24 x 7 x 365 Hello, Our company would like to know whether or not Oracle supports true 24x7x365 availability for an oltp database. We currently are using the 8.1.7 enterprise edition. Does an architecture exist whereby we can upgrade the database and/or operating system and not cause an outage? Will RAC solve this issue? Are there any other areas of concerns that I should be thinking about? For example, analyzing with the validate clause and its impacts on the transaction system. Thanks
RE: 24 x 7 x 365
Well, first thing that needs to be noted is that “24 x 7 x 365” indicates uptime for 7 years, which always gives me a chuckle when people say it. Mind you, I’ve been guilty of saying it too! J And probably the second thing that needs to be said is that no single product addresses true HA requirements. RAC is no different to that. It provides machine failover capability, and while it can be stretched to a certain extent to give the illusion of site failover capability, you would still need someone like DataGuard to address issues such as human error correction. And probably the third thing that needs to be said is that it’s not just a technology thing. If you don’t have robust change control, for example, a simple coding error can ensure you don’t meet your availability requirements. And probably the fourth thing that needs to be said is that it’s all covered in one of my papers at RMOUG Training Days next February, Real Business Continuity with Oracle10g . J Pete "Controlling developers is like herding cats." Kevin Loney, Oracle DBA Handbook "Oh no, it's not. It's much harder than that!" Bruce Pihlamae, long-term Oracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tracy Rahmlow Sent: Thursday, December 11, 2003 3:44 AM To: Multiple recipients of list ORACLE-L Subject: 24 x 7 x 365 Hello, Our company would like to know whether or not Oracle supports true 24x7x365 availability for an oltp database. We currently are using the 8.1.7 enterprise edition. Does an architecture exist whereby we can upgrade the database and/or operating system and not cause an outage? Will RAC solve this issue? Are there any other areas of concerns that I should be thinking about? For example, analyzing with the validate clause and its impacts on the transaction system. Thanks American Express made the following annotations on 12/10/2003 09:41:15 AM -- ** "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." ** ==
