Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Selective Backup & Restore?
Mon, Mar 29 2021 9:09 PMPermanent Link

Ian Branch

Avatar

Hi Team,
My Customer's database is getting quite large.  Perhaps not as large as some, but large nevertheless.
Is it possible to do a selective Backup and later Restore in some manner?
The idea being to Backup and then delete all table records prior to say 01/01/2010 from multiple tables so they no longer exist in the current database, but, if required at a later date to be able to restore those tables/records into the Database without negatively impacting existing tables/records.

Regards & TIA,
Ian
Tue, Mar 30 2021 2:29 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Ian


My first thought would be to look at EXPORT and IMPORT

After that it depends on why you want to do it. If its to save disk space then you need to do something that will allow the data to be physically removed. If not, and its just to speed things up a bit, what about creating clones of the tables you want to reduce and move the data into them - if you use the date range as part of the file name you could allow users to select a file/set of files to report on.

After you've deleted the unwanted data from the live tables don't forget to optimise them

Roy Lambert
Tue, Mar 30 2021 2:54 AMPermanent Link

Ian Branch

Avatar

Hi Roy,
The prime objective is to reduce the overall Database size.
I will have a look at Export/Import.

Regards,
Ian
Tue, Mar 30 2021 2:58 AMPermanent Link

Ian Branch

Avatar

I have had a look at Export/Import.  Might be problematic.
I just had a thoughty, perhaps I could export the data to DBISAM tables, assuming there is adequate field/data type compatibility.  Just thinking out loud here...
Tue, Mar 30 2021 4:45 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Ian


<<The prime objective is to reduce the overall Database size.>>

<<perhaps I could export the data to DBISAM tables>>

Why use DBISAM? How about this as a process:

1. create clones of tables that you want to archive data from
2. copy the data you want from the live tables
3. delete the copied data from the live tables
4. optimise the live tables
5. create backup of the archived tables / copy the backup tables somewhere
6. drop (or DELETEFILE) the archived tables

Roy Lambert
Tue, Mar 30 2021 9:42 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Ian


Minor change

0. Have  clones of tables that you want to archive data from

1. copy the data you want from the live tables
2. delete the copied data from the live tables
3. optimise the live tables
4. create backup of the archived tables / copy the backup tables somewhere
5. EMPTY the archived tables

Roy Lambert
Tue, Mar 30 2021 3:55 PMPermanent Link

Ian Branch

Avatar

Hi Roy,
Understood.  Thank you.  Still contemplating the issue.

Ian
Tue, Mar 30 2021 4:13 PMPermanent Link

Raul

Team Elevate Team Elevate

On 3/30/2021 3:55 PM, Ian Branch wrote:
> Hi Roy,
> Understood.  Thank you.  Still contemplating the issue.

What Roy proposed (or something similar based on same principle) is best
way to go.

EDB backups are more complex than DBISAM since table schema is not part
of table (like in EDB) and there is also what EDB calls a table version
related to actual schema changes to the tables.

This is one reason why you should always backup the catalogue but also
makes it very complex to bring back single table(s) or such.

Raul


Image