DBArk from Essist
Now widely accepted as the next ‘To-Do’ project for most companies, this Archiving project is still being put back… mainly because the traditional approach can bring along a fear of corrupting the database or application, a potential for application down-time and a significant amount of time for a traditional approach project.
And that is certainly a valid concern. Even if we have a well known third party application, this could be configured in many ways to suit a variety of requirements for our installation. And then there are always the modifications we made to suit our own company requirements. Did we document them?… all of them?
But the advantages that can be gained by archiving some of the olderdata are immense…
And now you can deploy the project with confidence…
with DB-ARK
Advantages of Application Database Archiving: –
- Faster Application Responses
- Shorter Back-up Times
- Faster Recovery Times after Disasters
- Faster Query and SQL jobs
- More Overnight Processing Window
- Faster Migration to New Releases of the Application
Advantages of DB-ARK: –
- Easy to Install and Run
- Schemas and Data Models for Many Popular ERP and Banking Systems such as M3 Already Mapped
- Tailored for IBM System i and DB2
- Full audit and management of archived data
- No requirement to Interrupt all the Application Users and Close Down the Application
With DB-ARK, many years of Application Archiving knowledge and experience is coupled with the worlds leading brains on Application Design Recovery.
In many instances, it is the very fear of getting the File/Table links wrong and either archiving something that shouldn’t have been archived or – worse – leaving some information back in the Operational Database that will cause the Application to fail/ABEND.
Along with the mature Database Architecture Models, the experience of Archiving over many applications over many years kicks in and a sensible Archive approach can be initiated that will yield IMMEDIATE results.
Not just a purge…
Access to the Archive Data? Of course. In most instances, the existing application can be run over the Archive Data directly and it is always available to be recovered on-demand. In fact, using almost the same process we can create Test Database Subsets that we can run the Application over.
And where to store it? Well, you could Archive from a DB2 database on an IBM System i and store the Archive on an SQL server in a remote location. Keep it on-line, on tape, in BRMS or over on a separate platform and all points in between.
Take back control.
Not just a purge…
Access to the Archive Data? Of course. In most instances, the existing application can be run over the Archive Data directly and it is always available to be recovered on-demand. In fact, using almost the same process we can create Test Database Subsets that we can run the Application over.
And where to store it? Well, you could Archive from a DB2 database on an IBM System i and store the Archive on an SQL server in a remote location. Keep it on-line, on tape, in BRMS or over on a separate platform and all points in between.
Take back control.
