CA2545532A1 - Method and system for providing network attached system for disaster recovery and upgrade testing - Google Patents
Method and system for providing network attached system for disaster recovery and upgrade testing Download PDFInfo
- Publication number
- CA2545532A1 CA2545532A1 CA 2545532 CA2545532A CA2545532A1 CA 2545532 A1 CA2545532 A1 CA 2545532A1 CA 2545532 CA2545532 CA 2545532 CA 2545532 A CA2545532 A CA 2545532A CA 2545532 A1 CA2545532 A1 CA 2545532A1
- Authority
- CA
- Canada
- Prior art keywords
- primary
- database
- tables
- objectstore
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A method and system for providing a network attached system for real-time disaster recovery and upgrade testing wherein said system contains object management system software and a system database which contains reference data to point to the object within the system objectstore, the primary system, the secondary replicated system being attached to the same mirrored objectstore during maintenance or disaster recovery requirement the replica system is unattached upgraded to become the primary system or becomes the primary system the method comprising steps of:
(a) creating a replicated server containing the system in which the reference data in the system database points to the primary system mirrored filestore providing a storage mirrored filestore for changes to objects in the primary filestore to be recorded and system database tables that mirror the primary, except those tables, containing reference information that uniquely identifies the replicated system from the primary production system on the network fabric;
(b) unattaching the replica from the primary system in case of disaster or upgrade (c) subsequently after either successful upgrade or recovery reattaching the replica as the primary system.
(a) creating a replicated server containing the system in which the reference data in the system database points to the primary system mirrored filestore providing a storage mirrored filestore for changes to objects in the primary filestore to be recorded and system database tables that mirror the primary, except those tables, containing reference information that uniquely identifies the replicated system from the primary production system on the network fabric;
(b) unattaching the replica from the primary system in case of disaster or upgrade (c) subsequently after either successful upgrade or recovery reattaching the replica as the primary system.
Description
METHOD AND SYSTEM FOR PROVIDING A NETWORK ATTACHED
SYSTEM FOR DISASTER RECOVERY AND UPGRADE TESTING
Field of Invention Many institutions use metadata associated with an object, for example consider when one buys music from a record store, or goes to a library, or uses a computerised document management system or a records management system ( rocks or soil samples within the records management department of an oil company ).
The management of documents or objects is today commonplace. This application is an improvement that became possible only because of a discovery and correction of a flaw in how document versions were currently being handled and stems from the correction of that flaw. Namely the Identification and Separation of Deleted and Overwritten Documents, CA2,504,070 It also stems and is an improvement of a another prior application including an increase of scope, the prior application being CA2,506,303.
CA2,506,303 developed a process whereby changes , and upgrades can be applied to a copy of the system using a replicated system which shares the mirrored primary obj ectstore.
The advantages of the above application were vast not only did it reduce the number of objectstores needed thereby reducing cost, it also decreased latency and provided a continuously synchronised system, which allowed testing to take place upon real data under real conditions and safely.
Whilst users could continue to use the current production system, i.e. without risking the production system.
The replicated system was reattached once testing was over to the primary, and resynchronised, so as to be able to take over as the new primary production system.
The old primary system either being decommissioned, or alternatively upgraded so as to become the new replica system.
This application extends the scope of the prior application by applying the technique to records management systems and indeed any system that has a database of information associated with stored objects.
It also extends the above application by provision of rollback allowing online backup recovery and recovery from corruption of the live system and also rollback of user test data during testing should that be required.
It further adds features of previous applications and hence provides archiving and recovery of deleted and overwritten files.
It does the above using the advancement first submitted in Patent Application CA2,506,756, and moreover its improved version CA 2,523,206 (incorporating CA
SYSTEM FOR DISASTER RECOVERY AND UPGRADE TESTING
Field of Invention Many institutions use metadata associated with an object, for example consider when one buys music from a record store, or goes to a library, or uses a computerised document management system or a records management system ( rocks or soil samples within the records management department of an oil company ).
The management of documents or objects is today commonplace. This application is an improvement that became possible only because of a discovery and correction of a flaw in how document versions were currently being handled and stems from the correction of that flaw. Namely the Identification and Separation of Deleted and Overwritten Documents, CA2,504,070 It also stems and is an improvement of a another prior application including an increase of scope, the prior application being CA2,506,303.
CA2,506,303 developed a process whereby changes , and upgrades can be applied to a copy of the system using a replicated system which shares the mirrored primary obj ectstore.
The advantages of the above application were vast not only did it reduce the number of objectstores needed thereby reducing cost, it also decreased latency and provided a continuously synchronised system, which allowed testing to take place upon real data under real conditions and safely.
Whilst users could continue to use the current production system, i.e. without risking the production system.
The replicated system was reattached once testing was over to the primary, and resynchronised, so as to be able to take over as the new primary production system.
The old primary system either being decommissioned, or alternatively upgraded so as to become the new replica system.
This application extends the scope of the prior application by applying the technique to records management systems and indeed any system that has a database of information associated with stored objects.
It also extends the above application by provision of rollback allowing online backup recovery and recovery from corruption of the live system and also rollback of user test data during testing should that be required.
It further adds features of previous applications and hence provides archiving and recovery of deleted and overwritten files.
It does the above using the advancement first submitted in Patent Application CA2,506,756, and moreover its improved version CA 2,523,206 (incorporating CA
2,531,996 which increases the speed by separating the overwritten and deleted references and hence the documents at the point they are recorded ) by the extra independent storage objectstore to identify, record and separate the deleted overwritten and inserted objects or files.
This technique was also developed in CA2,531,714 to store all files added, deleted or overwritten, to allow the recovery from corruption and disaster recovery of the main primary system, however, the above application has an advantage over and above CA2,531,714 with less objectstores being required this as well as providing the capability of rolling back user data within the Testbed, in case of user inputting errors.
By incorporating the improved separation process developed in Application CA
2,531,996 , an improvement on CA 2,504,070, where an increases speed is realised, the application speed increases further.
CA 2,523,206 an enhancement of (2,531,996 and 2,504,070) is also incorporated in this application to allow archival and migration of files and recovery from erroneously deleted files.
Description of the Related Art Reference 1 a method developed and presented at the Documentum Conference in Lisbon May 2004, "Upgrading to Documentum Si using the Clean Build Toggle Clone Approach"
http://www.momentumeurope.com/conf track3.shtml .
In this method a replicated server ( document data within a system in a separate location, wherein the document data is stored in a system objectstore associated with a system database) was built, upgraded, plurality of data was achieved but only at a point in time in order to switch or toggle the new replica to become the production system. The data was copied from the objectstore using a full backup /restore on the Thursday night to the secondary backup store, on Friday night the Primary production server was shutdown and incremental backup and database export taken and these applied to the secondary server.
This step ensured the plurality of the data for the point in time when after testing a switch could be made. This method forms one of the foundation stones of this Invention, however, suffers from the fallback that the two systems are only in sync for a point in time.
The second Reference is co-pending CA2,504,070 , however within this application I
intend to use the improved version co-pending CA2,531,996, both these applications identify and separate the Deleted and Overwritten metadata in regards to documents deleted or overwritten. These allow individual transactions to be tracked and recovered.
The third reference is: CA 2,523,206 which is an improved version of Prior Application CA 2,506,756 as the concepts of delete archiving and migration are used within this application.
The fourth reference is CA2,531,714 to store all files added, deleted or overwritten, to allow the recovery from corruption and disaster recovery of the main primary system, as this feature is being incorporated into CA,2,506,303 which forms the fifth reference.
The final reference is that of fellow inventor Sandeep Jain Oracle Corporation US5737601A. Who invented two way replication using a similar low level method in databases. However this invention does more than the above invention as it has to handle the transactions as related to a objectstore, and identify and separate documents.
Briefly here also to mention Netapps they simply take snapshots of data in order to replicate and do not achieve continuous synchronisation.
Advantages of this application This application combines the best features of all the prior applications to make a real-time disaster recovery system / Testbed that can rollback transactions.
The advantage of this rolling back transctions is that many runs of the data can be done, should the data be corrupted. It also allows some disaster recovery for the primary system. It improves CA 2,506,303 which provides continuous synchronicity, increased latency by sharing the same primary objectstore. This application further uses the concept of mirroring by not only mirroring the primary objectstore, but also the storage objectstore added specifically to record additions and changes to files.
Background of the Invention Many large companies use document management software, records management software. The purpose of such software is to help companies keep track of large volumes of objects in an organized way, so that objects can be easily stored, found and retrieved.
In many cases, there will be more than one version of a particular object.
Thus, version control is another aspect of most object management systems. Version control is an issue of particular importance in situations where different people are able to share objects and have shared access to the objects, including a shared right to independently modify the obj ects.
In this Application a document management system will be described however the techniques applied here can be easily applied to many different areas.
This application extends further and increases the robustness of the earlier system testbed application providing a safe environment to test upgrades including Major Upgrades, allowing the users to continue entry whilst an upgrade of a system is being carried out.
It allows real stress testing to be carried out with the ability to rollback changes should that be necessary.
Before the co-pending application CA 2,506,303 was designed risks occasionally had to be taken upon the live production systems, reversing out changes was often messy and many people would wait until somebody else had upgraded.
The application centres on a document management system however an object management system could be treated in the same way.
Documentum TM is a document management system that comprises of three different layers(or technologies) sitting on top of an operating system (server based) such as Unix or Windows 2000 server, a system database, and a objectstore.
The layers comprise of a Documentum application server layer that sits on top of the database and serves Documentum client interfaces. The reference information (i.e. the information pointing to the physical document data) and supplementary document information (i.e. the attributes of the types of Documents stored) are stored in the database. The actual physical data is stored in a objectstore on either the server, a Storage area network (SAN) or Filer pointed to by the server.
One example of a company in which a document management software system would be useful is an engineering company that has many versions of the same part. When a client orders that part the company has to find the correct part version.
The document management system typically includes a system database that is associated with a objectstore. The objectstore stores the actual document data, while the system database stores reference information that points to the document within the objectstore.
Also, the system database typically stores supplementary document information regarding each document.
As part of the management of a document management system the system database and objectstore continue to grow in size. While this is a positive and desirable situation for the business as a whole, the company's data / Intellectual property is kept safe. This poses large problems for systems people who need to maintain, upgrade these vast systems.
The problem posed is also complicated by the range of different technologies involved.
The document management system having its own layers to manipulate the user entry and the separate stores of data namely the system database and the objectstore which need to be maintained consistently.
For example every company needs to maintain the availability of these large systems stretching for some large companies into the terabytes of data. Hence recovery from disaster is important.
Should one of these systems experience problems, such as a performance problem or require a hardware or a Documentum, or a database software patch there is currently no satisfactory way of handling ,testing or validating these changes, nor providing archiving.
The changes can be tested on a test system but this system never mirrors a real live production system and Stress testing is seldom carried out (real load testing where sometimes the real problems of performance degradation are found).
Also documentum software, databases need maintaining, tuning and effects of small changes need to be adequately studied. Often its required to carry these requirements out on live production systems this risks lack of validation and stress testing and considerable periods of problems, or downtime if the patch applied fixes one scenario but breaks another, or when a mistake gets made.
This is unacceptable for most businesses, as some changes cannot be reverted.
With regards to major upgrades until very recently, most companies still preferred to completely write a new system and migrate the data across, some still do this, as the risk to their current system is so great.
This invention caters for major upgrades, however, here it is advisable to sever the connection between the servers and use a copy of the objectstore for the secondary system and use the approach as was presented by myself at the Documentum Conference in Lisbon May 2004, "Upgrading to Documentum Si using the Clean Build Toggle "Clone" Approach". The above approach was born out of a real-time critical problem.
The objectstore SAN storage that the Documentum management system was pointing to was running out of space.
Where this application surpasses its predecessor is that not only does it allow the entry of data whilst the mirrored system is being tested and upgraded as well as the resynchronisation with the main system as in the previous application. It also allows the rollback of transactions, during testing, disaster recovery, archiving and migration.
In this application a replicated server is used. The replica containing the proprietary document management system software and the system database containing reference data to point to the document data wherein said primary document data (mirrored) is associated with the secondary system database built, and hence plurality of data is achieved at any point in time that allows a switch or toggle to allow the new replicated server to become the production system on successful testing.
It is appreciated that this invention could additionally be used for the purpose of the secondary server acting as a "Standby" in case of failure of the first system's Server or in another capacity as a disaster recovery system.
Summary of the Invention This invention has two primary purposes the first is for testing, the second is for online backup or disaster recovery.
What is required is a method for safely validating changes that need to be applied to the system these could be software or hardware patches, minor or major upgrades.
More specifically as this has already been addressed by the previous application this application solves the further problem of rolling back the data changes in case re-testing is necessary.
The Testbed works as follows the network links are broken between primary and secondary as in fig 2.
The mirrored objectstores are broken allowing both the primary and secondary replicated system to connect to the primary; objectstore.
The upgrade is carried out then the secondary replica system.
On success there is a reconnection of the secondary replica system database to the primary objectstore (this has been re-mirrored) the test data can be removed from the database, the new mirrored primary objectstore not containing the mirrored files.
The invention envisages doing this testing safely with no risk by using a replicated secondary system as a system testbed which during normal operation constantly remains attached and in synchronous mode.
Should the link break, during a network outage the user input can be stopped, the replicated secondary system resynchronised.
On necessary upgrade being required user input is stopped the link is purposely broken between the replica and the production system. The mirror in the mirrored primary objectstore is broken allowing both the primary database and the replica database to be connected to the same yet separate copies of the primary objectstore.
User input is restarted on the primary system once the objectstore has been re-mirrored, the replica system now unattached to the primary system can be upgraded and used for testing purposes.
This enables users to experience only positive changes to the system documents being managed by a document management system. Whilst system professionals being able to break the mirrored primary objectstore, and the mirrored storage objectstore stop the transactions to the replicated secondary system database by severing the link can safely upgrade the system, stop user input temporarily re-attaching the replicated system database to the new mirror of the primary objectstore and resynchronise the replica using the transactions stored in the primary finally user input can be restarted .
On successful upgrade the secondary replica system is then switched or toggled to become the production system allowing, an upgrade to take place on the old primary system (the new secondary replicated system).
On failure of the upgrade the primary or production system is unaffected, and the primary system database, and primary document management system software are replicated to form a new secondary system and attached to the primary obj ectstore to ensure the primary system is secured for purposes of online backup.
In the meantime system professionals can resolve the problems on the original unattached secondary system, before carrying out the upgrade on the newly replicated secondary system.
The Primary and Secondary systems share a common objectstore which is mirrored.
They also share a specially created storage objectstore, which is also mirrored, this store is initially empty, but. If the secondary system and one of these mirrors is placed in an offsite location.
The primary system can be recovered on disaster, using the synchronisation techniques in previous applications.
Individual corrupted transactions and corrupted data can be rolled back or removed as all transactions are recorded at low level, including files. The identification and the separation of deleted and overwritten metadata and documents is key to this application as only if the discrete transactions are recorded against date and time of the transaction can they be matched with each other and to a point in date and time.
Files can also be archived to disk and recovered from disk using the storage objectstore which tracks all changes. Files or objects can be migrated with their metadata to other Document Management , or Record Management Systems.
The advantages of this application are many firstly like its predecessor the application can be used to provide a system testbed, which eradicates the need to do any risky change on a live production system. It provides a disaster recovery system capable of recovery from any disaster. It provides return on investment as not only does the primary and secondary system only share two mirrored file stores whereas at least three main objectstores would be normally required, the storage objectstore provides the capability of keeping these objectstore small by providing an archiving facility, also a facility to automatically recover deleted and overwritten files.
Accordingly, there is provided a method and system for providing a network attached system for real-time disaster recovery and upgrade testing wherein said system contains object management system software and a system database which contains reference data to point to the object within the system objectstore, during maintenance or disaster recovery requirement to the primary system, the secondary replicated system can be used as a test environment, the method comprising steps of:
(a) creating a replicated server containing the system in which the reference data in the system database points to the primary system objectstore providing a storage objectstore for changes to objects in the primary objectstore to be recorded and system database tables that mirror the primary, except those tables, containing reference information that uniquely identifies the replicated system from the primary production system on the network fabric;
(b) unattaching the replica from the primary system in case of disaster or upgrade (c) subsequently after either successful upgrade or recovery reattaching the replica as the primary system..
Preferably, the primary system is operably connected to a network fabric.
Preferably, the secondary system is operably connected to a network fabric. Preferably, the primary system has information loaded onto it, and is based on the first server.
Preferably, the secondary system has information loaded onto it, and is based on a second server.
Preferably, the first system and the second system is configured to allow a client computer operably connected to the network fabric to locate information owned by the first system and information owned by the second system. Preferably, the second system replicates the first system. Preferably, the system comprises a Object Management System residing on a server (Unix or Windows 2000 server) comprising of a objectstore storing the actual object data and a system database storing reference information pointing to the obj ects within a obj ectstore, supplementary information on the obj ects, together with system specific information. Preferably, the second system's system database is configured to mirror the information in that of the first system's system database less a portion of the data which allows the second system to be uniquely identified on the network fabric. Preferably, the objectstore containing documents is connected to the network fabric. Preferably, the objectstore is based on a Storage Area Network (SAN) or Filer connected to the network fabric and is mirrored.
Preferably, the primary system's server can be connected to the objectstore. Preferably, the secondary system's server can be connected to the same system objectstore it is appreciated that a separate objectstore for the primary system is used for storage of changes to the objects and this is comprehended by the Invention in this case the second separate object store would need to be mirrored so both the primary and second replicated databases could be attached to the object store, object storage store and be continuously applied to them throughout. Preferably, the primary and secondary system share the same system mirrored objectstore and mirrored storage object store. Preferably, the primary and secondary system databases are linked through the network fabric. Preferably, the method comprises of using Oracle Database software linking primary and secondary system databases on the network fabric by means of an Oracle database link command.
Preferably, in the case of a SQL Server database this link between primary and secondary system databases is by a means of a SQL server linked server command.
Preferably, both the primary and secondary systems databases have the required access permissions to access, modify, insert or delete data in each other and are accessible to each other across the network fabric. Preferably, the method comprises object data being added to the objectstore and reference data modified within system tables in the primary system database, and wherein the recording step comprises the step of recording reference data from all primary system tables, save those holding system specific data.
Preferably, the primary system, in response to a insert, update, delete command, inserts, updates,deletes reference data to each of the system tables affected for each particular transaction.
Preferably, the recording step comprises recording the reference data using at least one database trigger. Preferably, the recording step comprises recording the reference data using three database triggers associated with each system table, excepting those tables, which allow the first system to be uniquely identified on the network fabric.
Preferably, the method comprises adding a first database trigger associated with recording the changes after an insert command on each table, adding a second database trigger associated with recording the changes after an update command on each table and adding a third database trigger associated with recording the changes after a delete command on each database table, excepting those tables that define the primary system on the network fabric. Preferably, the method comprises performing identical changes, to that which can occur after an insert, update, delete command on each primary system database table and are recorded within the respective database trigger pertaining to that particular transaction to the identical replicated secondary system database table, by means of the salient SQL
command contained within the three triggers on each of the primary database tables, the transfer, and application of the identical SQL command made possible only by the primary and secondary database systems being linked through a database link on the network fabric. Preferably, the three triggers on each table in the primary database also record the changes on update, insert, delete to access-preservation tables and a single transaction table for all changes on all tables, the procedures within these tables also copy the objects to the storage objectstore. Preferably, the single transaction table contains the group: the type of transaction ( i.e. update, delete, Insert), the system table on which the transaction is performed, the primary key of the table, and a Date-timestamp.
Preferably, the recording step comprises using at least one access-preservation table.
Preferably, the recording step comprises using a set of three access preservation tables for each primary system table to be mirrored in the secondary's database tables. Preferably, the method additionally comprises using a database stored procedure to apply the changes and transactions recorded in the access-preservation tables and transaction table, to the secondary system should the database link be severed for any reason including that of maintenance to the secondary system on a time based input parameter, once the database link is restored and user input is halted temporarily, it does this by using the transaction tables it also updates storage objectstore to add the objects inserted and delete overwrite the objects that have been deleted and overwritten. Preferably, a set of database procedures can be used in contingency the database link is severed for any reason to apply the changes and transactions recorded, in order, from the time the link was severed to the secondary system in order to synchronise the two systems once the database link is restored again, user input to be halted at this point until the procedures have finished running , then the system can be returned to the said automated transfer using the SQL
command within the triggers on each table, with the user input recommenced.
Preferably, the set comprises a first access-preservation table to receive reference data recorded from the insert transaction on each system table, a second access-preservation table to receive reference data recorded from the update transaction on each system table, and a third access preservation table to receive reference data recorded from the delete transaction on each system table. Preferably, the method comprises input restriction until the primary and secondary system databases are re-synchronised. Preferably, the method comprises the contingency of applying the changes through at least a single database procedure using the combination transaction table and access-preservation tables, in order to resynchronise the primary and secondary systems once the database link is restored.
Preferably, the method, comprises using Documentum as the Document Management System for both the primary and secondary system. Preferably the method comprises of using the primary system for the user community to store their objects.
Preferably, the method comprises of using the secondary system as a testbed for changes which eventually need to be applied to the primary system. Preferably, the method comprises document data being added to the store and reference data modified within Documentum system tables in the primary Oracle system database, and wherein the recording step comprises the step of recording reference data from all primary system tables, save those holding server specific data. Preferably, the method requires the secondary system to be used as a testbed, for testing any changes before applying changes to the Primary system.
Preferably, the secondary system can be also used as a standby backup system in case of failure of the primary system. Preferably, the primary and secondary systems can be interchanged by adding the database triggers and procedures to both primary and secondary system databases and disabling the triggers and procedures in the designated secondary system. Preferably, the system comprises a Documentum document management system, and wherein the method is carried out additionally it is appreciated that the secondary server be used as a "Standby" this is comprehended by this invention.
Preferably, the recording, inserting, updating, deleting and providing steps and standard database constructs are executed by the execution of Oracle database software code.
Preferably, the recording, inserting, updating, deleting and providing steps and standard database constructs are executed by the execution of SQL Server database software code.
An example of the invention will now be described in detail with reference to the accompanying drawings in which;
Drawings Figure 1 is a schematic diagram of a system testbed, disaster recovery system according to a first embodiment of the invention that shows the network attached system before or after upgrading.
Figure 2 is a schematic diagram of a system testbed , disaster recovery system unattached during upgrade.
Description of the Invention Figure 1 shows a system testbed, or a online backup or disaster recovery system incorporating features which allow archiving , migration and deletion of objects 100 according to a first embodiment of the invention.
It allows the invaluable validation, testing of changes due to applying software / hardware patches, maintenance work, and upgrades on a real-time replica of the system.
It also allows recovery from the loss of the Primary system both in terms of corruption of the data to other causes, such as fire, flood.
In this embodiment a Document management system known as Documentum, is described however, the technique applied would work with any Object management System.
This system can be used for any object management system from a library to a document, records management system.
A typical Documentum system database has a number of system tables that store reference information and supplementary document information. The Replicated server is set up using the approach presented at the Documentum Conference "Upgrading to Documentum Si using the toggle "clone" method.
The advantages of this application are many firstly like its predecessor the application can be used to provide a system testbed, which eradicates the need to do any risky change on a live production system.
It provides a disaster recovery system capable of recovery from any disaster.
It provides return on investment as not only do the primary and secondary systems only share two mirrored objectstores, where at least three main objectstores would be normally required, the storage objectstore provides the capability of keeping these objectstores small by providing an archiving facility, also a facility to automatically recover deleted and overwritten files.
The primary system 101 is made up of a system database 108 including a number of system tables 112 and a objectstore 110. Document data files, i.e. the files created and edited etc by users, are themselves stored in the objectstore 110. Reference information about the data stored in the objectstore, i.e. information pointing to the physical document data and supplementary document information, i.e. the attributes of the types of documents stored are stored in the system database 108. The data sent to the system tables 112 is in the form of metadata.
As is known from conventional databases and document management systems, metadata contains information sufficient to enable a system to identify each file stored in the objectstore 110 sufficiently to enable authorised personnel to retrieve, protect and carry out the disposition of the files in the objectstore 110.
This information may include items such as: place of origin, file code/identification, key words for retrieval etc... Each time a file is edited, metadata is generated.
The metadata is used to update information in the system tables 112 corresponding to the file held in the system database. Therefore, if a document is added, updated or deleted, the metadata will provide information of this to the system database of the primary system 101 to enable the changes to be made.
The system database shown comprises a system table 112, access preservation tables 114, procedures corresponding to database triggers 111, e.g. update, delete and insert, in which procedures are executed in response to a user updating, deleting or inserting a document in the objectstore and store the original document overwritten , deleted , or the new document inserted to the new storage objectstore 118, and the transaction metadata into the transaction table 117 which includes at least the name of the system table ,the transaction that is carried out , and the date and time of the transaction .
Typically, the system tables 112 are added by the document management system on install and store all metadata in regards to a file into the database. The system tables are originally added by the document management system to the database of choice on installation. Typically, the access preservation tables 114 are new tables created to store transactions that occur on the system tables, that have been trapped by database triggers save those that uniquely identify the system. They are for capturing storing the information including identity into the access preservation tables the reference metadata inserted deleted and updated.
The replica system 102 comprises connection to the same mirrored objectstore 110, coupled to a replica system database 109. The objectstore of the primary system 101 and the replica system are connected 110, across a network fabric. The link enables the replica system to have the same contents in the objectstore 110.
Like the primary system database 108, the replica system database 109 comprises a system tables 112, access preservation tables 114, procedures 115 the database triggers 111 (when the primary system), e.g. update, delete and insert, and a transaction table 117.
A unique identifier is provided for uniquely identifying each of the primary and replica systems. In this respect, the unique identifier enables the network server to identify the relevant system. A unique identifier may be provided in each of the primary and replica system databases, or in just one.
While the link between the primary system database and the replica database is in tact, every time a change is made to the system database 108 of the primary system101, a corresponding change is made to the system database 109 of the replica system 102.
There are two ways in which the corresponding change can be made. In a first embodiment, when the system table of the primary system is updated, a procedure could be initiated automatically to make a corresponding update to the system table of the replica system database.
In an alternative embodiment, the corresponding change can be made in response to a change being made to the access preservation tables or the transaction table of the primary system. Thus, if a document is updated, the metadata that is sent to the system database to fire the "update" trigger is also copied to the system database of the replica system.
The primary system 101 is operably connected to a network fabric 103. The secondary replica system 102 is operably connected to a network fabric 103.
The primary system 101 has information loaded onto it, and is based on the first server 104. The secondary replica system 102 has information loaded onto it, and is based on a second server 105.
The first system 101 and the second system 102 are configured to allow a client computer operably connected to the network fabric 103 to locate information owned by the first system 101 and information owned by the second replica system 102.
The second replica system 102 replicates the first system 101. The system in this embodiment comprises a Document Management System residing on a server (Unix TM
or Windows 2000 TM server) 104, 105 comprising of a mirrored primary objectstore 110 storing the actual object data and a system databases 108 , 109 storing reference information pointing to the objects within the primary objectstore 110, supplementary information on the document, together with any system specific information.
A mirrored storage objectstore 118 initially empty is attached to both primary and secondary replicated systems 101, 102. The secondary storage objectstore 118 stores the changes to files or the file transactions occurring to the primary objectstore 110 including the identification information.
The second system's system database 109 is configured to mirror the information in that of the first system's system database 108 less a portion of the data which allows the second system 102 to be uniquely identified on the network fabric 103.
The objectstore 110 containing documents is connected to the network fabric 103. The objectstore is based on a Storage Area Network (SAN) or Filer 110 connected to the network fabric 103. The primary system's server 104 can be connected to the objectstore 110. The secondary system's server 105 can be connected to the same objectstore 110 .
The primary 101 and secondary system 102 share the same system objectstore 110. The primary and secondary system databases 108,109 are linked through the network fabric 103. Preferably, the method comprises of using Oracle Database software linking primary and secondary system databases 108, 109 on the network fabric by means of an Oracle database link command. Preferably, in the case of a SQL Server database this link between primary and secondary system databases is by a means of a SQL server linked server command.
Both the primary and secondary systems databases have the required access permissions to access, modify, insert or delete data in each other and are accessible to each other across the network fabric 103.
The method comprises document data being added to the objectstore and reference data modified within system tables 112 in the primary system database, and wherein the recording step comprises the step of recording reference data from all primary system tables 112, save those holding system specific data.
The primary system 101, in response to a insert, update, delete command, inserts, updates, deletes reference data to each of the system tables 112 affected for each particular transaction, and copy files (overwritten, deleted and inserted) over to the secondary objectstore 118.
The recording step comprises recording the reference data using at least one database trigger 111.
The recording step comprises recording the reference data using three database triggers 111 associated with each system table, excepting those tables, which allow the first system to be uniquely identified on the network fabric 103.
The method comprises adding a first database trigger associated with recording the changes after an insert command on each table 112, adding a second database trigger associated with recording the changes after an update command on each table and adding a third database trigger associated with recording the changes after a delete command on each database table, excepting those tables 112 that define the primary system 101 on the network fabric 103.
The method comprises performing identical changes, to that which can occur after an insert, update, delete command on each primary system database table 112 and are recorded within the respective database trigger 111 pertaining to that particular transaction to the identical replicated secondary system database table 112, by means of the salient SQL command contained within the three triggers on each of the primary database tables, the transfer, and application of the identical SQL command made possible only by the primary and secondary database systems being linked through a database link on the network fabric.
Preferably, the three triggers on each table in the primary database also record the changes on update, insert, delete to access-preservation tables and a single transaction table 117 for all changes on all tables.
Preferably, the single transaction table at least contains the group: the type of transaction ( i.e. update, delete, Insert), the system table on which the transaction is performed, the primary key of the table, and a Date-timestamp.
Preferably, the recording step comprises using at least one access-preservation table 114.
Preferably, the recording step comprises using a set of three access preservation tables for each primary system table to be mirrored in the secondary's database tables.
The method additionally comprises using a database stored procedure 115 to apply the changes and transactions recorded in the access-preservation tables 114 and transaction table, 117 to the secondary system should the database link be severed for any reason including that of maintenance to the secondary system on a time based input parameter, once the database link is restored and user input is halted temporarily.
A set of database procedures can be used in contingency the database link is severed for any reason to apply the changes and transactions recorded, in order, from the time the link was severed to the secondary system in order to synchronise the two systems once the database link is restored again, user input to be halted at this point until the procedures have finished running , then the system can be returned to the said automated transfer using the SQL command within the triggers on each table, with the user input recommenced.
On necessary upgrade being required user input is stopped on the primary system the link is broken between the replica and the production system. The mirror in the mirrored primary objectstore is broken allowing both the primary database and the replica database to be connected to the same yet separate copies of the primary objectstore.
User input is restarted on the primary system once the objectstore has been re-mirrored.
Whilst the replica system now unattached from the primary system can be upgraded and used for testing purposes.
Typically, using this method the users can upgrade the system whilst the users continue to enter changes into the primary system.
The replica system after successful testing is re-attached to the primary system after database testing and is toggled to become the primary system. The newly mirrored primary filestore being shared again.
Transactions in regards to testing are backed out using procedures and the information added to the primary system is applied to the replica system to resynchronise.
During corruption the data of the primary system, user data entered into this system can be rolled back if necessary to the point just before the corruption happened, using information stored in the storage objectstore and transaction table..
The method comprises input restriction until the primary and secondary system databases are re-synchronised.
Typically using this method, the secondary re lica system can be used if the first should fail in case of disaster. The objectstores would need to be mirrored off site and the transactions can be rolled back to a consistent point using the information held in the transaction table and mirrored storage objectstore.
On successful upgrade, recovery, the method comprises the contingency of applying the changes through at least a single database procedure using the combination transaction table and access-preservation tables, in order to re-synchronise the primary and secondary systems once the database link is restored.
The method, comprises using Documentum as the Document Management System for both the primary and secondary system. The method comprises of using the primary system for the user community to store their documents. The method comprises of using the secondary system as a testbed for changes which eventually need to be applied to the primary system or a disaster recovery system.
Preferably, the method comprises document data being added to the objectstore and reference data modified within Documentum system tables in the primary Oracle system database, and wherein the recording step comprises the step of recording reference data from all primary system tables, save those holding server specific data.
The method requires the secondary system to be used as a testbed, for testing any changes before applying changes to the Primary system 101.
The secondary system 102 can be also used as a standby backup, disaster recovery system in case of failure of the primary system 101.
The primary and secondary systems 101, 102 can be interchanged by adding the database triggers 111 and procedures 115 to both primary and secondary system databases 108 , 109 and disabling the triggers and procedures in the designated secondary system 102.
In this Embodiment the system 100 comprises a Documentum document management system, and wherein the method is carried out, and additionally it is appreciated that the secondary server be used as a "Standby" or Disaster Recovery system.
Fig 2 Shows 2000 the primary and secondary systems working independently of each other i.e unattached.
The recording, inserting, updating, deleting and providing steps and standard database constructs are executed by the execution of Oracle database software code.
The recording, inserting, updating, deleting and providing steps and standard database constructs are executed by the execution of SQL Server database software code.
The triggers are added to the relevant Documentum tables and they automatically fire to capture the salient information needed to apply a SQL command to keep two systems synchronised, where the secondary system is a replica of the first. This transfer is made possible by the setting up of a Database link between the primary and secondary database systems across the network fabric. In this case an Oracle Database link.
Permissions to the user schema or database on the secondary system need to be granted to the primary system's schema or database, and visa versa in case of the secondary system taking over the role of the primary.
Additionally, the database link could be set up using other databases ofcourse using the relevant construct, as I have some experience with Sql Server I can at least provide the database mechanism to link two Sql server databases together namely the "linked server"
construct. Though my experience is mainly within the Oracle database arena, most large database of any stature have to have similar constructs through common standards such as the SQL command language itself. So this method is very much mufti-database.
Typically because the system uses and stores delete and overwrite transactions both within the transaction table and the storage objectstore, the system can archive and recover such files.
Typically that the system can recycle documents erroneously deleted.
Below follows examples of the code necessary to transfer the reference metadata information.
Oracle Create Database link link name Connect to username Identified by password Using sqlnet string;
e.g.
Create Database link Secondary connect to secondary identified by secondary using 'backup database' It is appreciated that in the case of an Oracle delete trigger (a before or after) trigger can be used, as is comprehended by the invention.
Create or replace trigger keep del r trigger before delete on dm sysobject r for each row Begin delete from dm sysobject r@backup_database where r object id = :old.r object id Insertinto keep r table value (:old.r object id,:old.r_version label,:old.i folder id,:SYSDATE);
Insert into transaction table ('Delete','dm sysobject r',:old.r object id, SYSDATE);
EXCEPTION
when others then RAISE;
END;
The first command of the above trigger shows the SQL command and the "after delete row" trigger on the primary database automatically deletes the row in the secondary table. The insert statement is necessary in case the link is severed which can happen from time to time in case of maintenance, or in case of failure. As the above Oracle code shows this can be used in order to preserve the data in access preservation tables and the transaction table. In this case instead of using the link to transfer the necessary commands; the access- preservation tables and transaction table are used instead at a later point by database procedures that can run in the transactions in sequence to the Secondary Database, or visa versa. The triggers and procedures being "Enabled"
in the designated Primary.
Create or replace trigger keep ins r trigger after insert on dm sysobject r for each row Begin insert into dm sysobject r@backup_database(:new.r object id,:new.r version label,:new.i_folder id) Insertinto keep r table value (:new.r object id,:new.r version label,:new.i folder id:,SYSDATE);
Insert into transaction table ('Insert','dm sysobject r',:new.r object id, SYSDATE);
EXCEPTION
when others then RAI SE;
END;
Notice the new values are used meaning the values after the insert or update of a row and these are subsequently used to apply changes to the secondary database.
Create or replace trigger keep upd r trigger after update on dm sysobject r for each row Begin update dm sysobject r@backup_database set r version label = :new.r version label, i folder id = :new.i folder id where r object id = :new.r object id, Insert into keep r table value (:new.r object id,:new.r version label,:new.i folder id:,SYSDATE);
Insert into transaction table ('Update','dm sysobject r',:old.r object id, SYSDATE);
EXCEPTION
when others then RAISE;
END;
In the case of the dm sysobject r table above an example has been given of how the three triggers record the transactions for that table. This ofcourse can be extended to every table within the system. A "before row delete" is used in the example, meaning the data the is about to be deleted is captured the :old values meaning whatever was there previously is always captured.
A "after row insert" and "after row update" is preferably used, meaning that the data values of the row that have been, inserted or updated are actually captured notice the new values inserted are always used. On a "before insert " old values do not exist. This ensures that all salient and/or relevant information is captured.
It will be appreciated that an "after row delete" and "before row update /
insert" could also be used and are comprehended by the invention. In such a case, the old values are captured immediately upon the deletion and the new values upon update and insert.
An oracle database procedure or stored procedure is a piece of oracle execution code and carries out logical instructions. An oracle trigger is a piece of application code that can be applied to an oracle "table" (a storage unit like a filling cabinet) which when particular transactions are carried out on the table it fires automatically to execute the code within it.
This technique was also developed in CA2,531,714 to store all files added, deleted or overwritten, to allow the recovery from corruption and disaster recovery of the main primary system, however, the above application has an advantage over and above CA2,531,714 with less objectstores being required this as well as providing the capability of rolling back user data within the Testbed, in case of user inputting errors.
By incorporating the improved separation process developed in Application CA
2,531,996 , an improvement on CA 2,504,070, where an increases speed is realised, the application speed increases further.
CA 2,523,206 an enhancement of (2,531,996 and 2,504,070) is also incorporated in this application to allow archival and migration of files and recovery from erroneously deleted files.
Description of the Related Art Reference 1 a method developed and presented at the Documentum Conference in Lisbon May 2004, "Upgrading to Documentum Si using the Clean Build Toggle Clone Approach"
http://www.momentumeurope.com/conf track3.shtml .
In this method a replicated server ( document data within a system in a separate location, wherein the document data is stored in a system objectstore associated with a system database) was built, upgraded, plurality of data was achieved but only at a point in time in order to switch or toggle the new replica to become the production system. The data was copied from the objectstore using a full backup /restore on the Thursday night to the secondary backup store, on Friday night the Primary production server was shutdown and incremental backup and database export taken and these applied to the secondary server.
This step ensured the plurality of the data for the point in time when after testing a switch could be made. This method forms one of the foundation stones of this Invention, however, suffers from the fallback that the two systems are only in sync for a point in time.
The second Reference is co-pending CA2,504,070 , however within this application I
intend to use the improved version co-pending CA2,531,996, both these applications identify and separate the Deleted and Overwritten metadata in regards to documents deleted or overwritten. These allow individual transactions to be tracked and recovered.
The third reference is: CA 2,523,206 which is an improved version of Prior Application CA 2,506,756 as the concepts of delete archiving and migration are used within this application.
The fourth reference is CA2,531,714 to store all files added, deleted or overwritten, to allow the recovery from corruption and disaster recovery of the main primary system, as this feature is being incorporated into CA,2,506,303 which forms the fifth reference.
The final reference is that of fellow inventor Sandeep Jain Oracle Corporation US5737601A. Who invented two way replication using a similar low level method in databases. However this invention does more than the above invention as it has to handle the transactions as related to a objectstore, and identify and separate documents.
Briefly here also to mention Netapps they simply take snapshots of data in order to replicate and do not achieve continuous synchronisation.
Advantages of this application This application combines the best features of all the prior applications to make a real-time disaster recovery system / Testbed that can rollback transactions.
The advantage of this rolling back transctions is that many runs of the data can be done, should the data be corrupted. It also allows some disaster recovery for the primary system. It improves CA 2,506,303 which provides continuous synchronicity, increased latency by sharing the same primary objectstore. This application further uses the concept of mirroring by not only mirroring the primary objectstore, but also the storage objectstore added specifically to record additions and changes to files.
Background of the Invention Many large companies use document management software, records management software. The purpose of such software is to help companies keep track of large volumes of objects in an organized way, so that objects can be easily stored, found and retrieved.
In many cases, there will be more than one version of a particular object.
Thus, version control is another aspect of most object management systems. Version control is an issue of particular importance in situations where different people are able to share objects and have shared access to the objects, including a shared right to independently modify the obj ects.
In this Application a document management system will be described however the techniques applied here can be easily applied to many different areas.
This application extends further and increases the robustness of the earlier system testbed application providing a safe environment to test upgrades including Major Upgrades, allowing the users to continue entry whilst an upgrade of a system is being carried out.
It allows real stress testing to be carried out with the ability to rollback changes should that be necessary.
Before the co-pending application CA 2,506,303 was designed risks occasionally had to be taken upon the live production systems, reversing out changes was often messy and many people would wait until somebody else had upgraded.
The application centres on a document management system however an object management system could be treated in the same way.
Documentum TM is a document management system that comprises of three different layers(or technologies) sitting on top of an operating system (server based) such as Unix or Windows 2000 server, a system database, and a objectstore.
The layers comprise of a Documentum application server layer that sits on top of the database and serves Documentum client interfaces. The reference information (i.e. the information pointing to the physical document data) and supplementary document information (i.e. the attributes of the types of Documents stored) are stored in the database. The actual physical data is stored in a objectstore on either the server, a Storage area network (SAN) or Filer pointed to by the server.
One example of a company in which a document management software system would be useful is an engineering company that has many versions of the same part. When a client orders that part the company has to find the correct part version.
The document management system typically includes a system database that is associated with a objectstore. The objectstore stores the actual document data, while the system database stores reference information that points to the document within the objectstore.
Also, the system database typically stores supplementary document information regarding each document.
As part of the management of a document management system the system database and objectstore continue to grow in size. While this is a positive and desirable situation for the business as a whole, the company's data / Intellectual property is kept safe. This poses large problems for systems people who need to maintain, upgrade these vast systems.
The problem posed is also complicated by the range of different technologies involved.
The document management system having its own layers to manipulate the user entry and the separate stores of data namely the system database and the objectstore which need to be maintained consistently.
For example every company needs to maintain the availability of these large systems stretching for some large companies into the terabytes of data. Hence recovery from disaster is important.
Should one of these systems experience problems, such as a performance problem or require a hardware or a Documentum, or a database software patch there is currently no satisfactory way of handling ,testing or validating these changes, nor providing archiving.
The changes can be tested on a test system but this system never mirrors a real live production system and Stress testing is seldom carried out (real load testing where sometimes the real problems of performance degradation are found).
Also documentum software, databases need maintaining, tuning and effects of small changes need to be adequately studied. Often its required to carry these requirements out on live production systems this risks lack of validation and stress testing and considerable periods of problems, or downtime if the patch applied fixes one scenario but breaks another, or when a mistake gets made.
This is unacceptable for most businesses, as some changes cannot be reverted.
With regards to major upgrades until very recently, most companies still preferred to completely write a new system and migrate the data across, some still do this, as the risk to their current system is so great.
This invention caters for major upgrades, however, here it is advisable to sever the connection between the servers and use a copy of the objectstore for the secondary system and use the approach as was presented by myself at the Documentum Conference in Lisbon May 2004, "Upgrading to Documentum Si using the Clean Build Toggle "Clone" Approach". The above approach was born out of a real-time critical problem.
The objectstore SAN storage that the Documentum management system was pointing to was running out of space.
Where this application surpasses its predecessor is that not only does it allow the entry of data whilst the mirrored system is being tested and upgraded as well as the resynchronisation with the main system as in the previous application. It also allows the rollback of transactions, during testing, disaster recovery, archiving and migration.
In this application a replicated server is used. The replica containing the proprietary document management system software and the system database containing reference data to point to the document data wherein said primary document data (mirrored) is associated with the secondary system database built, and hence plurality of data is achieved at any point in time that allows a switch or toggle to allow the new replicated server to become the production system on successful testing.
It is appreciated that this invention could additionally be used for the purpose of the secondary server acting as a "Standby" in case of failure of the first system's Server or in another capacity as a disaster recovery system.
Summary of the Invention This invention has two primary purposes the first is for testing, the second is for online backup or disaster recovery.
What is required is a method for safely validating changes that need to be applied to the system these could be software or hardware patches, minor or major upgrades.
More specifically as this has already been addressed by the previous application this application solves the further problem of rolling back the data changes in case re-testing is necessary.
The Testbed works as follows the network links are broken between primary and secondary as in fig 2.
The mirrored objectstores are broken allowing both the primary and secondary replicated system to connect to the primary; objectstore.
The upgrade is carried out then the secondary replica system.
On success there is a reconnection of the secondary replica system database to the primary objectstore (this has been re-mirrored) the test data can be removed from the database, the new mirrored primary objectstore not containing the mirrored files.
The invention envisages doing this testing safely with no risk by using a replicated secondary system as a system testbed which during normal operation constantly remains attached and in synchronous mode.
Should the link break, during a network outage the user input can be stopped, the replicated secondary system resynchronised.
On necessary upgrade being required user input is stopped the link is purposely broken between the replica and the production system. The mirror in the mirrored primary objectstore is broken allowing both the primary database and the replica database to be connected to the same yet separate copies of the primary objectstore.
User input is restarted on the primary system once the objectstore has been re-mirrored, the replica system now unattached to the primary system can be upgraded and used for testing purposes.
This enables users to experience only positive changes to the system documents being managed by a document management system. Whilst system professionals being able to break the mirrored primary objectstore, and the mirrored storage objectstore stop the transactions to the replicated secondary system database by severing the link can safely upgrade the system, stop user input temporarily re-attaching the replicated system database to the new mirror of the primary objectstore and resynchronise the replica using the transactions stored in the primary finally user input can be restarted .
On successful upgrade the secondary replica system is then switched or toggled to become the production system allowing, an upgrade to take place on the old primary system (the new secondary replicated system).
On failure of the upgrade the primary or production system is unaffected, and the primary system database, and primary document management system software are replicated to form a new secondary system and attached to the primary obj ectstore to ensure the primary system is secured for purposes of online backup.
In the meantime system professionals can resolve the problems on the original unattached secondary system, before carrying out the upgrade on the newly replicated secondary system.
The Primary and Secondary systems share a common objectstore which is mirrored.
They also share a specially created storage objectstore, which is also mirrored, this store is initially empty, but. If the secondary system and one of these mirrors is placed in an offsite location.
The primary system can be recovered on disaster, using the synchronisation techniques in previous applications.
Individual corrupted transactions and corrupted data can be rolled back or removed as all transactions are recorded at low level, including files. The identification and the separation of deleted and overwritten metadata and documents is key to this application as only if the discrete transactions are recorded against date and time of the transaction can they be matched with each other and to a point in date and time.
Files can also be archived to disk and recovered from disk using the storage objectstore which tracks all changes. Files or objects can be migrated with their metadata to other Document Management , or Record Management Systems.
The advantages of this application are many firstly like its predecessor the application can be used to provide a system testbed, which eradicates the need to do any risky change on a live production system. It provides a disaster recovery system capable of recovery from any disaster. It provides return on investment as not only does the primary and secondary system only share two mirrored file stores whereas at least three main objectstores would be normally required, the storage objectstore provides the capability of keeping these objectstore small by providing an archiving facility, also a facility to automatically recover deleted and overwritten files.
Accordingly, there is provided a method and system for providing a network attached system for real-time disaster recovery and upgrade testing wherein said system contains object management system software and a system database which contains reference data to point to the object within the system objectstore, during maintenance or disaster recovery requirement to the primary system, the secondary replicated system can be used as a test environment, the method comprising steps of:
(a) creating a replicated server containing the system in which the reference data in the system database points to the primary system objectstore providing a storage objectstore for changes to objects in the primary objectstore to be recorded and system database tables that mirror the primary, except those tables, containing reference information that uniquely identifies the replicated system from the primary production system on the network fabric;
(b) unattaching the replica from the primary system in case of disaster or upgrade (c) subsequently after either successful upgrade or recovery reattaching the replica as the primary system..
Preferably, the primary system is operably connected to a network fabric.
Preferably, the secondary system is operably connected to a network fabric. Preferably, the primary system has information loaded onto it, and is based on the first server.
Preferably, the secondary system has information loaded onto it, and is based on a second server.
Preferably, the first system and the second system is configured to allow a client computer operably connected to the network fabric to locate information owned by the first system and information owned by the second system. Preferably, the second system replicates the first system. Preferably, the system comprises a Object Management System residing on a server (Unix or Windows 2000 server) comprising of a objectstore storing the actual object data and a system database storing reference information pointing to the obj ects within a obj ectstore, supplementary information on the obj ects, together with system specific information. Preferably, the second system's system database is configured to mirror the information in that of the first system's system database less a portion of the data which allows the second system to be uniquely identified on the network fabric. Preferably, the objectstore containing documents is connected to the network fabric. Preferably, the objectstore is based on a Storage Area Network (SAN) or Filer connected to the network fabric and is mirrored.
Preferably, the primary system's server can be connected to the objectstore. Preferably, the secondary system's server can be connected to the same system objectstore it is appreciated that a separate objectstore for the primary system is used for storage of changes to the objects and this is comprehended by the Invention in this case the second separate object store would need to be mirrored so both the primary and second replicated databases could be attached to the object store, object storage store and be continuously applied to them throughout. Preferably, the primary and secondary system share the same system mirrored objectstore and mirrored storage object store. Preferably, the primary and secondary system databases are linked through the network fabric. Preferably, the method comprises of using Oracle Database software linking primary and secondary system databases on the network fabric by means of an Oracle database link command.
Preferably, in the case of a SQL Server database this link between primary and secondary system databases is by a means of a SQL server linked server command.
Preferably, both the primary and secondary systems databases have the required access permissions to access, modify, insert or delete data in each other and are accessible to each other across the network fabric. Preferably, the method comprises object data being added to the objectstore and reference data modified within system tables in the primary system database, and wherein the recording step comprises the step of recording reference data from all primary system tables, save those holding system specific data.
Preferably, the primary system, in response to a insert, update, delete command, inserts, updates,deletes reference data to each of the system tables affected for each particular transaction.
Preferably, the recording step comprises recording the reference data using at least one database trigger. Preferably, the recording step comprises recording the reference data using three database triggers associated with each system table, excepting those tables, which allow the first system to be uniquely identified on the network fabric.
Preferably, the method comprises adding a first database trigger associated with recording the changes after an insert command on each table, adding a second database trigger associated with recording the changes after an update command on each table and adding a third database trigger associated with recording the changes after a delete command on each database table, excepting those tables that define the primary system on the network fabric. Preferably, the method comprises performing identical changes, to that which can occur after an insert, update, delete command on each primary system database table and are recorded within the respective database trigger pertaining to that particular transaction to the identical replicated secondary system database table, by means of the salient SQL
command contained within the three triggers on each of the primary database tables, the transfer, and application of the identical SQL command made possible only by the primary and secondary database systems being linked through a database link on the network fabric. Preferably, the three triggers on each table in the primary database also record the changes on update, insert, delete to access-preservation tables and a single transaction table for all changes on all tables, the procedures within these tables also copy the objects to the storage objectstore. Preferably, the single transaction table contains the group: the type of transaction ( i.e. update, delete, Insert), the system table on which the transaction is performed, the primary key of the table, and a Date-timestamp.
Preferably, the recording step comprises using at least one access-preservation table.
Preferably, the recording step comprises using a set of three access preservation tables for each primary system table to be mirrored in the secondary's database tables. Preferably, the method additionally comprises using a database stored procedure to apply the changes and transactions recorded in the access-preservation tables and transaction table, to the secondary system should the database link be severed for any reason including that of maintenance to the secondary system on a time based input parameter, once the database link is restored and user input is halted temporarily, it does this by using the transaction tables it also updates storage objectstore to add the objects inserted and delete overwrite the objects that have been deleted and overwritten. Preferably, a set of database procedures can be used in contingency the database link is severed for any reason to apply the changes and transactions recorded, in order, from the time the link was severed to the secondary system in order to synchronise the two systems once the database link is restored again, user input to be halted at this point until the procedures have finished running , then the system can be returned to the said automated transfer using the SQL
command within the triggers on each table, with the user input recommenced.
Preferably, the set comprises a first access-preservation table to receive reference data recorded from the insert transaction on each system table, a second access-preservation table to receive reference data recorded from the update transaction on each system table, and a third access preservation table to receive reference data recorded from the delete transaction on each system table. Preferably, the method comprises input restriction until the primary and secondary system databases are re-synchronised. Preferably, the method comprises the contingency of applying the changes through at least a single database procedure using the combination transaction table and access-preservation tables, in order to resynchronise the primary and secondary systems once the database link is restored.
Preferably, the method, comprises using Documentum as the Document Management System for both the primary and secondary system. Preferably the method comprises of using the primary system for the user community to store their objects.
Preferably, the method comprises of using the secondary system as a testbed for changes which eventually need to be applied to the primary system. Preferably, the method comprises document data being added to the store and reference data modified within Documentum system tables in the primary Oracle system database, and wherein the recording step comprises the step of recording reference data from all primary system tables, save those holding server specific data. Preferably, the method requires the secondary system to be used as a testbed, for testing any changes before applying changes to the Primary system.
Preferably, the secondary system can be also used as a standby backup system in case of failure of the primary system. Preferably, the primary and secondary systems can be interchanged by adding the database triggers and procedures to both primary and secondary system databases and disabling the triggers and procedures in the designated secondary system. Preferably, the system comprises a Documentum document management system, and wherein the method is carried out additionally it is appreciated that the secondary server be used as a "Standby" this is comprehended by this invention.
Preferably, the recording, inserting, updating, deleting and providing steps and standard database constructs are executed by the execution of Oracle database software code.
Preferably, the recording, inserting, updating, deleting and providing steps and standard database constructs are executed by the execution of SQL Server database software code.
An example of the invention will now be described in detail with reference to the accompanying drawings in which;
Drawings Figure 1 is a schematic diagram of a system testbed, disaster recovery system according to a first embodiment of the invention that shows the network attached system before or after upgrading.
Figure 2 is a schematic diagram of a system testbed , disaster recovery system unattached during upgrade.
Description of the Invention Figure 1 shows a system testbed, or a online backup or disaster recovery system incorporating features which allow archiving , migration and deletion of objects 100 according to a first embodiment of the invention.
It allows the invaluable validation, testing of changes due to applying software / hardware patches, maintenance work, and upgrades on a real-time replica of the system.
It also allows recovery from the loss of the Primary system both in terms of corruption of the data to other causes, such as fire, flood.
In this embodiment a Document management system known as Documentum, is described however, the technique applied would work with any Object management System.
This system can be used for any object management system from a library to a document, records management system.
A typical Documentum system database has a number of system tables that store reference information and supplementary document information. The Replicated server is set up using the approach presented at the Documentum Conference "Upgrading to Documentum Si using the toggle "clone" method.
The advantages of this application are many firstly like its predecessor the application can be used to provide a system testbed, which eradicates the need to do any risky change on a live production system.
It provides a disaster recovery system capable of recovery from any disaster.
It provides return on investment as not only do the primary and secondary systems only share two mirrored objectstores, where at least three main objectstores would be normally required, the storage objectstore provides the capability of keeping these objectstores small by providing an archiving facility, also a facility to automatically recover deleted and overwritten files.
The primary system 101 is made up of a system database 108 including a number of system tables 112 and a objectstore 110. Document data files, i.e. the files created and edited etc by users, are themselves stored in the objectstore 110. Reference information about the data stored in the objectstore, i.e. information pointing to the physical document data and supplementary document information, i.e. the attributes of the types of documents stored are stored in the system database 108. The data sent to the system tables 112 is in the form of metadata.
As is known from conventional databases and document management systems, metadata contains information sufficient to enable a system to identify each file stored in the objectstore 110 sufficiently to enable authorised personnel to retrieve, protect and carry out the disposition of the files in the objectstore 110.
This information may include items such as: place of origin, file code/identification, key words for retrieval etc... Each time a file is edited, metadata is generated.
The metadata is used to update information in the system tables 112 corresponding to the file held in the system database. Therefore, if a document is added, updated or deleted, the metadata will provide information of this to the system database of the primary system 101 to enable the changes to be made.
The system database shown comprises a system table 112, access preservation tables 114, procedures corresponding to database triggers 111, e.g. update, delete and insert, in which procedures are executed in response to a user updating, deleting or inserting a document in the objectstore and store the original document overwritten , deleted , or the new document inserted to the new storage objectstore 118, and the transaction metadata into the transaction table 117 which includes at least the name of the system table ,the transaction that is carried out , and the date and time of the transaction .
Typically, the system tables 112 are added by the document management system on install and store all metadata in regards to a file into the database. The system tables are originally added by the document management system to the database of choice on installation. Typically, the access preservation tables 114 are new tables created to store transactions that occur on the system tables, that have been trapped by database triggers save those that uniquely identify the system. They are for capturing storing the information including identity into the access preservation tables the reference metadata inserted deleted and updated.
The replica system 102 comprises connection to the same mirrored objectstore 110, coupled to a replica system database 109. The objectstore of the primary system 101 and the replica system are connected 110, across a network fabric. The link enables the replica system to have the same contents in the objectstore 110.
Like the primary system database 108, the replica system database 109 comprises a system tables 112, access preservation tables 114, procedures 115 the database triggers 111 (when the primary system), e.g. update, delete and insert, and a transaction table 117.
A unique identifier is provided for uniquely identifying each of the primary and replica systems. In this respect, the unique identifier enables the network server to identify the relevant system. A unique identifier may be provided in each of the primary and replica system databases, or in just one.
While the link between the primary system database and the replica database is in tact, every time a change is made to the system database 108 of the primary system101, a corresponding change is made to the system database 109 of the replica system 102.
There are two ways in which the corresponding change can be made. In a first embodiment, when the system table of the primary system is updated, a procedure could be initiated automatically to make a corresponding update to the system table of the replica system database.
In an alternative embodiment, the corresponding change can be made in response to a change being made to the access preservation tables or the transaction table of the primary system. Thus, if a document is updated, the metadata that is sent to the system database to fire the "update" trigger is also copied to the system database of the replica system.
The primary system 101 is operably connected to a network fabric 103. The secondary replica system 102 is operably connected to a network fabric 103.
The primary system 101 has information loaded onto it, and is based on the first server 104. The secondary replica system 102 has information loaded onto it, and is based on a second server 105.
The first system 101 and the second system 102 are configured to allow a client computer operably connected to the network fabric 103 to locate information owned by the first system 101 and information owned by the second replica system 102.
The second replica system 102 replicates the first system 101. The system in this embodiment comprises a Document Management System residing on a server (Unix TM
or Windows 2000 TM server) 104, 105 comprising of a mirrored primary objectstore 110 storing the actual object data and a system databases 108 , 109 storing reference information pointing to the objects within the primary objectstore 110, supplementary information on the document, together with any system specific information.
A mirrored storage objectstore 118 initially empty is attached to both primary and secondary replicated systems 101, 102. The secondary storage objectstore 118 stores the changes to files or the file transactions occurring to the primary objectstore 110 including the identification information.
The second system's system database 109 is configured to mirror the information in that of the first system's system database 108 less a portion of the data which allows the second system 102 to be uniquely identified on the network fabric 103.
The objectstore 110 containing documents is connected to the network fabric 103. The objectstore is based on a Storage Area Network (SAN) or Filer 110 connected to the network fabric 103. The primary system's server 104 can be connected to the objectstore 110. The secondary system's server 105 can be connected to the same objectstore 110 .
The primary 101 and secondary system 102 share the same system objectstore 110. The primary and secondary system databases 108,109 are linked through the network fabric 103. Preferably, the method comprises of using Oracle Database software linking primary and secondary system databases 108, 109 on the network fabric by means of an Oracle database link command. Preferably, in the case of a SQL Server database this link between primary and secondary system databases is by a means of a SQL server linked server command.
Both the primary and secondary systems databases have the required access permissions to access, modify, insert or delete data in each other and are accessible to each other across the network fabric 103.
The method comprises document data being added to the objectstore and reference data modified within system tables 112 in the primary system database, and wherein the recording step comprises the step of recording reference data from all primary system tables 112, save those holding system specific data.
The primary system 101, in response to a insert, update, delete command, inserts, updates, deletes reference data to each of the system tables 112 affected for each particular transaction, and copy files (overwritten, deleted and inserted) over to the secondary objectstore 118.
The recording step comprises recording the reference data using at least one database trigger 111.
The recording step comprises recording the reference data using three database triggers 111 associated with each system table, excepting those tables, which allow the first system to be uniquely identified on the network fabric 103.
The method comprises adding a first database trigger associated with recording the changes after an insert command on each table 112, adding a second database trigger associated with recording the changes after an update command on each table and adding a third database trigger associated with recording the changes after a delete command on each database table, excepting those tables 112 that define the primary system 101 on the network fabric 103.
The method comprises performing identical changes, to that which can occur after an insert, update, delete command on each primary system database table 112 and are recorded within the respective database trigger 111 pertaining to that particular transaction to the identical replicated secondary system database table 112, by means of the salient SQL command contained within the three triggers on each of the primary database tables, the transfer, and application of the identical SQL command made possible only by the primary and secondary database systems being linked through a database link on the network fabric.
Preferably, the three triggers on each table in the primary database also record the changes on update, insert, delete to access-preservation tables and a single transaction table 117 for all changes on all tables.
Preferably, the single transaction table at least contains the group: the type of transaction ( i.e. update, delete, Insert), the system table on which the transaction is performed, the primary key of the table, and a Date-timestamp.
Preferably, the recording step comprises using at least one access-preservation table 114.
Preferably, the recording step comprises using a set of three access preservation tables for each primary system table to be mirrored in the secondary's database tables.
The method additionally comprises using a database stored procedure 115 to apply the changes and transactions recorded in the access-preservation tables 114 and transaction table, 117 to the secondary system should the database link be severed for any reason including that of maintenance to the secondary system on a time based input parameter, once the database link is restored and user input is halted temporarily.
A set of database procedures can be used in contingency the database link is severed for any reason to apply the changes and transactions recorded, in order, from the time the link was severed to the secondary system in order to synchronise the two systems once the database link is restored again, user input to be halted at this point until the procedures have finished running , then the system can be returned to the said automated transfer using the SQL command within the triggers on each table, with the user input recommenced.
On necessary upgrade being required user input is stopped on the primary system the link is broken between the replica and the production system. The mirror in the mirrored primary objectstore is broken allowing both the primary database and the replica database to be connected to the same yet separate copies of the primary objectstore.
User input is restarted on the primary system once the objectstore has been re-mirrored.
Whilst the replica system now unattached from the primary system can be upgraded and used for testing purposes.
Typically, using this method the users can upgrade the system whilst the users continue to enter changes into the primary system.
The replica system after successful testing is re-attached to the primary system after database testing and is toggled to become the primary system. The newly mirrored primary filestore being shared again.
Transactions in regards to testing are backed out using procedures and the information added to the primary system is applied to the replica system to resynchronise.
During corruption the data of the primary system, user data entered into this system can be rolled back if necessary to the point just before the corruption happened, using information stored in the storage objectstore and transaction table..
The method comprises input restriction until the primary and secondary system databases are re-synchronised.
Typically using this method, the secondary re lica system can be used if the first should fail in case of disaster. The objectstores would need to be mirrored off site and the transactions can be rolled back to a consistent point using the information held in the transaction table and mirrored storage objectstore.
On successful upgrade, recovery, the method comprises the contingency of applying the changes through at least a single database procedure using the combination transaction table and access-preservation tables, in order to re-synchronise the primary and secondary systems once the database link is restored.
The method, comprises using Documentum as the Document Management System for both the primary and secondary system. The method comprises of using the primary system for the user community to store their documents. The method comprises of using the secondary system as a testbed for changes which eventually need to be applied to the primary system or a disaster recovery system.
Preferably, the method comprises document data being added to the objectstore and reference data modified within Documentum system tables in the primary Oracle system database, and wherein the recording step comprises the step of recording reference data from all primary system tables, save those holding server specific data.
The method requires the secondary system to be used as a testbed, for testing any changes before applying changes to the Primary system 101.
The secondary system 102 can be also used as a standby backup, disaster recovery system in case of failure of the primary system 101.
The primary and secondary systems 101, 102 can be interchanged by adding the database triggers 111 and procedures 115 to both primary and secondary system databases 108 , 109 and disabling the triggers and procedures in the designated secondary system 102.
In this Embodiment the system 100 comprises a Documentum document management system, and wherein the method is carried out, and additionally it is appreciated that the secondary server be used as a "Standby" or Disaster Recovery system.
Fig 2 Shows 2000 the primary and secondary systems working independently of each other i.e unattached.
The recording, inserting, updating, deleting and providing steps and standard database constructs are executed by the execution of Oracle database software code.
The recording, inserting, updating, deleting and providing steps and standard database constructs are executed by the execution of SQL Server database software code.
The triggers are added to the relevant Documentum tables and they automatically fire to capture the salient information needed to apply a SQL command to keep two systems synchronised, where the secondary system is a replica of the first. This transfer is made possible by the setting up of a Database link between the primary and secondary database systems across the network fabric. In this case an Oracle Database link.
Permissions to the user schema or database on the secondary system need to be granted to the primary system's schema or database, and visa versa in case of the secondary system taking over the role of the primary.
Additionally, the database link could be set up using other databases ofcourse using the relevant construct, as I have some experience with Sql Server I can at least provide the database mechanism to link two Sql server databases together namely the "linked server"
construct. Though my experience is mainly within the Oracle database arena, most large database of any stature have to have similar constructs through common standards such as the SQL command language itself. So this method is very much mufti-database.
Typically because the system uses and stores delete and overwrite transactions both within the transaction table and the storage objectstore, the system can archive and recover such files.
Typically that the system can recycle documents erroneously deleted.
Below follows examples of the code necessary to transfer the reference metadata information.
Oracle Create Database link link name Connect to username Identified by password Using sqlnet string;
e.g.
Create Database link Secondary connect to secondary identified by secondary using 'backup database' It is appreciated that in the case of an Oracle delete trigger (a before or after) trigger can be used, as is comprehended by the invention.
Create or replace trigger keep del r trigger before delete on dm sysobject r for each row Begin delete from dm sysobject r@backup_database where r object id = :old.r object id Insertinto keep r table value (:old.r object id,:old.r_version label,:old.i folder id,:SYSDATE);
Insert into transaction table ('Delete','dm sysobject r',:old.r object id, SYSDATE);
EXCEPTION
when others then RAISE;
END;
The first command of the above trigger shows the SQL command and the "after delete row" trigger on the primary database automatically deletes the row in the secondary table. The insert statement is necessary in case the link is severed which can happen from time to time in case of maintenance, or in case of failure. As the above Oracle code shows this can be used in order to preserve the data in access preservation tables and the transaction table. In this case instead of using the link to transfer the necessary commands; the access- preservation tables and transaction table are used instead at a later point by database procedures that can run in the transactions in sequence to the Secondary Database, or visa versa. The triggers and procedures being "Enabled"
in the designated Primary.
Create or replace trigger keep ins r trigger after insert on dm sysobject r for each row Begin insert into dm sysobject r@backup_database(:new.r object id,:new.r version label,:new.i_folder id) Insertinto keep r table value (:new.r object id,:new.r version label,:new.i folder id:,SYSDATE);
Insert into transaction table ('Insert','dm sysobject r',:new.r object id, SYSDATE);
EXCEPTION
when others then RAI SE;
END;
Notice the new values are used meaning the values after the insert or update of a row and these are subsequently used to apply changes to the secondary database.
Create or replace trigger keep upd r trigger after update on dm sysobject r for each row Begin update dm sysobject r@backup_database set r version label = :new.r version label, i folder id = :new.i folder id where r object id = :new.r object id, Insert into keep r table value (:new.r object id,:new.r version label,:new.i folder id:,SYSDATE);
Insert into transaction table ('Update','dm sysobject r',:old.r object id, SYSDATE);
EXCEPTION
when others then RAISE;
END;
In the case of the dm sysobject r table above an example has been given of how the three triggers record the transactions for that table. This ofcourse can be extended to every table within the system. A "before row delete" is used in the example, meaning the data the is about to be deleted is captured the :old values meaning whatever was there previously is always captured.
A "after row insert" and "after row update" is preferably used, meaning that the data values of the row that have been, inserted or updated are actually captured notice the new values inserted are always used. On a "before insert " old values do not exist. This ensures that all salient and/or relevant information is captured.
It will be appreciated that an "after row delete" and "before row update /
insert" could also be used and are comprehended by the invention. In such a case, the old values are captured immediately upon the deletion and the new values upon update and insert.
An oracle database procedure or stored procedure is a piece of oracle execution code and carries out logical instructions. An oracle trigger is a piece of application code that can be applied to an oracle "table" (a storage unit like a filling cabinet) which when particular transactions are carried out on the table it fires automatically to execute the code within it.
Claims (34)
1. An apparatus for aiding real-time validation of system changes, comprising:
a primary system based on a first server; and a secondary system based on a second server, wherein the primary and secondary system are operable to be connected to a network fabric and attached to each other; and wherein business information loaded onto the primary system initially is replicated onto the secondary system whilst the primary and secondary systems are unattached; and further business information entered, altered, deleted and overwritten by the user base at real-time is continuously transferred from the primary system to the attached secondary system such that the secondary system is operable to achieve continuous synchronization and at real-time replicate the primary system; and wherein the secondary system can be resynchronized to changes to business information upon the primary system after any breakage of the link for any reason using at least one transaction table and at least one database procedure once the secondary system is reattached such that the secondary system continues to be continuously synchronized; and wherein the secondary system on successful upgrade validation is re-attached and interchanged to become the primary system.
a primary system based on a first server; and a secondary system based on a second server, wherein the primary and secondary system are operable to be connected to a network fabric and attached to each other; and wherein business information loaded onto the primary system initially is replicated onto the secondary system whilst the primary and secondary systems are unattached; and further business information entered, altered, deleted and overwritten by the user base at real-time is continuously transferred from the primary system to the attached secondary system such that the secondary system is operable to achieve continuous synchronization and at real-time replicate the primary system; and wherein the secondary system can be resynchronized to changes to business information upon the primary system after any breakage of the link for any reason using at least one transaction table and at least one database procedure once the secondary system is reattached such that the secondary system continues to be continuously synchronized; and wherein the secondary system on successful upgrade validation is re-attached and interchanged to become the primary system.
2. The apparatus according to claim 1, further comprising information location means operable to allow at least one client computer connected to the said network fabric to locate first information owned by the primary system and second information owned by the secondary system.
3. The apparatus according to any one of claims 1 to 2, wherein at least one of the first server and the second server comprises a document management system.
4. The apparatus according to claim 3, wherein the document management system comprises at least one objectstore operable to store document data.
5. The apparatus according to claim 3 or claim 4, wherein the document management system comprises a system database operable to store reference information pointing to the document data within the objectstore.
6. The apparatus according to any one of claims 3 to 5, wherein the document management system comprises supplementary information about the document data and system specific information.
7. The apparatus according to any one of claims 3 to 6, wherein the primary system and the secondary system share the same main objectstore.
8. The apparatus according to any one of claims 1 to 7, wherein the primary system comprises a primary database and the secondary system comprises a secondary database.
9. The apparatus according to claim 8, wherein the primary database and the secondary database comprise database tables.
10. The apparatus according to claim 7 and claim 9, wherein the primary database and the secondary database are linked using a database network communication layer.
11. The apparatus according to any one of claims 8 to 10, wherein the primary database and the secondary database are each operable to record and transfer changes to the database tables.
12. The apparatus as claimed in claim 1 wherein said breakage of the link includes any breakage during planned maintenance or upgrade to the secondary system, whilst the primary system continues to receive user input.
13. The apparatus according to any one of the claims 1 to 12, wherein the primary and secondary systems are interchangeable for any purpose.
14. The apparatus according to any of the claims 1 to 13, wherein the primary and secondary systems are interchangeable after successful upgrade of the secondary and resynchronization using the at least one database procedure and transaction table of the secondary system to the primary system.
15. A content management network-attached system according to claim 1 with native integration of a content management system and a storage system comprising:
a storage system for storing content data, content metadata, and business data.
a storage system for storing content data, content metadata, and business data.
16. The content management network-attached system of claim 1 further comprising:
a native unified replication system which automatically synchronizes replication of the content data, the content metadata, and business data.
a native unified replication system which automatically synchronizes replication of the content data, the content metadata, and business data.
17. The content management network-attached system according to claim 1 further comprising:
a native unified replication system which resynchronizes replication of the content data, the content metadata, and business data, on restoration of network attachment in the case of breakage of the attachment to the network attached system.
a native unified replication system which resynchronizes replication of the content data, the content metadata, and business data, on restoration of network attachment in the case of breakage of the attachment to the network attached system.
18. A method for aiding users , system professionals validate safely system changes during an upgrade by use of a replicated secondary system as a system testbed wherein the primary system contains document management system software further comprising a system database containing reference data to point to document data within a system objectstore, the method comprising:
creating a replicated server containing a secondary system replicating the primary in which the reference data in the secondary system database points to the primary system objectstore and system database tables in the secondary system mirror the database tables on the primary system based on a primary server, excepting those tables, containing reference information that uniquely identifies the secondary system from the primary system on a network;
determining that a insert, update, delete/overwrite command has been issued on tables within the primary system database; and transferring and recording the issued commands upon the primary system' database to the mirrored database system tables of the secondary system;
detaching and carrying out the upgrade and validation on the secondary system whilst allowing input upon the primary system to continue; and on successful validation, re-attachment and resynchronization the secondary system to the primary system interchanging the secondary system to become the new primary system.
creating a replicated server containing a secondary system replicating the primary in which the reference data in the secondary system database points to the primary system objectstore and system database tables in the secondary system mirror the database tables on the primary system based on a primary server, excepting those tables, containing reference information that uniquely identifies the secondary system from the primary system on a network;
determining that a insert, update, delete/overwrite command has been issued on tables within the primary system database; and transferring and recording the issued commands upon the primary system' database to the mirrored database system tables of the secondary system;
detaching and carrying out the upgrade and validation on the secondary system whilst allowing input upon the primary system to continue; and on successful validation, re-attachment and resynchronization the secondary system to the primary system interchanging the secondary system to become the new primary system.
19. The method according to claim 18, further comprising:
connecting the system objectstore containing documents to the said network ;
basing the system objectstore on a storage system;
connecting the primary system's server to the system objectstore; and connecting the secondary system's server to the same system objectstore.
connecting the system objectstore containing documents to the said network ;
basing the system objectstore on a storage system;
connecting the primary system's server to the system objectstore; and connecting the secondary system's server to the same system objectstore.
20. The method according to claim 18 or claim 19, further comprising:
using database software to link primary and secondary system databases on the said network by means of a database link command;
using a network layer on the said network; and allowing the primary database and the secondary database the required access to transfer and record necessary changes to both the primary and secondary' database tables.
using database software to link primary and secondary system databases on the said network by means of a database link command;
using a network layer on the said network; and allowing the primary database and the secondary database the required access to transfer and record necessary changes to both the primary and secondary' database tables.
21. The method according to claim 20, further comprising:
using a server database to provide the link between primary and secondary system databases;
using a server network layer on the said network by means of a linked server command or commonly known as a database link; and giving both the primary and secondary databases the required access to transfer and record the necessary changes to the database tables.
using a server database to provide the link between primary and secondary system databases;
using a server network layer on the said network by means of a linked server command or commonly known as a database link; and giving both the primary and secondary databases the required access to transfer and record the necessary changes to the database tables.
22. The method according to any one of claims 18 to 21, further comprising adding documents to the objectstore and allowing reference data to be continually added, modified and deleted within system tables in the primary system database by a user community.
23. The method according to any one of claims 18 to 22, further comprising recording reference data from all primary system tables, apart from the primary system tables holding specific data with regards to its definition as the primary system on the said network.
24. The method according to any one of claims 18 to 23, further comprising:
inserting, updating or deleting reference data in the primary system to each of the primary system tables in response to an insert, update or delete command; and recording the reference data using at least one database trigger.
inserting, updating or deleting reference data in the primary system to each of the primary system tables in response to an insert, update or delete command; and recording the reference data using at least one database trigger.
25. The method according to any one of claims 18 to 23, further comprising recording the reference data using three database triggers associated with each system table, apart from those tables that allow the primary system to be uniquely identified on the said network.
26. The method according to any one of claims 18 to 23, further comprising:
adding a first database trigger associated with recording the changes after an insert command on each table;
adding a second database trigger associated with recording the changes after an update command on each table; and adding a third database trigger associated with recording the changes after a delete command on each database table, excepting those tables that define the primary system on the said network.
adding a first database trigger associated with recording the changes after an insert command on each table;
adding a second database trigger associated with recording the changes after an update command on each table; and adding a third database trigger associated with recording the changes after a delete command on each database table, excepting those tables that define the primary system on the said network.
27. The method according to claim 25 or 26, further comprising performing identical changes, to that which occur after an insert, update, delete command on each primary system database table recorded within the respective secondary system database table, by means of the salient command contained within each of the three triggers placed on each of the primary database tables, save those that uniquely identify the primary and secondary database being linked through the database link on the said network.
28. The method according to claim 25 or claim 26, further comprising performing identical changes to that which occur after an insert, update or delete command on each primary system database table recorded within respective database trigger and access preservation tables and transferred to the secondary system by means of the salient command contained within a second set of triggers that reside on the access preservation tables, the primary and secondary' tables being linked through the database link on the said network.
29. The method according to any one of claims 18 to 27, further comprising using at least a single database procedure,
30. The method according to any one of claims 18 to 27, further comprising using a set of database procedures that can be enabled for use to transfer and apply the changes to the secondary's database system using the primary'access-preservation tables, and a single combined transaction table for each valid database system table, in the contingency the database link is severed for any reason, including planned maintenance to the secondary system, this once user input is halted and the database link is restored.
31. The method according to any one of claims 18 to 30, further comprising:
using the primary system for the user community to store their documents;
using the secondary system as a testbed for changes which eventually need to be applied to the primary system;
adding document data to the objectstore on a storage area network and reference data modified within document management system tables in the primary system database;
and recording reference data from all primary system tables, apart from those holding server specific data.
using the primary system for the user community to store their documents;
using the secondary system as a testbed for changes which eventually need to be applied to the primary system;
adding document data to the objectstore on a storage area network and reference data modified within document management system tables in the primary system database;
and recording reference data from all primary system tables, apart from those holding server specific data.
32. The method according to any one of claims 18 to 31, further comprising using the secondary system as a testbed, for testing any changes before applying changes to the primary system.
33. The method according to any one of claims 18 to 31, further comprising interchanging primary and secondary systems on successful upgrade by adding the database triggers and procedures to both primary and secondary system' databases and disabling the triggers and procedures in the designated secondary system.
34 A computer readable medium embodying database software code means for executing recording, inserting and providing steps as claimed according to any one of claims 11 to 33.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2545532 CA2545532A1 (en) | 2005-05-04 | 2006-05-03 | Method and system for providing network attached system for disaster recovery and upgrade testing |
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2,506,303 | 2005-05-04 | ||
| CA002506303A CA2506303A1 (en) | 2005-04-14 | 2005-05-04 | Method for validating system changes safely by use of a replicated system as a system testbed |
| CA 2523206 CA2523206A1 (en) | 2005-04-14 | 2005-10-12 | Method and system for preserving access to deleted and overwritten documents by means of a system recycle bin |
| CA2,523,206 | 2005-10-12 | ||
| CA 2545532 CA2545532A1 (en) | 2005-05-04 | 2006-05-03 | Method and system for providing network attached system for disaster recovery and upgrade testing |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2545532A1 true CA2545532A1 (en) | 2006-11-04 |
Family
ID=37310247
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2545532 Abandoned CA2545532A1 (en) | 2005-05-04 | 2006-05-03 | Method and system for providing network attached system for disaster recovery and upgrade testing |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2545532A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117874145A (en) * | 2024-03-13 | 2024-04-12 | 连连（杭州）信息技术有限公司 | Strong agreement method, device, equipment and storage medium for master-slave database |
| CN117874145B (en) * | 2024-03-13 | 2024-05-28 | 连连（杭州）信息技术有限公司 | Strong agreement method, device, equipment and storage medium for master-slave database |
-
2006
- 2006-05-03 CA CA 2545532 patent/CA2545532A1/en not_active Abandoned
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117874145A (en) * | 2024-03-13 | 2024-04-12 | 连连（杭州）信息技术有限公司 | Strong agreement method, device, equipment and storage medium for master-slave database |
| CN117874145B (en) * | 2024-03-13 | 2024-05-28 | 连连（杭州）信息技术有限公司 | Strong agreement method, device, equipment and storage medium for master-slave database |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11740974B2 (en) | Restoring a database using a fully hydrated backup | |
| US20060235905A1 (en) | Method and system for preserving real-time access to a system in case of a disaster | |
| US11561716B2 (en) | Fast migration of metadata | |
| US8712970B1 (en) | Recovering a database to any point-in-time in the past with guaranteed data consistency | |
| CA2626227C (en) | Apparatus and method for creating a real time database replica | |
| US6983295B1 (en) | System and method for database recovery using a mirrored snapshot of an online database | |
| US6934725B1 (en) | Management of file extent mapping to hasten mirror breaking in file level mirrored backups | |
| US8190572B2 (en) | High-availability and data protection of OLTP databases | |
| US20050071391A1 (en) | High availability data replication set up using external backup and restore | |
| EP3796174B1 (en) | Restoring a database using a fully hydrated backup | |
| US20060253500A1 (en) | Method for validating system changes by use of a replicated system as a system testbed | |
| US20060235904A1 (en) | Method for preserving access to system in case of disaster | |
| CN111427898A (en) | Continuous data protection system and method based on analysis of Oracle log | |
| US10922186B1 (en) | Method and system for implementing current, consistent, and complete backups by rolling a change log backwards | |
| GB2445367A (en) | Method for validating system changes by use of a replicated system as a system testbed | |
| EP1715425A2 (en) | Method and system for preserving access to a system in case of a disaster | |
| CA2506100C (en) | Method for preserving access to system in case of disaster | |
| CA2545532A1 (en) | Method and system for providing network attached system for disaster recovery and upgrade testing | |
| KR20180034901A (en) | System and method for real time data replication for high availability | |
| GB2445584A (en) | Database backup and retrieval using transaction records and a replicated data store | |
| GB2425376A (en) | Method and system for producing a data backup system of a primary system in a document management system | |
| CA2531714C (en) | A method and system for preserving access to a system in case of a disaster | |
| Malcher et al. | RMAN Restore and Recovery | |
| Kuhn et al. | RMAN Restore and Recovery | |
| Kuhn et al. | Chapter 16 User-Managed Backup and Recovery |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead | ||
| FZDE | Dead |
Effective date: 20121005 |