Incremental backups are huge [message #301070] |
Tue, 19 February 2008 02:23 |
n_de_fontenay
Messages: 33 Registered: October 2006 Location: Paris
|
Member |
|
|
Good morning,
I'm having a very particuliar problem right now.
My company has bought a product which it turns out has very generic tables generating lots of records to process an information.
Right now, for an information (I don't really want to give some business vocabulary) it generates a 100 records. It's wild!
It has created a lot of problems, on data files size, performance, backups and finally network (backups over the network).
Right now the database is 135 GB and growing 10 GB a month.
I'm trying to explain that the reason of all this pain is at the beginning a poor DB structure.
Currently we are doing incremental backups. The full backup weights about 175 GB and incremental backups can weight about 100 GB if someone run a report there's a weekly report.
That person mentioned to me that his report does only SELECT queries. He does that through the application though.
So right now people come to me saying, how come the incremental backups are so big and how come the full backups are bigger than the DB itself?
Additional information on the backups: there is no windowing recovery period or duplication on RMAN. It goes straight on tape (clogging the network on the way) every day.
So here are my questions:
1) What transactions generates archive logs?
2) Would a poorly structured DB accentuate the trend of archive logs generation? I tend to say yes but I have no way to prove that. Anybody ever faced this kind of demonstration problem? Any metrics I could gather to support my theory?
It's a difficult subject but any thoughts would be welcome.
Thanks,
Nico
|
|
|
|
|
Re: Incremental backups are huge [message #301111 is a reply to message #301070] |
Tue, 19 February 2008 03:55 |
n_de_fontenay
Messages: 33 Registered: October 2006 Location: Paris
|
Member |
|
|
Hi.
Thanks for your answers guys.
It's pretty much what I needed.
Actually, I've got so much questioning from unkonwledgeable people that I started questioning my fundamentals x)
It's good to have people reminding what they are.
I'm more confident.
It's not possible for me to re-think a complete structure of this complexe application.
I did show an example using the classical HR DB with employees and departments showing the differences between a generic table having it all and another structure with tables divided by entity.
The problem seems to be politics, not DBA :/
|
|
|