Comments?
Dereck L. Dietz
recovery has been explained to us. This is an Oracle 10g database running
on Windows 2003 server.
The way we did the disaster recovery backup is:
Step1:
1.. Export the entire db (with no rows option) - This will get a copy of
export to recreate the database with all users and system settings.
2.. Export the entire schema (with no rows option) - This will get a copy
of export to recreate empty table shells with indexes, keys and all
procedures, packages, functions and any other metadata for each user.
3.. Export every table by schema (all table data) - This is all the data.
Step2: Every export file is zipped and encrypted using gpg
Step3: Move the whole archive to USB drive.
The entire process takes about 5 full days. Which is ok considering its
once a month job. Most of it is automatically done except for moving to usb
and preparing the scripts. The total size of this is about 170GB.
We have 1tb disks which can hold up to 5 or 6 of these copies.
sybr...@hccnet.nl
This is not about disaster recovery. This is about flagrant
incompetence.
First of all export is NOT a disaster recovery option. Export is a
*logical* dump. This means if you use exp imp to recover a database
you do NOT have a physically identical copy, so you CAN'T use archives
to recover your database.
Secondly: you describe this nonsense is going to take 5 (FIVE) full
days. Will the 'export' be consisted? OF COURSE NOT.
Apart from that : a 170 Gb 'export' is nonsense. Did you take into
account how much time it takes to import it?
The only option if you insist on misusing exp as a disaster recovery
mechanism for this database, is using transportable tablespaces.
However, I would recommend using this 'plan' or the paper it was
printed on as toilet paper.
--
Sybrand Bakker
Senior Oracle DBA
gazzag
Who devised this "strategy"? Have they not heard of RMAN, for
example?
-g
Ed Prochak
Along with other comments, I will add that this is at best half of
disaster recovery planning. Have you ever actually tried to restore
from these backups? Until you can successfully do that, you do not
have a recovery plan.
Ed
Dereck L. Dietz
"gazzag" <gar...@jamms.org> wrote in message
news:28dd705b-5d2c-4962...@d1g2000hsg.googlegroups.com...
-g
Our off site DBA.
I've been harping about RMAN since I first started here (as a contractor
before being hired in). Other than having my head bit off I was told he
wasn't using RMAN because he didn't have an RMAN repository set up. I think
I got in trouble for calling him on the fact that the repository isn't
mandatory for using RMAN.
joel garry
In addition to all the other excellent advice you've received, note
that rman compression works very well, so not only is it faster and
able to do transactional recovery, it also doesn't need that zip
step. It should be a lot less than 5 days, too.
The procedure you've described is very good - for long term archival
purposes, not for disaster recovery - unless your disaster recovery is
on some incompatible platform. And like Sybrand pointed out, the imp
would be slower than the exp, 5-10x in my experience. So unless your
disaster recovery window is on the order of months, you might be
unnecessarily manufacturing another disaster. Which would be Ed's
point. Even so, five days sounds long, I do 40G in about 40 minutes
on middling risc hardware with a low-end SAN, 6-12 hours to exp/move/
create schema/imp on another box (I've been testing a complex
migration/upgrade, have the whole thing down to 26 hours without
compulsive tuning [perhaps next one less now that I've discovered the
log file size advisor]). Google for Connor McDonald's site, he has a
page on how to speed up exp. DIRECT=Y with the largest buffer made a
big difference for me.
There could be an argument for user managed backups for disaster
recovery, but again, you need to know what you are doing and need to
have appropriate hardware (for example, a SAN with snapping
capability). Personally, I like the idea of having everything
including the oracle installation for a bare-metal rapid disaster
recovery, but I don't know about Windows there (I tried it once with
ghosting including an app server, it worked, but never felt good about
the steps it required and didn't implement it).
jg
--
@home.com is bogus.
http://www.signonsandiego.com/uniontrib/20080723/news_1b23qcom.html
Palooka
himself, has not the faintest clue how to go about things. Sadly, one
sees this all too often.
Good luck.
Palooka
joel garry
Aw jeez, tell the dorkus to go to the dbconsole, click on maintenance
tab, click on Schedule Backup, run through the four steps for
customize backup. Then if he doesn't want to schedule it to work
automatically, he can cut and past the script. Or better, don't tell
him, just spend five minutes to do it and say it came to you in a
dream where Angelina Jolie was hurting you.
jg
--
@home.com is bogus.
Dereck L. Dietz
"joel garry" <joel-...@home.com> wrote in message
news:4facad89-7f55-44e5...@w39g2000prb.googlegroups.com...
Unfortunately the server is physically in another state.
Dereck L. Dietz
"Ed Prochak" <edpr...@gmail.com> wrote in message
news:612b755c-df6b-4fd1...@34g2000hsh.googlegroups.com...
We haven't received the instructions on how to restore nor have we had a
chance to practice a restore.
rogergorden@....gmail.com
> "Ed Prochak" <edproc...@gmail.com> wrote in message
>
> - Show quoted text -
I wise man once said to me: "You cannot possibly call yourself a DBA
unless you can properly backup and restore a database."
I'd add to that that if you can't do that, then database
administration, no matter how well you may code SQL, is beyond your
grasp and that you are endangering the welfare of your company's data
and your company's livelyhood if they rely on it by attempting to fill
a role for which you aren't qualified.
If not RMAN, then why isn't that DBA doing hot backups using shell or
PERL???
Is there ever any discussion on what if disaster strikes??
Is there ever any discussion on what if boneheaded jr. sysadmin
deletes a datafile? What if a disk gets corrupted or just dies?
Is the answer simply to run like hell and update your resume?
Let me guess, your PHB who thinks nothing of overpaying for his car,
house, food and mistress decided to be frugal with what he pays
professionals who manage his business.
Roger
joel garry
> "joel garry" <joel-ga...@home.com> wrote in message
>
> Unfortunately the server is physically in another state.
The dbconsole is a GUI app added with the 10G install that runs in a
browser - the more general version is called grid. It could be in
another country. Put this term in the search box at http://tahiti.oracle.com:
dbconsole
There should be a file somewhere (maybe $ORACLE_HOME/install/) called
something like portlist.ini that says where to point the browser at
(unfortunately, the ports could be changed after that file is
generated). The docs probably say where the defaults are, obvious ones
to try are http://<yournode>:1158/em or https://<yournode>:5500/em
(I've seen cases where proxies and other strange things netadmins do
block access, if you can't resolve that you need to run the browser
locally to the server - X works for me on unix, various pcanywhere/
dameware type apps on windows, I do it the latter way for XE on
Windows in several states [the start menu selection takes me to
localhost:8080]).
jg
--
@home.com is bogus.
http://www.signonsandiego.com/uniontrib/20080725/images/tigers430.jpg
ora...@msn.com
On Jul 22, 8:28 pm, "Dereck L. Dietz" <diet...@ameritech.net> wrote:
> The below is a portion of an email describing how the plan for disaster
> recovery has been explained to us.
This plan is a disaster, and now that I've recovered from reading
it ...
> This is an Oracle 10g database running
> on Windows 2003 server.
>
> The way we did the disaster recovery backup is:
>
> Step1:
>
> 1.. Export the entire db (with no rows option) - This will get a copy of
> export to recreate the database with all users and system settings.
And you can use imp with rows=n from a full export including rows to
do the exact same thing.
> 2.. Export the entire schema (with no rows option) - This will get a copy
> of export to recreate empty table shells with indexes, keys and all
> procedures, packages, functions and any other metadata for each user.
And, gee whiz gollee whilikers, you can do THAT, too, from a full
export including rows by using both the rows=n command-line parameter
and the fromuser/touser options.
> 3.. Export every table by schema (all table data) - This is all the data.
Again, which you'd have in a full export including data. So can
someone explain why THREE exports are taken when ONE will suffice???
> Step2: Every export file is zipped and encrypted using gpg
>
And you can do that with the single, fully loaded export someone seems
to think is unnecessary.
> Step3: Move the whole archive to USB drive.
Oh, joy, now you have mobile media that can be subject to tampering
carrying these three wonderful exports, which are nothing more than
point in time copies of the database structures and data. Absolutely
NO recovery via archived redo log application can be effected (as
already stated by Sybrand) so how can anyone seriously consider this
three-ring-circus of busywork a backup strategy? Any series of
database 'backup/recovery' events that requires 5 full days of
attention to complete isn't a disaster recovery plan, it's a planned
disaster. It certainly isn't a usable recovery method.
>
> The entire process takes about 5 full days.
Sourdough starter takes less time to ferment.
> Which is ok considering its
> once a month job.
Because when you finally finish the current 'backup' it's time to
start the process over again.
> Most of it is automatically done except for moving to usb
> and preparing the scripts. The total size of this is about 170GB.
Ridiculous, really.
>
> We have 1tb disks which can hold up to 5 or 6 of these copies.
You can perform 6 of these 'backups' in a month's time ... and no one
has mentioned the issue of someone changing object definitions between
the time the first glorious export is taken and the second is begun,
thus invalidating the first effort and requiring the entire process to
begin anew.
[from a subsequent response by you]
> ... I was told he wasn't using RMAN because he didn't have an RMAN repository set up.
As you stated in a follow-up post that's hogwash. Possibly he's
having difficulty spelling RMAN ... what could be simpler than issuing
two commands to RMAN
restore database;
recover database;
to put your database in working order again? I must agree with
Sybrand and state this is nothing except flagrant incompetence. I
think you need a new off-site DBA.
David Fitzjarrell
joel garry
> Comments embedded.
> On Jul 22, 8:28 pm, "Dereck L. Dietz" <diet...@ameritech.net> wrote:
>
> > The below is a portion of an email describing how the plan for disaster
> > recovery has been explained to us.
>
> This plan is a disaster, and now that I've recovered from reading
> it ...
>
> > This is an Oracle 10g database running
> > on Windows 2003 server.
>
> > The way we did the disaster recovery backup is:
>
> > Step1:
>
> > 1.. Export the entire db (with no rows option) - This will get a copy of
> > export to recreate the database with all users and system settings.
>
> And you can use imp with rows=n from a full export including rows to
> do the exact same thing.
>
> > 2.. Export the entire schema (with no rows option) - This will get a copy
> > of export to recreate empty table shells with indexes, keys and all
> > procedures, packages, functions and any other metadata for each user.
>
> And, gee whiz gollee whilikers, you can do THAT, too, from a full
> export including rows by using both the rows=n command-line parameter
> and the fromuser/touser options.
>
> > 3.. Export every table by schema (all table data) - This is all the data.
>
> Again, which you'd have in a full export including data. So can
> someone explain why THREE exports are taken when ONE will suffice???
It's been too long since I've done it, but my recollection of going
away from a single full exp is that the imp has to run through the
entire export before it thinks it is done, so if you have a multistep
restore with time pressure, you don't want to be waiting unnecessarily
while it cranks through data you don't want yet. Please correct me if
I'm wrong (I'd like to know if I'm doing obsolute stuff too!). In the
multi-[hour|day] type of imp situation, you may have some things more
important than others that you want rapidly brought back into service.
Obviously, I agree with everything else you've said.
jg
--
@home.com is bogus.