FW: Backup VLDB's
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 10 Nov 2009 10:42:51 -0500
snipped to fit – apparently your messages to me are getting turned into huge
pictures – I have no idea why.
_____
From: Mark W. Farnham [mailto:mwf@xxxxxxxx]
Sent: Tuesday, November 10, 2009 8:59 AM
To: 'Nizar Ahmed'; 'hrishys@xxxxxxxxxxx'; 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: Backup VLDB's
It absolutely is not a fact, nor is it written as a fact. It is a logical
condition. Whether it has a logical value of TRUE is something you measure
with each candidate backup technology against your actual load on your
actual system. If a given backup process degrades your throughput or
response time materially then you have to decide whether that degradation is
tolerable, constrain the degradation to a window where it is not material,
or reject that backup strategy. While tendancies of various backup methods
to generate noticeable loads can be described, what works for a particular
system has to be measured. Depending on whether journalling is used and
other factors, for example, some varieties of split duplex or triplex backup
have near zero overhead during the backup, but then put a significant load
on the i/o subsytems until the re-imaging is complete. If someone measures
only the overhead during the backup, then that is missed. Some varieties of
splitting are quite efficient at both splitting and re-association. You have
to measure. Your supposition that RMAN puts a noticeable load on overall
system performance could be true for some systems and false for other
systems. From the way you have written your response I think you have not
measured yet.
Your other point is very compelling, and is exactly what I am writing about
when I say to design your recovery. If you already have a source from which
to reload any lost data, then that may indeed represent your best recovery
protocol if the reloading process can serve your operational requirements.
Regards,
mwf
_____
From: Nizar Ahmed [mailto:gnahmed.c@xxxxxxxxxx]
Sent: Tuesday, November 10, 2009 6:55 AM
To: Mark W. Farnham; hrishys@xxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Cc: Nizar Ahmed
Subject: RE: Backup VLDB's
Thanks Hrishy and Mark for your comments.
Fortunately I am at a place where $$ do not matter. EMC is our backup
partner; we have VTL's; and are also trying out BCV to another node and
backing up (RMAN) from the second node. This is for another system and this
costs real money. We had EMC experts on site but this approach is still not
stable / smooth as we would like it to be.
Second though Mark's points have compelling logic – in the 5 years I have
handled this system, I have not had to do a single recovery. And I am not
stupid to extrapolate this to mean – "I don’t need a backup ever…" This
system sources its data from various other systems and I can always fall
back on them to reload lost data. See Mark's comments I have highlighted –
Is this a guaranteed fact?
Third – My question – "what's the fastest way to backup" is because I need
read response time in seconds on these huge tables. I do not want the RMAN
backup window to run for most of the day thereby putting a load on the
overall system performance. We do use block change tracking and run a
differential incremental on weekdays to keep the sizes of the backup small.
Thanks gents,<snip>
The information in this email may contain confidential material and it is
intended solely for the addresses. Access to this email by anyone else is
unauthorized. If you are not the intended recipient, please delete the email
and destroy any copies of it, any disclosure, copying, distribution is
prohibited and may be considered unlawful. Contents of this email and any
attachments may be altered, Statement and opinions expressed in this email
are those of the sender, and do not necessarily reflect those of Saudi
Telecommunications Company (STC).
قد يحتوي هذا البريد الالكتروني على معلومات سرية موجهة إلى الأشخاص المرسلة
لهم فقط ولا يصرح لأي شخص آخر الاطلاع عليها، وفي حال استلام هذا البريد
الالكتروني بشكل خاطئ فإنه يجب حذفه وإبلاغ المرسل بشكل مباشر. وأي تسريب لتلك
المعلومات أو نسخها أو نشرها يعد أمراً مخالفاً وقد يؤدي إلى المسائلة
القانونية، كما أن الآراء المذكورة بهذا البريد تمثل رأي مرسلها ولا تعبر
بالضرورة عن رأي شركة الاتصالات السعودية
Other related posts:
