RE: Zero DataLoss
Date: Wed, 9 Nov 2022 15:04:06 +0000
Message-ID: <CO1PR19MB49841244BBEF94CA2176C8CC9B3E9_at_CO1PR19MB4984.namprd19.prod.outlook.com>
As usual, MWF hit the relevant points, except perhaps not standing in the predicted meteor impact zoneđ. Also consider these points:
For ANY zero data loss system itâs possible to come up with a scenario where (committed) data will be lost.
Attempting to achieve zero data loss can be an infinite resource (time and money) sink, so one should ALWAYS consider things like the cost and probability of that âlast bitâ of data actually being âlostâ.
And something to think about with MAA â all MAA or any âtwo-phase commitâ system does is prevent a transaction from committing until there are multiple (presumably at least one of would be âsecureâ) copies of said transaction. In a failure scenario, what really happens is that the âlast transactionâ, which in fact MAY have been âcommitableâ in a non-MAA environment, doesnât get committed, and, like any other âin-flightâ transaction, is âlostâ. All youâre really doing is changing the timing.
Good luck!
Clay Jackson
From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> On Behalf Of Mark W. Farnham
Sent: Wednesday, November 9, 2022 5:27 AM
To: chrishna0007_at_gmail.com; 'Oracle L' <oracle-l_at_freelists.org>
Subject: RE: Zero DataLoss
CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.
Presuming youâre already doing some sort of log application to a recovery system, a radio accessible way to pull the redo logs from a âdeadâ data center to be taken to your remote recovery site is probably the best you can do. Axxana Inc had this sort of hardware, but Iâm getting a problem trying to visit their website to copy a link to you.
IF a given âdisasterâ has a little warning you can update a custom table (say insert a row with the current scn and timestamp), commit, alter system switch logfile, alter system archive log all to accelerate shoving all the transactions committed so far to your recovery system. You can also have a policy that switches the database to restricted in the event of a disaster âearly warningâ but notice that in our mostly hacked world that is a slippery slope under time pressure for analysis. In combination those steps maximize the chances of shoving the required redo logs to your remote recovery systems in time. In lieu of the overhead of MAA or a piece of hardware that has a plex of your logfiles and archived logfiles and can transmit them in a burned up building that is buried in the crevasse of an earthquake and flooded in the crevasse, thatâs about as close to zero as you are going to get. (I didnât mention nuclear, because if you put a radio transmit unit in an EMP cage, you probably interfere with its ability to transmit. I leave that as an exercise for the community.)
mwf
From: oracle-l-bounce_at_freelists.org<mailto:oracle-l-bounce_at_freelists.org> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Krishnaprasad Yadav
Sent: Tuesday, November 08, 2022 10:55 PM
To: Oracle L
Dear Experts,
We want to achieve zero data loss availability in our environment , for this we are planning to put MAA in DB , but we see there is overhead of redo causing lgwr events .
so we put it back to maximum performance .
Apart from using ZDLRA and MAA, is their any other solution we can use to achieve this? .
Regards,
Subject: Zero DataLoss
Krishna
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Nov 09 2022 - 16:04:06 CET