Thanks for the suggestions. I don't have 19T of disk to do the file-copy,
and will not get it right now even if I justify it. I asked for it once
before. I think they're still laughing at my request. I also will not be
able to get active DG and a standby. Used to have a standby, but with the
shake up in the company in the past year, DG and standbys were deemed too
costly and superfluous. I'm stuck with using tape and the current TTS
process. The only upside is that these two databases are slated to be
replaced within the next 6-9 months. Of course, I've heard that story
before and it was nothing more than a fairy tale.
Still trying to find out from my SEs how long tape backups are kept. I
have already informed my manager the current backup strategy is not
acceptable. I'm not sure he really understands the risks even though I
said, "I can't restore the database to a reasonably current P-I-T."
Sandy
On Wed, Jun 10, 2015 at 11:32 AM, Mladen Gogala <dmarc-noreply@xxxxxxxxxxxxx
wrote:
My advice would be to scrap the TTS process and create an active DG
standby DB. You could also use it to backup the primary. Also to consider
is SAN snapshot.
Regards,
On 06/10/2015 11:33 AM, Sandra Becker wrote:
OS: Solaris10
DB: EE 11.2.0.2
Current database and backup configuration:
- 19T database that we backup to tape--disk is not an option for me
- Level 0 backups roughly once a month, Level 1 weekly, archivelogs
multiple times per day
- Backup optimization is OFF
- No READ ONLY tablespaces
- TTS process that runs 7 times a week to create new tablespaces, one
per day, using transportable tablespaces between two databases. The target
database is the 19T one.
- Once data has been loaded, it is rarely updated after 90 days
- Backups and the TTS process are not allowed to run at the same
time. The people who wrote the very complex backup and TTS process scripts
left the company over 2 years ago and they are not well documented.
- Level1 backups are now running long enough that the TTS process
doesn't run at it's next scheduled time causing us to fall behind and
customer frustration because the expected data is not in the database
I am looking at options to improve backup performance. From what I've
read, I can set most of the tablespaces to READ ONLY and enable backup
optimization so the tablespaces that don't change do not get backed up
every week. Given the length of time for a Level 1 backup, schedule of
Level 0 backups, and tape retention policy, I am currently at risk of not
being able to restore this database if needed.
Questions:
1. What would be valid reasons for not letting the backups and TTS
process run at the same time? The TTS process can take up to 4 hours for a
single day.
2. If backups and creating/loading the new tablespaces should not be
done at the same time, I'm thinking that modifying the schedule would be an
option I should consider so the TTS process completes before the backup
kicks off. Does this sound reasonable?
3. Is my thinking around optimizing my backups valid? Is there
another/better way I should consider? We would need to script something to
change the tablespaces to READ ONLY on a daily or weekly basis.
4. If a tablespace is READ ONLY and has not been backed up yet. will
it get picked up in a Level 0 or 1 backup even with backup optimization on?
I am new to the transportable tablespace feature and haven't been able
to figure out everything our TTS scripts are doing or why yet. I
appreciate any suggestions and insight.
--
Sandy
GHX
--
Mladen Gogala
Oracle DBAhttp://mgogala.freehostia.com
