Note: Descriptions are shown in the official language in which they were submitted.
CA 02506100 2006-02-08
METHOD FOR PRESERVING ACCESS TO SYSTEM
IN CASE OF DISASTER
Field of Invention
The present invention relates to a method, system for allowing systems
professionals to
retrieve a document management system, quickly in a off site location in the
case of disaster.
Background of the Invention
Many large companies use document management software. The purpose of such
software is
to help companies keep track of large volumes of documents in an organized
way, so that
documents can be easily stored, found and retrieved. In many cases, there will
be more than
one version of a particular document. Thus, version control is another aspect
of most
document management systems. Version control is an issue of particular
importance in
situations where different people are able to share documents and have shared
access to the
documents, including a shared right to independently modify the documents.
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
filestore. The filestore
stores the actual document data, while the system database stores reference
information that
points to the document within the filestore. Also, the system database
typically stores
supplementary document information regarding each document.
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 filestore.
The layers comprise of a Documentum application server layer that sits on top
of the
1
CA 02506100 2006-02-08
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 filestore on either the server , a
Storage area network
(SAN) or Filer pointed to by the server.
As part of the management of a document management system the system database
and
filestore 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 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 layer to manipulate the user entry and the
separate stores
of data namely the system database and the filestore 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. Should one of
these systems
fail over currently, the best method requires re-installing the database and
document
management software and recovering from backup tapes, and database exports.
This at the
very least would take days. This is unacceptable for most businesses.
Imagine the effect of a flood in the computer room or an earthquake it would
mean total loss
for perhaps days at the very least. This invention conquers the problem of
synchronising the
various components, thereby giving peace of mind to many Businesses.
With regards to major upgrades until very recently , most companies still
preferred to
completely write a new system and migrate data across, some still do this as
the risk to their
current system is so great.
This changed somewhat due to a method developed and presented at the
Documentum
Conference in Lisbon May 2004, "Upgrading to Documentum 5i using the Clean
Build
2
CA 02506100 2006-02-08
Toggle Clone Approach". In this method a replicated server (document data
within a system
in a separate location, wherein the document data is stored in a system
filestore 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 filestore 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 foundation stone of this invention is File number is co-pending
application
number CA2,504,070, CTC002 submitted April 141h 2005 for Patent in Canada, in
which the
concept of access preservation tables to record the data is developed.
Another foundation of this invention is that systems can be "Networked" i.e.
joined together.
This invention is described below. The combination steps allow the data to be
synchronised
at many points in time allowing the ease of recovery required immediately
after a disaster.
What is required is a method for allowing systems professionals to retrieve a
document
management system, quickly in a off site location in the case of disaster.
Accordingly, there is provided a method for preserving access to document data
within a
system in a separate location, wherein said document data is stored in a
system filestore
associated with a system database, the system database containing reference
data to point to
the document data within the system filestore, In case of disaster to the
primary system such
as, earthquake, the secondary system can be used, the method comprising steps
of:
3
CA 02506100 2006-02-08
creating a replicated server containing the system database and filestore;
determining that a insert, update, delete command has been issued within the
primary production system database upon its system tables excepting those
containing
reference information that uniquely identifies the production system database
from its replica
on the network fabric;
transferring and recording the commands above to the database system tables of
the
replica based on time of earliest recorded data;
transferring recorded document data to secondary filestore using incremental
backup transfers;
Preferably, the primary system is operably connected to a network fabric.
Preferably, the
secondary system is operably connected to the 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 client computers
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
second system is
located in an off-site location. Preferably, the system comprises a Document
Management
System residing on a server (Unix or Windows 2000 server) comprising of a
filestore storing
the actual document data and a system database storing reference information
pointing to the
documents within a filestore, supplementary information on the document,
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.
4
CA 02506100 2006-02-08
Preferably, the filestore containing documents is connected to the network
fabric. Preferably,
the filestore is based on a Storage Area Network (SAN) or Filer connected to
the network
fabric. Preferably, the primary system's server can be connected to the
filestore. Preferably,
the secondary system's server can be connected to a separate filestore the
second filestore in
this case would need to have incremental backups from the first filestore to
be continuously
applied to it throughout perhaps at hourly intervals.
Preferably, the incremental backup is done every hour and automatically
applied to the
secondary filestore. 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 document data being added to the
filestore 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
CA 02506100 2006-02-08
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.
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.
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 and in
order, from the
6
CA 02506100 2006-02-08
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 access-preservation tables and the combined
transaction table
are stored on the secondary server in case of failure of the first.
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
documents.
Preferably, the method comprises of using the secondary system as a disaster
recovery
system. Preferably, the method comprises document data being added to the
filestore 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 secondary system can be also used as a disaster recovery
system in case of
failure of the primary system. Preferably, in the case of disaster the
secondary system can be
used, the system is synchronised by applying the latest incremental filestore
backup from the
7
CA 02506100 2006-02-08
primary filestore and applying it to the secondary and accessing the
transaction table and
access-preservation tables to either back out or insert transactions up to the
point of the
backup that haven't already been automatically transferred.
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 but is not the
primary purpose.
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 drawing in which;
Drawings
Figure 1 is a schematic diagram of a preserved system in of disaster according
to a first
embodiment of the invention.
Description of the Invention
Figure 1 shows a preserved system in case of disaster 100 according to a first
embodiment of
the invention that shows a secondary system in a offsite location and a
primary system which
allows the capture of relevant reference and supplementary document
information at the
exact time it is inserted, deleted or updated this by means of Oracle database
triggers placed
on each table except those needed to identify the primary and secondary as the
primary and
secondary on the network fabric and access-preservation tables, a single
transaction table and
incremental filestore backups. These triggers are added to the relevant
Documentum tables
and they automatically fire to capture and transfer the salient information.
Incremental
filestore backups are restored to the secondary system filestore.
8
CA 02506100 2006-02-08
According to one aspect of the Invention in the case of disaster the secondary
system 102 can
be used, the system is synchronised by applying the latest incremental backup
and accessing
the transaction table and access-preservation tables to either back out or
insert transactions up
to the time point of the incremental backup applied.
The primary system 101 is operably connected to a network fabric 103. The
secondary
system 102 is operably connected to the network fabric 103. The primary system
has
information loaded onto it, and is based on a first server 104. Preferably,
the secondary
system has information loaded onto it, and is based on a second server 105.
Preferably, the first system 101 and the second system 102 is configured to
allow client
computers operably connected to the network fabric 103 to locate information
owned by the
first system 101 and information owned by the second system 102. The second
system 102
replicates the first system 101. Preferably, the second system 102 is located
in an off-site
location. Preferably, the first and second system 102 comprises a Document
Management
System residing on a servers 104,105 (Unix or Windows 2000 server) comprising
of
filestores 106, 107 storing the actual document data and system databases
108,109 storing
reference information pointing to the documents within a filestores 106,107,
supplementary
information on the document, together with system specific information.
The second system's system database is configured to mirror the information in
that of the
first system's 101 system database 108 less a portion of the data which allows
the second
system 102 to be uniquely identified on the network fabric 103.
Preferably, the filestores 106,107 containing documents are connected to the
network fabric
103. Preferably, the filestores 106,107 are based on a Storage Area Network
(SAN) or Filer
connected to the network fabric 103. Preferably, the primary system's 101
server can be
connected to the filestore 106.
9
CA 02506100 2006-02-08
Preferably, the secondary system's server can be connected to a separate
filestore the second
filestore 107 in this case would need to have incremental backups from the
first filestore to be
continuously applied to it throughout perhaps at hourly intervals. Preferably,
the incremental
backup is done every hour and automatically applied to the secondary
filestore107. 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 103 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 108,109 is by a means of a SQL server
linked server
command. Preferably, both the primary and secondary systems databases 108,109
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.
Preferably, the method comprises document data being added to the filestore
106 and
reference data modified within system tables 110 in the primary system
database 108, and
wherein the recording step comprises the step of recording reference data from
all primary
system tables 110, save those holding system specific data. Preferably, the
primary system
101, in response to an insert, an update, or an delete command, inserts,
updates,deletes
reference data to each of the system tables affected for each particular
transaction. The
recording step comprises recording the reference data using at least one
database trigger 111.
Preferably, the recording step comprises recording the reference data using
three database
triggers 111 associated with each system table 110, excepting those tables,
which allow the
first system 101 to be uniquely identified on the network fabric 103.
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
CA 02506100 2006-02-08
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 110, excepting those tables that define the primary system 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 110 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 108, 109 being linked through a database link on the network
fabric 103.
Preferably, the three triggers on each table in the primary database 108 also
record the
changes on update, insert, delete to access-preservation tables 113 and a
single transaction
table 114 for all changes on all tables. Preferably, the single transaction
table 114 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.
The recording
step comprises using at least one access-preservation table 113. Preferably,
the recording
step comprises using a set of three access preservation tables for each
primary system table
110 to be mirrored in the secondary's database tables 112. The method
additionally
comprises using a database stored procedure 115 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. Preferably, a set of database procedures 115 can
be used in
contingency the database link is severed for any reason to apply the changes
and transactions
recorded and 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
11
CA 02506100 2006-02-08
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 access-preservation tables 113 and
the
combined transaction table 114 are stored on the secondary server in case of
failure of the
first. 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 documents. Preferably, the method comprises of
using the
secondary system as a disaster recovery system. Preferably, the method
comprises document
data being added to the filestore 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 secondary system can be also used as a disaster
recovery
system in case of failure of the primary system. Preferably, in the case of
disaster the
secondary system can be used, the system is synchronised by applying the
latest incremental
filestore backup from the primary filestore and applying it to the secondary
and accessing the
transaction table and access-preservation tables to either back out or insert
transactions up to
the point of the backup that haven't already been automatically transferred.
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 but is not the primary purpose. Preferably,
the recording,
12
CA 02506100 2006-02-08
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.
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 multi-database.
Below, there is shown sample code which can be extended to implement the
invention the
code is by no means complete but is sufficient to demonstrate the method. Code
is given for
Oracle only. One system table is taken dm_sysobject_r as example from the
Documentum
system though not all the columns are used for the example to merely show the
concept of
the three trigger a table system that is embodied by this invention. The
concept is however
explained.
The Invention can be embodied in a multi-operating system embodiment. The
invention can
be embodied in a multi-document management system embodiment. The invention
can be
implemented in a multi-database embodiment.
13
CA 02506100 2006-02-08
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.robject_id
Insert into keep_r_table value@backup_database
(:old.r object_id,:old.r version_label,:old.i_folder id,:SYSDATE);
Insert into transaction table@backup_database
('Delete','dm_sysobject_r',:old.r object_id,
SYSDATE);
EXCEPTION
when others then
RAISE;
END;
/
14
CA 02506100 2006-02-08
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. The triggers
and procedures
being "Enabled" in the secondary.
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
)
Insert into keep_r_table value@backup_database
(:new.r object_id,:new.r_version_label,:new.i_folder_id:,SYSDATE);
Insert into transaction table@backup_database
('Insert','dm_sysobject_r',:new.r object_id,
SYSDATE);
EXCEPTION
when others then
RAISE;
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.
CA 02506100 2006-02-08
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@backup_database
(:new.r object_id,:new.r version_label,:new.i_folder id:,SYSDATE);
Insert into transaction table@backup_database
('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.
16
CA 02506100 2006-02-08
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.
17
