JD_Edwards
Member
Re:RE: Oracle - Deleted PRODB733 Tables
Glad you had a solution, I was worried when I read this.
By the way, you may want to consider using OCM & Database Data Sources to
separate data into separate databases. It seems that many consultants that
setup One World on Oracle tend to place all of the data into one Oracle
database. This also seems to be JDE's recommendation for an Oracle
configuration. I think this is terrible, so I made a few changes.
We actually have 8 databases for our OneWorld installation. Three are on
our production server, the other 5 are on our test/disaster recovery
server. Here is what we have done.
JDEPROD - Contains the PRODCTL & PRODDTA schema's (production business
data).
JDESYS - Contains the SYS7333, SVM7333, OBJ7333, & DD7333 schema's.
JDEPCOBJ - Contains the PD7333 schema (production central objects &
versions).
JDETCOBJ - Contains the DV7333, JD7333, & PY7333 schema's (test co's &
versions).
JDECRP - Contains the CRPCTL & CRPDTA schema's (CRP, aka - PY, business
data).
JDEPRIST - Contains the PRISTCTL & PRISTDTA schema's (Pristine business
data).
JDETEST - Contains the TESTCTL & TESTDTA schema's (Test business data).
JDETRAIN - Contains the TRAINCTL & TRAINDTA schema's (We created this for
training).
The advantage of this is that should we need to restore Central Objects, we
can do this without preventing people from using the system. Should we
need to restore business data from any environment, we can also do this
without disabling the system. We have a much more flexible recovery
situation (since it's either the entire database, or nothing at all).
Additionally, it is much easier to tune the database to specific needs, (rb
segments, log & redo log files, db_block_buffers, shared_pool_size,
sort_area_size, etc), since like objects are grouped in their own
databases.
One other thing is that it is extremely easy to refresh test business data
from production via an export/import. One other mod to make this easy was
to call all business data tablespaces DTALARGE & DTAINDEX, and all control
table tablespaces CTLLARGE & CTLINDEX.
Sorry for the long-winded response,
Brad Snyder
Oracle 8.1.5 HPUX 11
OneWorld Xe SP 14.1
____________________Reply Separator____________________
Subject: RE: Oracle - Deleted PRODB733 Tables
Author: [email protected] (Gopal_Kistasami
<[email protected]>)
Date: 05/04/2001 8:39 AM
I have managed to restore the situation using my method, this took 16
hrs. Yes, we do not do archive logging and cold backup is performed
nightly using ufsdump.
Many thanks to all for responding.
Regards,
Gopal.
Gopal,
The main thing we need to know before answering this question is
if you are running your Oracle database in archivelog mode. In
this mode, the database copies the online redo logs to a specified
location before overwriting them. The redo logs contain details
of all transactions that affect the database. Running in archivelog
mode enables you to do complete or point-in-time recovery of the
database, providing you have kept all the archived redo logs since
the last "hot" or "cold" backup.
A "cold" backup is a backup that is performed while the database is
shut down. A "hot" backup refers to one that is done while the
database
is running, and the tablespaces are in backup mode. That is, you
needed
to have executed the command "ALTER TABLESPACE xxxxx BEGIN BACKUP;"
before copying the physical data files.
If you don't run your database in archivelog mode, then your only
options
are to restore the database from the last "cold" backup, or use the
last full export, if you have one.
If you do run the database in archivelog mode, and have performed a
"hot"
or "cold" backup and still have all the archived redo logs from that
backup, then you have a couple options, I think. You can either
recover
the entire database to a specific point-in-time (probably not a very
good
option since this will affect all tablespaces), or you can create a
clone
database, recover the database to a specific point-in-time with only
the
specified tablespace(s) data files online, export the tables and then
import
them into your production database. This is similar to the scenario
that
you
proposed, but it shouldn't require you to restore all the database
data
files, but only the ones you are interested in. However, I have never
done
this and it looks fairly complicated. You should probably have an
experienced
DBA or Oracle support consultant help you with this.
I hope this helps.
Michael Twaddell
OW B7331
Sun Unix 2.7
Oracle 8.1.5
--------------------------
--------------------------
Glad you had a solution, I was worried when I read this.
By the way, you may want to consider using OCM & Database Data Sources to
separate data into separate databases. It seems that many consultants that
setup One World on Oracle tend to place all of the data into one Oracle
database. This also seems to be JDE's recommendation for an Oracle
configuration. I think this is terrible, so I made a few changes.
We actually have 8 databases for our OneWorld installation. Three are on
our production server, the other 5 are on our test/disaster recovery
server. Here is what we have done.
JDEPROD - Contains the PRODCTL & PRODDTA schema's (production business
data).
JDESYS - Contains the SYS7333, SVM7333, OBJ7333, & DD7333 schema's.
JDEPCOBJ - Contains the PD7333 schema (production central objects &
versions).
JDETCOBJ - Contains the DV7333, JD7333, & PY7333 schema's (test co's &
versions).
JDECRP - Contains the CRPCTL & CRPDTA schema's (CRP, aka - PY, business
data).
JDEPRIST - Contains the PRISTCTL & PRISTDTA schema's (Pristine business
data).
JDETEST - Contains the TESTCTL & TESTDTA schema's (Test business data).
JDETRAIN - Contains the TRAINCTL & TRAINDTA schema's (We created this for
training).
The advantage of this is that should we need to restore Central Objects, we
can do this without preventing people from using the system. Should we
need to restore business data from any environment, we can also do this
without disabling the system. We have a much more flexible recovery
situation (since it's either the entire database, or nothing at all).
Additionally, it is much easier to tune the database to specific needs, (rb
segments, log & redo log files, db_block_buffers, shared_pool_size,
sort_area_size, etc), since like objects are grouped in their own
databases.
One other thing is that it is extremely easy to refresh test business data
from production via an export/import. One other mod to make this easy was
to call all business data tablespaces DTALARGE & DTAINDEX, and all control
table tablespaces CTLLARGE & CTLINDEX.
Sorry for the long-winded response,
Brad Snyder
Oracle 8.1.5 HPUX 11
OneWorld Xe SP 14.1
____________________Reply Separator____________________
Subject: RE: Oracle - Deleted PRODB733 Tables
Author: [email protected] (Gopal_Kistasami
<[email protected]>)
Date: 05/04/2001 8:39 AM
I have managed to restore the situation using my method, this took 16
hrs. Yes, we do not do archive logging and cold backup is performed
nightly using ufsdump.
Many thanks to all for responding.
Regards,
Gopal.
Gopal,
The main thing we need to know before answering this question is
if you are running your Oracle database in archivelog mode. In
this mode, the database copies the online redo logs to a specified
location before overwriting them. The redo logs contain details
of all transactions that affect the database. Running in archivelog
mode enables you to do complete or point-in-time recovery of the
database, providing you have kept all the archived redo logs since
the last "hot" or "cold" backup.
A "cold" backup is a backup that is performed while the database is
shut down. A "hot" backup refers to one that is done while the
database
is running, and the tablespaces are in backup mode. That is, you
needed
to have executed the command "ALTER TABLESPACE xxxxx BEGIN BACKUP;"
before copying the physical data files.
If you don't run your database in archivelog mode, then your only
options
are to restore the database from the last "cold" backup, or use the
last full export, if you have one.
If you do run the database in archivelog mode, and have performed a
"hot"
or "cold" backup and still have all the archived redo logs from that
backup, then you have a couple options, I think. You can either
recover
the entire database to a specific point-in-time (probably not a very
good
option since this will affect all tablespaces), or you can create a
clone
database, recover the database to a specific point-in-time with only
the
specified tablespace(s) data files online, export the tables and then
import
them into your production database. This is similar to the scenario
that
you
proposed, but it shouldn't require you to restore all the database
data
files, but only the ones you are interested in. However, I have never
done
this and it looks fairly complicated. You should probably have an
experienced
DBA or Oracle support consultant help you with this.
I hope this helps.
Michael Twaddell
OW B7331
Sun Unix 2.7
Oracle 8.1.5
--------------------------
--------------------------
