Restore a DB without audit data
- Thread starter kasundha
- Start date
Rob Fitzpatrick
ProgressTalk.com Sponsor
You can't. There is no option for a partial database restore.
kasundha
Member
Is there any method to take the backup, excluding audit data?
Rob Fitzpatrick
ProgressTalk.com Sponsor
Database backup and restore (probkup and prorest) acts on the entire database. You cannot deselect areas or objects.
It is possible to create a copy of a database by dump and load of schema, data, and metadata. This gives you granular control of which objects get dumped from the source database and loaded into the target database. It also gives you the opportunity to make configuration changes that might otherwise be infeasible or impossible; e.g. changing the database block size, or changing structure or object assignments to areas. And it is possible to script the entire process.
There are several challenges to this approach. There is no utility to do the work for you, or even to tell you what work must be done. You have to know what data is in the source, and decide what needs to get to the target. This includes application schema, table data, and other data. The list of other data can be quite extensive, depending on your database configuration, use of features and add-on products, authentication, etc.
You need to know how to dump and load all of this data manually. Then you need to script these commands, with the appropriate permissions, logging and exception handling. The scripted process should be tested well to ensure it is sufficiently robust.
A dump and load is typically an infrequent exercise, say once every few years, or as needed for a project goal, like restructuring or server migration. It is not done as a replacement for database backups.
If you don't want to restore audit data, that suggests to me that perhaps it is because you have a lot of it. You should not have a lot of audit data in a production database. The best practice with OpenEdge Auditing is to archive that data on a regular basis into an audit archive database, to prevent the audit data from becoming a maintenance liability in the production environment.
Or is there some other reason why you do not want to restore audit data?
It is possible to create a copy of a database by dump and load of schema, data, and metadata. This gives you granular control of which objects get dumped from the source database and loaded into the target database. It also gives you the opportunity to make configuration changes that might otherwise be infeasible or impossible; e.g. changing the database block size, or changing structure or object assignments to areas. And it is possible to script the entire process.
There are several challenges to this approach. There is no utility to do the work for you, or even to tell you what work must be done. You have to know what data is in the source, and decide what needs to get to the target. This includes application schema, table data, and other data. The list of other data can be quite extensive, depending on your database configuration, use of features and add-on products, authentication, etc.
You need to know how to dump and load all of this data manually. Then you need to script these commands, with the appropriate permissions, logging and exception handling. The scripted process should be tested well to ensure it is sufficiently robust.
A dump and load is typically an infrequent exercise, say once every few years, or as needed for a project goal, like restructuring or server migration. It is not done as a replacement for database backups.
If you don't want to restore audit data, that suggests to me that perhaps it is because you have a lot of it. You should not have a lot of audit data in a production database. The best practice with OpenEdge Auditing is to archive that data on a regular basis into an audit archive database, to prevent the audit data from becoming a maintenance liability in the production environment.
Or is there some other reason why you do not want to restore audit data?
kasundha
Member
We have different DB servers for other purposes, and from time to time, we need to restore the live DB backups to those servers. Since I have a server spacing issue, I'm trying to omit the audit data from those servers.
Eg:- Monthly reporting server - replacing the db in every month-end.
Rob Fitzpatrick
ProgressTalk.com Sponsor
I understand the business need. But it still sounds like you have a lot of audit data in your production database. And that is not a best practice.
Virtually all of your audit data, except the most recent data from the current day, should be archived/deleted from production. Your auditors should be reading that data from an audit archive database. If you do that, you will no longer have the need to restore a backup of prod without audit data.
TomBascom
Curmudgeon
I haven’t tried this but… you could try restoring and then running proutil truncate area on the audit area. That’s not quite what you are asking for but it might get you the same result.
As Rob says though - you should not be keeping large amounts of audit data in your production instance in the first place. And now you know why
As Rob says though - you should not be keeping large amounts of audit data in your production instance in the first place. And now you know why
c_verbiest
New Member
see also Access rights validated
Tom's approach works
We have our own audit tables (pre-dates OpenEdge supplied audit)
For our setup database that contains initial data for new customers we hang on to our audit data, but that data is not relevant for a new customer.
We use a script that does following steps
prorest from original pbu file
proutil -C truncate area "AUDIT tables"
proutil -C truncate area "AUDIT indexes"
proutil -C idxbuild all
proutil -C truncate bi
probkup to new pbu without the data of truncated areas
Tom's approach works
We have our own audit tables (pre-dates OpenEdge supplied audit)
For our setup database that contains initial data for new customers we hang on to our audit data, but that data is not relevant for a new customer.
We use a script that does following steps
prorest from original pbu file
proutil -C truncate area "AUDIT tables"
proutil -C truncate area "AUDIT indexes"
proutil -C idxbuild all
proutil -C truncate bi
probkup to new pbu without the data of truncated areas