Totally agree with you. The performance is not the issue.
The management want to have the data clean, but want to access it if
needed.
There is one or two guys that will have to go on the historical data
if needed.
Thank you very much for your time.
Luc
On 1/31/07, *Carel-Jan Engel* <cjpengel.dbalert@xxxxxxxxx
<mailto:cjpengel.dbalert@xxxxxxxxx>> wrote:
My main objection against solutions with separated sets of
historical and
actual data is that users often (read: ultimately always...) want
to see
information combined/derived/aggegrated from both actual and
historical
data. This yields maintenance of more complex queries, with
unions, and a
lot of extra development, testing, release and version management
of data
and code.
I'd prefer to keep the whole thing in the same set of tables,
eventually
partitioned.
40 GB of data is not that big, after all.
You say it will probably help the performance. This implies
performance is
suboptimal now. Is the amount of data the root cause of your
performance
problems? Is performance the reason why you want to start all the
hassle
with splitting/separating your data? Did you investigate what is
causing
your bad performance?
Don't get me wrong: If you have 15GB worth of data that serves no
requirement (incl. legal enforcements to keep historicla data for
7 or 10
years, or whatever): Just make a backup of the database (or two), and
throw away the obsolete stuff. If you still need the data:
describe the
real problems, investigate for possible solutions and pick the
best. Try
not to jump into solutions to soon.
Regards, Carel-Jan
===
If you think education is expensive, try ignorance. (Derek Bok)
===
> Thank you all for your answers.
> The situation is, we have a in-house application, we having a lot of
> historical data (invoices, info on old products, old documents).
> It's not a big database (around 40Gigs), but I'm sure that we
can "purge"
> at
> least 15 Gigs of data.... of data that it's not been used anyway.
>
> It will probably help the performance in the same time ...
>
> We were thinking of creating another database, with the same
structure and
> transfer data from one to the other.
> My concern was on the modification that will be done on the
structure ....
> so we decided that we will apply the same scripts to both
databases, so
> the
> structures will be the same all the time.
>
> Do you have some comments ?
>
> Thanks
> Luc
>
>
> On 1/31/07, Carel-Jan Engel <cjpengel.dbalert@xxxxxxxxx
<mailto:cjpengel.dbalert@xxxxxxxxx>> wrote:
>>
>> Archiving is a solution. What is the probplem you're trying to
solve?
>>
>>
>> Best regards,
>>
>> Carel-Jan Engel
>>
>> ===
>> If you think education is expensive, try ignorance. (Derek Bok)
>> === On Tue, 2007-01-30 at 10:59 -0500, Luc Demanche wrote:
>>
>> Hi,
>>
>>
>>
>> We are thinking to have a process that will archive data from our
>> production database to another database, or somewhere else .....
>>
>> For example, data of an old customer, info of an old product,
etc ....
>>
>>
>>
>>
>>
>
>
> --
> Luc Demanche
> Oracle DBA
> (514) 867-9977
>
--
Luc Demanche
Oracle DBA
(514) 867-9977
