WO2010032278A1 - ２相コミットによるデータ更新同期方法及びシステム - Google Patents

２相コミットによるデータ更新同期方法及びシステム Download PDF

Info

Publication number
WO2010032278A1
WO2010032278A1 PCT/JP2008/002561 JP2008002561W WO2010032278A1 WO 2010032278 A1 WO2010032278 A1 WO 2010032278A1 JP 2008002561 W JP2008002561 W JP 2008002561W WO 2010032278 A1 WO2010032278 A1 WO 2010032278A1
Authority
WO
WIPO (PCT)
Prior art keywords
database
update
data
priority
configuration information
Prior art date
Application number
PCT/JP2008/002561
Other languages
English (en)
French (fr)
Inventor
森本健司
嶋田邦昭
松原正純
松本安英
和田裕二
渡辺幸洋
勝野昭
Original Assignee
富士通株式会社
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2008/002561 priority Critical patent/WO2010032278A1/ja
Priority to JP2010529512A priority patent/JP5257455B2/ja
Priority to EP08808502.2A priority patent/EP2330511B1/en
Publication of WO2010032278A1 publication Critical patent/WO2010032278A1/ja
Priority to US13/044,797 priority patent/US8572047B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
    • G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1865—Transactional file systems

Definitions

  • the present invention relates to a distributed database, and more particularly, to a configuration information integrated database system that virtually integrates and manages a plurality of element databases that hold configuration information of an information system.
  • 2-phase commit commit control is performed separately for the first phase and the second phase.
  • the main site database sends an update request to the subordinate site database.
  • the database at the main site receives an answer indicating whether or not the update is possible from the database at the subordinate site, determines whether to commit or abort based on the response result, and notifies the subordinate site of the determination result.
  • the commit or rollback is executed according to the determination result received from the main site.
  • the database at the subordinate site can be updated and the data can be committed or rolled back from the time when the update request is received until the decision result is notified from the main site. It is required to maintain “secure state”.
  • FIG. 12 is a schematic diagram showing a first phase method of two-phase commit in a normal distributed database.
  • the database at the main site is the integrated database 1001
  • the database at the subordinate sites is the element database 1002 (1002-1, 1002-2).
  • the integrated database 1001 notifies the element database 1002-1 and the element database 1002-2 of an update request and inquires whether or not commit is possible (FIG. 12A). ).
  • the element database 1002-1 prepares for the update, and if the update is possible, the element database 1002-1 replies “commitment desired” to the integrated database 1001 while maintaining the secure state. If the element database 1002-2 cannot be updated, the element database 1002-2 responds “Rollback request” to the integrated database 1001.
  • the integrated database 1001 determines commit or rollback based on the response of the element database 1002. In this determination, if there is at least one rollback answer, the rollback is determined. The integrated database 1001 notifies the element database 1002 of the determination result. The element database performs a commit or rollback process according to the notification from the integrated database 1001. In the example of FIG. 12, the integrated database 1001 determines rollback, and notifies the element databases 1002-1 and 1002-2 of rollback. Upon receiving the notification, the element databases 1002-1 and 2002-2 execute a rollback process.
  • FIG. 13 is a diagram illustrating the overall configuration of the FCMDB system.
  • the FCMDB system 10 is a distributed database including a plurality of MDR (Management Data Repository) 12 (MDR1, MDR2,..., MDRn) and FCMDB11 that virtually integrates these MDR12.
  • MDR 12 is a CMDB (Configuration Management Database) that manages a CI (Configuration Item) that is a management unit of the IT system and associates each CI with each other.
  • CMDB 11 itself is also a CMDB.
  • the CI is implemented as configuration information (attribute information) related to resources configuring the IT system.
  • the CMDB manages the CIs in association with each other, and this relationship is called a relationship.
  • FIG. 14 is a diagram showing a distribution example of configuration information of the same resource in the FCMDB system.
  • the same resource configuration information may be registered in multiple MDRs.
  • configuration information related to the server A (Server A) is registered in the MDR 12-1 (MDR1) and the MDR 12-2 (MDR2).
  • the MDR 12-1 manages information on a CPU (Central Processing Unit) 31, a memory (Memory) 32, and a power supply (@power) 33 as configuration information of the server 30 (A).
  • the MDR 12-2 manages information on the CPU 31, the HDD (Hard Disk Drive) 34, and the power supply 33 as the configuration information of the server A. Therefore, in this example, among the components of the server A, the CPU 31 and the power source 33 are registered in the MDR 12-1 and the MDR 12-2 redundantly.
  • the server 30, the CPU 31, the memory 32, and the HDD 34 are individual CIs.
  • the FCMDB 11 receives the information registration request from the MDR 12 and manages the resource configuration information.
  • the FCMDB 11 may manage only the position information (pointer) of the configuration information, not the content of the configuration information (for example, “value”) itself.
  • the FCMDB 11 determines (1) whether there is an item managed redundantly for each item of the resources managed by the MDR 12-1 and the MDR 12-2. (2) If there is an overlapping item, which MDR 12 (3) Which MDR 12 is the main (MDR that manages the main information) and which MDR 12 is the sub (the sub information is managed) MDR) is held.
  • the operation management middleware reads the data managed in the form, and detects and monitors the actual managed machine via the network.
  • the MDR response may be significantly slower. This is because human judgment may be involved in the MDR response.
  • it waits for a response from the update processing request for a certain time or more, and when that time has passed, it is determined that the participant who sent the update processing request is abnormal. Such waiting for a reply is not preferable because the processing efficiency deteriorates.
  • FIG. 15 is a schematic diagram showing factors that cannot apply the two-phase commit to the MDR information update (data update) in the FCMDB system.
  • the FCMDB 11 inquires whether the MDR 12-1 and the MDR 12-2 can be updated (FIG. 15A).
  • the MDR 12-1 is in a non-secured state (corresponding to the above reason (1)) at the time when the update process is requested from the FCMDB 11. For this reason, the MDR 12-1 replies to the FCMDB 11 that it has already been updated and the information cannot be restored.
  • the MDR 12-2 requires manual work for information update processing, and takes a long time to respond to the FCMDB 11 (corresponding to the above reason (2)).
  • An object of the present invention is to enable synchronization at the time of data update in a configuration information integrated database system including an element database that cannot be kept in a secure state at the time of an update request so that the data consistency of the system can be maintained. It is.
  • the present invention is premised on an integrated management database system including a plurality of element databases that hold configuration information of an information system to be managed and an integrated database that integrally manages the plurality of element databases.
  • the integrated database of the integrated management database system includes a configuration information database that centrally manages configuration information held in the plurality of element databases, and each piece of configuration information data registered in the configuration information database.
  • Processing policy registration means for registering a processing policy in advance, and when updating data stored in the configuration information database, refer to the processing policy related to the update target data registered in the processing policy registration means, and update Update request means that sends an update request only to a high-priority element database that holds the data to be received, and receives an answer from the element database to which the update request means sent the update request, and based on the received answer result
  • Update availability determination means for determining whether or not to commit the update, and update availability determination means
  • an updating process communication means for indicating a commit or rollback to every element database that holds the updating data.
  • the processing policy is registered in advance for each data of the configuration information, and when updating the data, the processing policy registered for the data is referred to, and priority is given. Notify the update request only to the high-level element database. Therefore, by appropriately setting the processing policy, it is possible to avoid notifying the update request to the element database that cannot hold the secure state. Therefore, the data of the integrated management database system can be synchronously updated by applying the two-phase commit.
  • FIG. 7 is a diagram illustrating a data structure of configuration information expressed in an XML format in FIG. 6.
  • FIG. 8 is a diagram illustrating a data structure of meta information (configuration information registration source meta information) of the configuration information illustrated in FIG. 7. It is a figure which shows the data structure of the priority information stored in priority DB. It is a flowchart which shows the flow of the whole process of the update process part of a FCMDB system. It is a flowchart which shows the process of the two-phase commit control by an update availability determination part. It is a schematic diagram which shows the method of the 1st phase of the two-phase commit in a normal distributed database. It is a figure which shows the whole structure of a FCMDB system. It is a figure which shows the example of distribution of the structure information of the same resource in a FCMDB system. It is a schematic diagram which shows the factor which cannot apply a two-phase commit to the information update of MDR in a FCMDB system.
  • the present embodiment employs a two-phase commit in consideration of the data storage form specific to the FCMDB system of the following (1) and (2) in the synchronous update of data.
  • (1) In the FCMDB system, there is a case where the data stored in a plurality of MDRs do not need to match exactly.
  • (2) Data can be held in FCMDB, and in the worst case, only this data may be correct.
  • the FCMDB and the MDR manage information (configuration information) related to resources constituting the IT system in CI units.
  • the CI includes a record, and the record includes a property. That is, the property is a part of the record, and the record is a part of the CI.
  • the data stored in FCMDB and MDR are properties (attributes), records, and CIs from the finer granularity.
  • a processing policy is set for each data unit of CI, record, and property.
  • the processing policy for each CI, each record, and each property is referred to.
  • the processing policy for a finer data unit is referred to first.
  • the processing policy is “a predetermined policy regarding which MDR is prioritized and which MDR is used as a reference”.
  • the processing policy is described in a definite manner such as “MDR1 is preferred”, if it is described in a slightly abstract manner such as “Master MDR is preferred”, and further described by a combination of mathematical expressions. Sometimes it is done.
  • the term “processing policy” may be expressed by another term “priority information”. These two are essentially synonymous, and the processing policy focuses on “what to do”.
  • MDRs are ranked in “priority”, “reference”, and “others”, and information related to this ranking is priority information. That is, the priority information is information paying attention to the order for ordering the MDRs.
  • priority information is used when determining what to do.
  • the processing policy is as follows. (1) “Master MDR (Master MDR) opinion priority / reference”, “Specific MDR opinion priority / reference”, “FCMDB opinion priority / reference”
  • the master is an information source mainly used in FCMDB when there are a plurality of information sources for one property.
  • the master can change dynamically.
  • the MDR that should give priority to opinions is defined as “priority MDR”, and the MDR that should refer to opinions as “reference MDR”.
  • (2) Quantify the priority For example, a calculation formula for calculating a master MDR point, a specific MDR point, an FCMDB point, and a priority value is determined in advance, and the priority is determined using a predetermined calculation formula for each MDR. Is calculated.
  • the MDR with the highest priority or the MDR with the priority equal to or higher than a predetermined value is determined as the MDR (priority MDR) that should give priority to opinion.
  • the inquiry is not performed in the first phase of the two-phase commit, and only the processing confirmation result is notified in the second phase.
  • “Don't Care” (whichever is acceptable) is added to the response from the first phase participant (MDR). Regardless of whether or not an MDR can be updated, the MDR returns “Don't Care” when the entire process can proceed. This is effective when updating takes time.
  • ⁇ 2-phase commit processing policy As described above, the MDRs participating in the two-phase commit are classified into “priority MDR”, “reference MDR”, or “other MDR”, and a processing policy is determined for each MDR.
  • Opinion priority of priority MDR FCMDB sends an update request to priority MDR, and if even one response cannot be updated, rollback is performed as a whole.
  • the priority MDR does not need to maintain a secure state. This is because when there is only one priority MDR, the FCMDB uses the response result of the priority MDR as it is as a processing policy.
  • Reference Reference of Reference MDR FCMDB refers to the response when an update request is sent to the reference MDR, but may commit as a whole even if the response is not updateable. This is meaningful when there is no priority MDR or when the priority MDR returns “Don't Care”. This is because in either case, the priority MDR does not return non-updatable.
  • Other MDRs MDRs that are neither priority MDR nor reference MDR
  • the FCMDB does not send an update request to the other MDR, but only notifies the process decision in the second phase. Other MDRs do not need to maintain a secure state. In other words, since the update request is not sent to the other MDR in the first phase, it is not necessary for the other MDR to maintain the secure state.
  • the master MDR point, the specific MDR point, and the FCMDM point are determined in advance.
  • a calculation formula used for calculating the priority is also determined in advance.
  • Priority Master ⁇ 2 + MDRany + FCMDB (1)
  • Master Symbol representing the point of the master MDR MDRany: Symbol representing the point of any MDR FCMDB: Symbol representing the point of FCMDB
  • FCMDB means MDR (configuration information database) provided inside FCMDB.
  • the point may be defined by a wider / narrower data unit, and the calculation formula may be the above formula (1).
  • subtraction can be used in the calculation formula for priority calculation.
  • ⁇ MDR with priority n1 or higher is “priority MDR”
  • other MDR with priority n2 (n2 ⁇ n1) or higher is “reference MDR” ⁇
  • reference MDRs Two from the higher priority Is a priority MDR and the following three are reference MDRs (however, in this determination, MDRs that do not have data to be updated are excluded and counted) And so on.
  • Data units stored in the FCMDB and MDR are properties, records, and CIs from the finer ones.
  • a policy of “refer to a processing policy of a wider data unit” is also possible. For example, if the same processing policy as that record is applied to all properties of a record, the processing policy of each property should be set to “Refer to the processing policy of a wider data unit”. Good.
  • processing policy setting patterns for each data unit of CI can be considered. For example, (1) Set only for properties (2) Set only for records (3) Set only for CIs (4) Set for properties and records (5) Settings for all properties, records and CIs.
  • Whether the MDR is a priority MDR, a reference MDR, or another MDR is determined statically or dynamically according to a prior policy. For example, for a certain MDR, if the data of the MDR needs to match the data of the FCMDB system, a policy is set so that the MDR becomes “priority MDR”. Further, when it is not necessary to match the data of the FCMDB system, the MDR is set to “reference MDR” or “other MDR”. Actually, due to the nature of FCMDB, more MDRs are used as reference MDRs or other MDRs.
  • MDRs (1) to (3) exist as MDRs for storing the CI.
  • HR information management MDR Since it is information that becomes a personnel master, it is set as a priority MDR.
  • Operation management MDR This information is important as contact information at the time of failure, but it is set as a reference MDR because it has a lower priority than the HR master.
  • Asset management MDR Since it is not used as a contact, other MDR is set.
  • ⁇ Operation of two-phase commit ⁇ ⁇ Phase 1> a) If neither the priority MDR nor the reference MDR exists, it is regarded as a commit and the process proceeds to the second phase. b) When there are one or more priority MDRs or reference MDRs (1) The FCMDB issues an update request to the priority MDR and reference MDR, and receives an update availability response from them. (2) Analyze the response result and determine whether it can be updated. (3) Decide commit or rollback and move to the second phase.
  • FIG. 1 illustrates a case where the FCMDB makes an update request to the priority MDR and other MDRs in the first phase of the two-phase commit. It is a figure explaining operation
  • MDR 12-1 is “priority MDR”
  • MDR 12-2 is “other MDR”.
  • the FCMDB 11 inquires the priority MDR 12-1 whether it can be updated, but does not inquire any other MDR 12-2.
  • the priority MDR 12-1 that has received the update request inquiry from the FCMDB 11 is “consent (commit)”, “opposite (rollback)”, or “don't care” (Don ⁇ t Care) "is returned.
  • FIG. 2 is a diagram for explaining the operation when the FCMDB makes an update request only to the reference MDR in the first phase of the two-phase commit.
  • both MDRs 12-1 and 12-2 are “reference MDR”.
  • the FCMDM 11 inquires whether the reference MDRs 12-1 and 12-2 may be updated.
  • the reference MDRs 12-1 and 12-2 can make “consent (commit)”, “opposite (rollback)”, or “don't care” with respect to the above inquiry. Don ⁇ t Care) ”.
  • the reference MDR may update the data even if “rollback” is instructed from the FCMDB 11 in response to the “update possible” response. Therefore, the reference MDRs 12-1 and 12-2 do not need to maintain a secure state.
  • FIG. 3 is a diagram illustrating an example in which the first phase of the two-phase commit fails when there are a plurality of priority MDRs.
  • both MDRs 12-1 and 12-2 are priority MDRs.
  • the FCMDB 11 inquires the priority MDRs 12-1 and 12-2 as to “may be updated” in the same manner as in the case of FIG.
  • FIG. 3B if the priority MDR 12-1 is in the non-secure state, a response stating that “the data cannot be restored because it is already updated” cannot be returned to the FCMDB 11. Do.
  • the priority MDR 12-2 returns a “rollback request” response to the FCMDB 11.
  • the FCMDB 11 notifies the administrator of a warning “MDR12-1 (MDR1) cannot be rolled back” as shown in FIG. To do.
  • FIG. 4 is a diagram showing the overall configuration of the FCMDB system of this embodiment.
  • the FCMDB system 20 illustrated in FIG. 4 includes an FCMDB 100 and n MDRs 200 (MDR1, MDR2, MDR3,... MDRn).
  • the FCMDB 100 includes a configuration information DB (configuration information database) 110, an update / registration input unit 120, a registration processing unit 130, an update processing unit 140, a configuration information holding unit 150, a search input unit 160, and a search processing unit 170.
  • configuration information DB configuration information database
  • the configuration information database 110 is a database that integrally manages n MDRs 200.
  • the configuration information database 110 is stored in the MDR 200-1 (MDR1), MDR 200-2 (MDR2), MDR 200-3 (MDR3),... MDR 200-n (MDRn) in the manner shown in FIG. CI configuration information is integrated and managed.
  • the configuration information database 110 itself is also an MDR provided in the FCMDB system 20.
  • the configuration information database 110 can be any of “priority MDR”, “reference MDR”, and “other MDR”.
  • the FCMDB system 20 is regarded as a distributed database
  • the FCMDB 100 can be regarded as an integrated database
  • the n MDRs and the configuration information database 110 within the FCMDB 100 can be regarded as element databases.
  • the update / registration input unit 120 receives update / registration requests for configuration information (attribute information) related to CIs from all the MDRs 200, and appropriately distributes the requests to the respective processing units.
  • the update / registration input unit 120 sends a configuration information registration request to the registration processing unit 130. Also, a configuration information update request is sent to the update processing unit 140.
  • the registration processing unit 130 Upon receiving the configuration information registration request from the update / registration input unit 120, the registration processing unit 130 sends the registration information to the configuration information holding unit 150.
  • the update processing unit 140 uses the above-described two-phase commit protocol to obtain information (data) on the priority MDR and reference MDR holding the configuration information. Update synchronously. Further, the update processing unit 140 receives the priority information of the configuration information from the priority input person 210 and holds the priority information therein.
  • the configuration information holding unit 150 manages registration / update of configuration information in the configuration information database 110.
  • the configuration information holding unit 150 receives the configuration information to be registered in the configuration information database 110 from the registration processing unit 130 and registers the configuration information in the configuration information database 110.
  • the configuration information registered in the configuration information database 110 is updated in response to the two-phase commit control from the update processing unit 140.
  • the search input unit 160 receives a search request for configuration information from the search user 220.
  • the search input unit 160 requests the search processing unit 170 to search for the configuration information specified in the search request.
  • FIG. 5 is a diagram illustrating a configuration of the update processing unit 140 of the FCMDB 100.
  • the update processing unit 140 includes a priority input unit 1401, a priority database (priority DB) 1402, an update input unit 1403, a priority determination unit 1404, an update request communication unit 1405, and an update availability determination unit. 1406, an update processing communication unit 1407 is provided.
  • the priority input unit 1401 inputs priority information input by the priority input person 210 (see FIG. 4), and registers the priority information in the priority DB 1402.
  • This priority information is a “processing policy” regarding each CI managed by the system. This processing policy can be set in CI units, record units, and property units.
  • the priority DB 1402 is a database managed by the priority input unit 1401 and stores priority information (processing policy) for each CI managed by the system.
  • the update request communication unit 1405 is notified of the determination result.
  • the update request communication unit 1405 is in charge of the first phase of the data update by the two-phase commit protocol for the CI for which the update request has been made.
  • the update availability determination unit 1406 receives a response from the MDR to which the update request communication unit 1405 has sent the update request. This response is either “commit”, “rollback”, or “Don ⁇ t Care”. The update availability determination unit 1406 determines whether to commit or roll back the data update based on the response result received from the MDR. Then, the update result communication unit 1407 is notified of the determination result.
  • the update processing communication unit 1407 When the update processing communication unit 1407 receives a notification of commit determination from the update availability determination unit 1406, the update processing communication unit 1407 instructs the priority MDR, reference MDR, other MDR and configuration information holding unit 150 to commit. In addition, when a notification of rollback determination is received from the update availability determination unit 1406, the rollback is instructed to the priority MDR, reference MDR, and configuration information holding unit 150.
  • FIG. 6 is a diagram illustrating an example of an expression format of configuration information.
  • FIG. 6 is a diagram illustrating the configuration information of the server A in which the configuration information of the server A on which the three types of CPUs 1, 2, and 3 can be mounted is expressed in an XML (extensible markup language) format.
  • the CI of server A includes a record including three types of properties (attributes): name (name), model (model), and id (identifier).
  • the CI of each of the CPUs 1, 2, and 3 includes a record including five types of properties: name, model, socket (CPU socket), id (identifier), and frequency (operation frequency).
  • FIG. 7 is a diagram showing the data structure of the configuration information expressed in the XML format in FIG.
  • the configuration information described in the XML format shown in FIG. 6 is stored in the configuration information database 110 as a table having a data structure as shown in FIG.
  • Each row of the table 300 shown in FIG. 7 corresponds to each CI of the configuration information.
  • Each row of the table 300 stores items of a data class 301, a data ID 302, and attribute information 303.
  • the first line of the table 300 stores the CI 310 of the server A, and the second to fourth lines store the CIs 320, 330, and 340 of the CPUs 1, 2, and 3, respectively.
  • the data class 301 is an item indicating the classification of each CI.
  • the CI 310 in the first row of the table 300 is classified as “server”.
  • the CIs 310 to 340 stored in the second to fourth rows of the table 300 are all classified as “CPU”.
  • the data ID 302 is an item indicating a CI identification ID.
  • the attribute information 303 is an item for storing all attribute information included in each CI.
  • a set of attribute information stored in the item field of the attribute information 303 corresponds to a CI record.
  • Each of the CIs 310 to 340 stored in the table 300 illustrated in FIG. 7 is an example of a CI including only one record.
  • the CI of the present invention may be configured to include a plurality of records. In this case, the CI has a data structure including a plurality of attribute information 303, for example.
  • FIG. 8 is a diagram showing a data structure of meta information (configuration information registration source meta information) of the configuration information shown in FIG.
  • the configuration information registration source meta information is meta information indicating the registration source of the configuration information. This configuration information registration source meta information is held in the configuration information database 110.
  • the configuration information registration source meta information 400 illustrated in FIG. 8 is a table in which a data ID 401 and a configuration information registration source 402 are stored in each row.
  • the data ID 401 of the configuration information registration source meta information 400 is equal to the data ID 302 of the configuration information 300. That is, the configuration information registration source meta information 400 and the configuration information 300 are linked by the data ID.
  • the configuration information registration source 402 is information indicating a master MDR holding CI configuration information having a data ID 401 in the same row.
  • the configuration information is “CI configuration information including information that the CI exists”.
  • FIG. 9 is a diagram illustrating a data structure of priority information stored in the priority DB 1402.
  • the priority information is information for setting a processing policy for each data unit of the configuration information.
  • the priority information 500 illustrated in FIG. 9 is an example of priority information in which a processing policy is set for the CI.
  • the priority information 500 is a table in which two items of data ID 501 and processing policy 502 are stored in each row.
  • the data ID 501 is equal to the data ID 302 of the configuration information 300. That is, the configuration information 300 and the priority information 500 are linked by the data ID.
  • the processing policy 502 is a processing policy for CI data having the data ID 501 in the same row.
  • the priority information for setting the processing policy for the property is that the data ID item is “data ID” or “data ID + record name + property name”, and other structures are the same as the priority information 500.
  • the priority information for setting a processing policy for a record is the same as the priority information 500 except that the data ID item is “data ID” or “data ID + record name”. is there. That is, in the table shown in FIG. 9, it is possible to set the CI, record, or property processing policy simply by changing the item content of the data ID.
  • the CI processing policy classified as server A on the first line is CI processing classified as CPU 1, 2, and 3 on the second, third, and fourth lines, respectively.
  • the policy is stored.
  • the CI processing policy 502 classified as server A is “FCMDB reference”. This means that the configuration information database 110 of the FCMDB 100 is used as a reference MDR in updating the data of the CI classified as the server A.
  • the CI processing policy 502 classified as CPU 1 is “master MDR reference”. This means that the master MDR is used as the reference MDR in the CI data update classified by the CPU 1.
  • the CI processing policy 502 classified as CPU 2 is “MDR1 priority”.
  • MDR1 is set as the priority MDR in the CI data update classified as CPU2.
  • the CI processing policy classified by the CPU 3 is “the numerical value calculation formula for the priority of each MDR and the numerical value for the priority of each MDR calculated using the formula.
  • the description of the condition for determining the priority MDR is based on “the other CI” is “deterministic description” or “somewhat abstract description by role designation”.
  • the CI processing policy classified into the server A and the CI processing policy classified into the CPU 1 are “FCMDB reference” and “master MDR reference”, respectively, and there is a priority MDR. It is not an example.
  • the CI processing policy classified as CPU 2 is “MDR1 priority”, and is a definitive description in which only MDR1 (MDR200-1) is determined as the priority MDR.
  • the MDR point other than MDR1 is “0” when it is not the master, and “1” when it is the master.
  • the MDR 1 and FCMDB 100 MDR (configuration information holding unit 150) point is “5” as the base when managing the CI, and the MDR point that is the master of the two MDRs is “ 1 ”is defined to be set higher. Therefore, when the CI processing policy classified as CPU 3 is applied, when the MDR (configuration information holding unit 150) of the MDR 1 or the FCMDB 100 manages the CI, the MDR that is the master MDR among them is managed. Is set as the priority MDR, both are set as the priority MDR when neither is the master MDR, and when neither is managing the CI, the master that is the other MDR is set as the priority MDR.
  • the processing policy setting method is not limited to the example shown in FIG. In addition to the example shown in FIG. 9, the following setting method is conceivable. (1) Set a processing policy only for records (2) Set a processing policy only for properties (3) Set a processing policy for properties and records (4) Set a processing policy for all properties, records, and CIs
  • a processing policy for a wider (higher) data unit is applied to the processing policy for that data unit.
  • a processing policy for a property is not set, a processing policy for a record including the property as an element is used as the processing policy for the property. In this case, if no processing policy is set for the record, the CI processing policy including the record becomes the processing policy of the property.
  • the FCMDB system 20 of this embodiment sets the MDR 200 that cannot maintain a secure state as the reference MDR or the other MDR, and updates the configuration information by the two-phase commit control unique to the present embodiment as described above. Is possible.
  • this two-phase commit control is performed by the update processing unit 140 in the FCMDB 100.
  • the MDR 200 that cannot maintain the secure state is set as a reference MDR or other MDR.
  • This setting is performed by the priority input person 210.
  • the priority input person 210 inputs priority information to the update processing unit 140.
  • the priority information is input to the priority input unit 1401 of the update processing unit 140 and registered in the priority DB 1402 by the priority input unit 1401.
  • the units of the configuration information are classified into CI, record, and property in descending order of granularity.
  • the CI is composed of one or a plurality of records
  • the record is composed of one or a plurality of properties.
  • the priority information of the present embodiment is composed of “data ID” and “processing policy”.
  • FIG. 10 is a flowchart showing an overall processing flow of the update processing unit 140 of the FCMDB system 20.
  • the priority determination unit 1404 refers to the processing policy of the property to be updated that is registered in the priority DB 1402 (step S11). Then, it is determined whether the property processing policy exists in the priority DB 1402 and the processing policy is the end (step S12).
  • “whether the processing policy is the end” means that the processing policy is not set to “refer to a processing policy of a wider data unit”. In other words, “the processing policy exists and is at the end” does not mean that the processing policy is “refers to a processing policy of a wider data unit” but, for example, “FCMDB reference”, “MDR1 priority” This means that the priority / reference FCMD or MDR is the content specifically specified.
  • step S12 the priority determination unit 1404 proceeds to step S13 if there is no processing policy for the property to be updated or if the processing policy is not the end (step S12, no). On the other hand, if “the property processing policy exists and is the end” (step S12, yes), the process proceeds to step S18.
  • step S13 the priority determination unit 1404 refers to the processing policy of the record to be updated (record including the property to be updated) registered in the priority DB 1402. Then, it is determined whether the processing policy of the record exists and the processing policy is the end (step S14). If the priority determination unit 1404 determines that the record processing policy does not exist or does not exist even if it exists (step S14, no), the process proceeds to step S15, and the record processing policy exists. If the record processing policy is the end (step S14, yes), the process proceeds to step S18.
  • step S15 the priority determination unit 1404 refers to the processing policy of the item to be updated (item including the property to be updated (CI)) registered in the priority DB 1402. And it is judged whether the processing policy of the item used as update object exists (step S16). If the priority determination unit 1404 determines that there is no processing policy for the item to be updated (step S16, no), the process proceeds to step S17, and if there is a processing policy for the item to be updated (step S16, yes). ) Proceed to step S18.
  • the priority determination unit 1404 determines that there is no processing policy for the item to be updated (step S16, no)
  • step S17 the priority determination unit 1404 determines that the processing policy of the property to be updated is “FCMDB priority”. Then, the process proceeds to step S18.
  • step 18 if the priority determination unit 1404 determines in step S12, S14, or S16 that “the processing policy exists and the processing policy is the end”, the processing policy that is the end is determined.
  • the processing policy To determine the MDR that will be the priority and reference.
  • the property, record, or CI processing policy is a numerical condition (priority calculation formula and priority or determination of MDR for reference based on the calculation result), the priority is calculated and the calculation is performed. Apply the results and conditions to determine the priority / reference MDR.
  • the priority determination unit 1404 determines whether the priority / reference MDR is only FCMDB (FCMDB configuration information database) (step S19). If it is determined that the priority / reference MDR is only FCMDB (step S19, yes), the process proceeds to step S21. If it is determined that the priority / reference MDR is not only FCMDB (step S19, no), the process proceeds to step S20.
  • FCMDB FCMDB configuration information database
  • step S20 the update request communication unit 1405 sends an update request to the priority / reference MDR and FCMDB, waits for a response, and proceeds to step S21.
  • step S21 the update availability determination unit 1406 receives a response from the MDR or FCMDB to which the update request communication unit 1405 has sent the update request, and determines update commit or rollback based on the response result. Then, the determination result (commit or rollback) is notified to all the MDRs (including the FCMDB configuration information holding unit) related to the update (step S22), and the process of this flowchart ends.
  • FIG. 11 is a flowchart showing the two-phase commit control process (details of the process in step S21 in FIG. 10) by the update availability determination unit 1406.
  • the update availability determination unit 1406 receives a response from all of the priority / reference MDRs sent by the update request communication unit 1405 (step S40). The update availability determination unit 1406 determines whether there is a priority MDR in the replied MDR (step S41). If it exists (step S41, yes), the process proceeds to step S42. If not present, the process proceeds to step S47.
  • step S42 the update availability determination unit 1406 refers to all priority MDR responses. Then, it is determined whether all the responses are “Don't Care” (step S43). If all the responses are not “Do n′t Care” (step S43, no), the process proceeds to step S44. If all the responses are “Don′t′Care” (step S43, yes), the process proceeds to step S47.
  • step S44 the update availability determination unit 1406 determines whether “not updateable” exists in the priority MDR response. If “not updateable” exists (step S44, yes), the rollback of the update process is notified to the configuration information holding units 150 of all MDRs 200 and FCMDBs 100 related to the update process (step S45). The process of the flowchart ends. On the other hand, if it is determined in step S44 that “not updateable” does not exist in the priority MDR response (step S44, no), the configuration information holding unit 150 of all the MDR 200 and FCMDB 100 related to the update process The commit of the update process is notified (step S46), and the process of this flowchart is terminated.
  • the update availability determination unit 1406 notifies the configuration information holding unit 150 of all the MDRs 200 and FCMDBs 100 related to the update process if there is at least one “update not possible” in the priority MDR response. To do.
  • step S47 the update availability determination unit 1406 refers to the reference MDR response. Then, it is determined whether “not updateable” exists in the response (step S48). If “not updateable” exists (step S48, yes), the configuration information of all the MDR 200 and FCMDB 100 related to the update process is held. The rollback of the update process is notified to the unit 150 (step S49), and the process of this flowchart ends. On the other hand, if “not updateable” does not exist (step S 48, no), the update processing commit is notified to the configuration information holding units 150 of all the MDR 200 and FCMDB 100 related to the update processing (step S 50). The process of the flowchart ends.
  • the update availability determination unit 1406 determines that all priority MDR responses are received even if the priority MDR does not exist among the participants in the update process or the priority MDR exists among the participants in the update process. Is “Don't Care”, refer to the reference MDR response. If even one of the responses of the reference MDR contains “not updateable”, the rollback is notified to all the MDR 200 and FCMDB 100 configuration information holding units 150 related to the update process.
  • the MDR set to non-priority does not need to reply to the update request from the FCMDB while maintaining the secure state. Therefore, in this embodiment, even if the configuration information database system includes an MDR that cannot respond to an update request from the FCMDB while maintaining a secure state, it is synchronized when the data is updated. It is possible to maintain data consistency. Further, in the present embodiment, when there is one priority MDR for certain data, it is not necessary for any MDR to maintain a secure state when updating the data. Further, in the present embodiment, when there is an MDR that seems to take a long time after receiving an update request, the MDR returns “Don't Care” at an early stage. Thus, the time required for the entire update process can be shortened.
  • the present invention is suitable for configuration management of an ITIL-compliant information system.

Abstract

　情報システムの構成情報を保持する複数の要素データベースと、それらを統合管理する統合データベースを備える統管理データベースシステムにおいて、更新依頼に対してセキュア状態を保ちながら返答できない要素データベースには２相コミットの第１相において更新依頼を通知しないようにすることで、データの更新時に同期を取り、システム内でのデータの整合性を維持する。

Description

[規則37.2に基づきISAが決定した発明の名称]　２相コミットによるデータ更新同期方法及びシステム
　本発明は、分散データベースに係り、特に、情報システムの構成情報を保持する複数の要素データベースを仮想的に統合管理する構成情報統合データベースシステムに関する。
　一般に、分散データベースにおいてデータを更新する際には、主サイトのデータベースと従属サイトのデータベースとの間で同期をとり、サイト間のデータの整合性を維持する必要がある。分散データベースにおいては、このデータ更新の同期は、２相コミットと呼ばれる方式で行なわれる。
　２相コミットにおいては、第１相と第２相に分けてコミット制御を行う。第１相においては、主サイトのデータベースが従属サイトのデータベースに更新依頼を送る。第２相においては、主サイトのデータベースが従属サイトのデータベースから更新可否の回答を受け取り、それらの回答結果に基づいてコミットかアボートかを決定し、その決定結果を従属サイトに通知する。従属サイトでは、主サイトから受け取った決定結果に従ってコミットまたはロールバックを実行する。この２相コミットにおいては、従属サイトのデータベースは、更新依頼を受け取った時点から主サイトから上記決定結果を通知されるまでの間、データを更新可能であっても、コミットもロールバックも可能な“セキュア状態”を保つことが求められる。
　図１２は、通常の分散データベースにおける２相コミットの第１相の方法を示す模式図である。図１２においては、主サイトのデータベースは統合データベース１００１となっており、従属サイトのデータベースは要素データベース１００２（１００２－１、１００２－２）となっている。
　図１２に示すように、第１相においては、まず、統合データベース１００１は、要素データベース１００２－１と要素データベース１００２－２に対して更新依頼を通知し、コミット可能か問い合わせる（図１２（Ａ））。要素データベース１００２－１は、更新の準備をし、更新が可能であれば、セキュア状態を保ちながら、「コミット希望」を統合データベース１００１に回答する。要素データベース１００２－２は、更新が不可であれば、「ロールバック希望」を統合データベース１００１に回答する。
　第２相において、統合データベース１００１は、要素データベース１００２の回答に基づいて、コミットまたはロールバックを決定する。この決定において、１つでもロールバックの回答があれば、ロールバックを決定する。統合データベース１００１は、決定結果を要素データベース１００２に通知する。要素データベースは、統合データベース１００１からの通知に従い、コミットまたはロールバックの処理を行なう。図１２の例の場合は、統合データベース１００１はロールバックを決定し、要素データベース１００２－１、１００２－２にロールバックを通知する。要素データベース１００２－１、２００２－２は、通知を受け取ると、ロールバックの処理を実行する。
　このように、通常の分散データベースにおいては、データを更新する際に、２相コミットにより、主サイトのデータベースと従属サイトのデータベースとの間で同期を取ることで、各サイトに保持されるデータ間の整合性を維持するようにしている。
　ところが、ＩＴシステム(Information Technology)の構成情報を仮想的に統合管理するＦＣＭＤＢ(Federated Configuration Management Database)システムにおいては、２相コミットを適用することは不可能である。
　ここで、ＦＣＭＤＢシステムについて説明する。ＦＣＭＤＢシステムは、ＩＴＩＬ(Information Technology Infrastructure Library)に準拠したデータベースシステムである。図１３は、ＦＣＭＤＢシステムの全体構成を示す図である。
　ＦＣＭＤＢシステム１０は、複数のＭＤＲ(Management Data Repository)１２（ＭＤＲ１、ＭＤＲ２、・・・、ＭＤＲｎ）とそれらのＭＤＲ１２を仮想的に統合するＦＣＭＤＢ１１を備える分散データベースである。ＭＤＲ１２は、ＩＴシステムの管理単位であるＣＩ(Configuration Item)と各ＣＩ間を関係付けて管理するＣＭＤＢ(Configuration Management Database)である。また、ＦＣＭＤＢ１１自体もＣＭＤＢである。ＣＭＤＢにおいては、ＣＩは、ＩＴシステムを構成するリソース(resource)に関する構成情報（属性情報）として実装される。ＣＭＤＢは各ＣＩ間を関係付けて管理しているが、この関係をリレーションシップ(relationship)と呼ぶ。
　図１４は、ＦＣＭＤＢシステムにおける同一リソースの構成情報の分布例を示す図である。
　ＦＣＭＤＢシステムにおいては、複数のＭＤＲに同一リソースの構成情報が重複して登録されている場合がある。図１４に示すＦＣＭＤＢシステム１０においては、サーバＡ(Server A)に関する構成情報がＭＤＲ１２－１（ＭＤＲ１）とＭＤＲ１２－２（ＭＤＲ２）に登録されている。ＭＤＲ１２－１は、サーバ３０（Ａ）の構成情報として、ＣＰＵ(Central Processing Unit)３１、メモリ(Memory)３２及び電源（@power）３３の情報を管理している。ＭＤＲ１２－２は、サーバＡの構成情報として、ＣＰＵ３１、ＨＤＤ(Hard Disk Drive)３４及び電源３３の情報を管理している。したがって、この例では、サーバＡの構成要素の内、ＣＰＵ３１と電源３３が、ＭＤＲ１２－１とＭＤＲ１２－２に重複して登録されている。ここで、サーバ３０、ＣＰＵ３１、メモリ３２及びＨＤＤ３４は個別のＣＩである。
　ＦＣＭＤＢ１１は、ＭＤＲ１２からの情報登録要求を受けて、リソースの構成情報を管理する。ＦＣＭＤＢ１１は、構成情報の内容（例えば「値」）そのものではなく、構成情報の位置情報（ポインタ）のみを管理する場合もある。ＦＣＭＤＢ１１は、ＭＤＲ１２－１とＭＤＲ１２－２が管理しているリソースの各項目について、（１）重複して管理されている項目があるか判定し、（２）重複する項目があれば、どのＭＤＲ１２に管理されている情報をその項目の「主情報」として保持するかどうか判断し、（３）どのＭＤＲ１２が主（主情報を管理するＭＤＲ）であり、どのＭＤＲ１２が副（副情報を管理するＭＤＲ）であるかのメタ情報を保持する。
　ＦＣＭＤＢシステム１０から情報を読み出して利用するものは「クライアント」と呼ばれる。また、ＭＤＲ１２の後方には、ＭＤＲ１２に対してデータを投入するデータプロバイダが存在する。これは、典型的には運用管理ミドルウェアである。運用管理ミドルウェアは、帳票で管理されているデータを読み取ったり、ネットワークを介して実際の管理対象マシンを検出・監視したりする。
　図１４に模式的に示すように、ＦＣＭＤＢシステムにおいては、同一リソースの構成情報を保持する複数のＭＤＲが存在する。このため、あるＭＤＲからＦＣＭＤＢに対して、あるリソースの構成情報の更新依頼があった場合、リソースの構成情報を保持する他のＭＤＲの構成情報も更新する必要がある。この更新を同期して行なおうとする場合、ＦＣＭＤＢシステムにおいては、２相コミットを利用できない。これは、ＦＣＭＤＢシステムにおいては、全てのＭＤＲが分散データベースへの参加を考慮しているとは必ずしも限らないからである。このため、下記（１）、（２）のような問題が発生する。
（１）ＦＣＭＤＢからの更新依頼に対して、セキュア状態を保ちつつ返答できないＭＤＲが存在する。
　これは、ＦＣＭＤＢシステムが分散データベースのように統一された環境ではなく、既存のデータストア（データベースでない場合もある）の寄せ集めであるためである。このため、ＦＣＭＤＢシステムにおいては、更新可能かどうかをセキュアに調べられないＭＤＲ（返答を優先すると、ロールバックできない状態でデータ更新を実行してしまう、逆にセキュア状態を優先するとデータ更新処理に着手できず返答もできなくなってしまうＭＤＲ）が存在する。
（２）ＦＣＭＤＢからの更新処理要求に対して、ＭＤＲの返答が大幅に遅い場合がある。
　これは、ＭＤＲの返答に人間の判断が介在する場合があるからである。２相コミットの場合、更新処理要求からの応答を一定時間以上待ち、その時間を過ぎた場合には、更新処理要求を送った参加者が異常であると判断するようになっているが、このような返答待ちは処理効率を悪化させるので好ましくない。
　図１５は、ＦＣＭＤＢシステムにおけるＭＤＲの情報更新（データ更新）に２相コミットが適用できない要因を示す模式図である。
　２相コミットの第１相において、ＦＣＭＤＢ１１は、ＭＤＲ１２－１とＭＤＲ１２－２に更新してもよいかどうかを問い合わせる（図１５（Ａ））。この例では、図１５（Ｂ）に示すように、ＦＣＭＤＢ１１から更新処理の依頼があった時点でＭＤＲ１２－１は非セキュア状態にある（上記理由（１）に該当）。このため、ＭＤＲ１２－１は、「もう更新してしまい、情報を元に戻すことができない」旨をＦＣＭＤＢ１１に返答する。また、ＭＤＲ１２－２は、情報更新の処理に人手の作業が必要であり、ＦＣＭＤＢ１１に応答するまでに大幅な時間を要する（上記理由（２）に該当）。
　以上述べたように、ＦＣＭＤＢシステムにおいては、データ（情報）更新の同期に２相コミットを利用することはできない。
　尚、通常の分散データベースにおいて、２相コミットによるデータ更新の処理時間を短縮する方法に関する発明が知られている（特許文献１参照）。
特開平６－１１９２７号公報
　本発明の目的は、更新依頼時にセキュア状態を保つことが不可能な要素データベースを含む構成情報統合データベースシステムにおいて、データの更新時に同期を取り、システムのデータの整合性を保持できるようにすることである。
　本発明は、管理対象となる情報システムの構成情報を保持する複数の要素データベースと、複数の要素データベースを統合管理する統合データベースを備える統合管理データベースシステムを前提とする。
　本発明の統合管理データベースシステムの前記統合データベースは、前記複数の要素データベースに保持されている構成情報を一元的に管理する構成情報データベースと、構成情報データベースに登録されている構成情報の各データについて、予め処理方針を登録する処理方針登録手段と、前記構成情報データベースに格納されているデータを更新する際、前記処理方針登録手段に登録されている更新対象のデータに関する処理方針を参照し、更新すべきデータを保持している優先度の高い要素データベースのみに更新依頼を送信する更新依頼手段と、更新依頼手段が更新依頼を送信した要素データベースからの回答を受信し、受信した回答結果に基づいて、更新をコミットするか否かを決定する更新可否決定手段と、更新可否決定手段の決定結果にしたがって、前記更新データを保持している全ての要素データベースにコミットまたはロールバックを指示する更新処理通信手段と、を備える。
　本発明の統合管理データベースシステムによれば、構成情報の各データについて予め処理方針を登録しておき、データを更新する際には、そのデータに対して登録されている処理方針を参照し、優先度の高い要素データベースのみに更新依頼を通知する。このため、処理方針を適切に設定することで、セキュア状態を保持できない要素データベースに対して更新依頼を通知することを回避できる。したがって、統合管理データベースシステムのデータを、２相コミットを適用して同期更新することができる。
ＦＣＭＤＢが、２相コミットの第１相において、優先ＭＤＲとその他ＭＤＲに対して更新依頼を行う場合の動作を説明する図である。 ＦＣＭＤＢが、２相コミットの第１相において、参考ＭＤＲのみに対して更新依頼を行う場合の動作を説明する図である。 優先ＭＤＲが複数ある場合に、２相コミットの第１相が失敗する例を説明する図である。 本実施形態のＦＣＭＤＢシステムの全体構成を示す図である。 ＦＣＭＤＢの更新処理部の構成を示す図である。 構成情報の表現形式の一例を示す図である。 図６においてＸＭＬ形式で表現されている構成情報のデータ構造を示す図である。 図７に示す構成情報のメタ情報（構成情報登録元メタ情報）のデータ構造を示す図である。 優先度ＤＢに格納される優先度情報のデータ構造を示す図である。 ＦＣＭＤＢシステムの更新処理部の全体的な処理の流れを示すフローチャートである。 更新可否判定部による２相コミット制御の処理を示すフローチャートである。 通常の分散データベースにおける２相コミットの第１相の方法を示す模式図である。 ＦＣＭＤＢシステムの全体構成を示す図である。 ＦＣＭＤＢシステムにおける同一リソースの構成情報の分布例を示す図である。 ＦＣＭＤＢシステムにおけるＭＤＲの情報更新に２相コミットが適用できない要因を示す模式図である。
　以下、図面を参照しながら、本発明の実施形態について説明する。
　まず、本実施形態の原理について説明する。
　［実施形態の原理］
本実施形態は、データの同期更新において、下記（１）、（２）のＦＣＭＤＢシステム特有のデータ格納形態を考慮した２相コミットを採用する。
（１）ＦＣＭＤＢシステムにおいては、複数のＭＤＲに格納されたデータが厳密に一致する必要がない場合もある。
（２）ＦＣＭＤＢでデータを持つことができ、最悪でも、このデータさえ正しければよい場合もある。
　本実施形態のＦＣＭＤＢシステムにおいて、ＦＣＭＤＢ及びＭＤＲは、ＣＩ単位で、ＩＴシステムを構成する資源に関する情報（構成情報）を管理する。ＣＩはレコードを含み、レコードはプロパティを含む。すなわち、プロパティはレコードの一部であり、レコードはＣＩの一部となっている。このため、ＦＣＭＤＢ及びＭＤＲに格納されるデータは、粒度の細かい方から、プロパティ（属性）、レコード、ＣＩとなる。
　｛２相コミットにおける問い合せ・集計の際の処理方針｝
　本実施形態では、ＣＩ、レコード、プロパティの各データ単位に処理方針を設定する。そして、２相コミットにおける問い合せ・集計の際には、ＣＩ毎・レコード毎・プロパティ毎の処理方針を参照する。このとき、より細かなデータ単位に対する処理方針を先に参照するようにする。
　ここで、処理方針とは、「どのＭＤＲを優先とし、どのＭＤＲを参考とするかについて、予め定められた方針」である。処理方針は、「ＭＤＲ１を優先」というように確定的に記述される場合、「マスタＭＤＲを優先」というように役割を指定してやや抽象的に記述される場合、さらには、数式の組み合わせによって記述される場合もある。以下の説明では、処理方針という用語が、「優先度情報」という別の用語で表現される場合もある。これら両者は、本質的には同義であり、「何をするか」に着目したのが処理方針である。本実施形態では、各データ単位について、ＭＤＲを「優先」、「参考」、「その他」に序列化しており、この序列化に関する情報が優先度情報である。すなわち、優先度情報は、ＭＤＲを序列化するための順位に着目した情報である。本実施形態では、「何をするか」を判断する際、優先度情報を利用する。
　処理方針は、例えば、以下のようなものである。
（１）「マスタとなっているＭＤＲ（マスタＭＤＲ）の意見優先／参考」、「特定のＭＤＲの意見優先／参考」、「ＦＣＭＤＢの意見優先／参考」
　ここで、マスタとは、１つのプロパティに対して複数の情報源があるとき、ＦＣＭＤＢにおいて主とされている情報源のことである。マスタは、動的に変化しうる。また、意見優先すべきＭＤＲを「優先ＭＤＲ」、意見参考すべきＭＤＲを「参考ＭＤＲ」と定義する。
（２）優先度を数値化する。例えば、マスタＭＤＲのポイント、特定ＭＤＲのポイント、ＦＣＭＤＢのポイント、及び優先度の値を計算するための計算式を予め決定しておき、各ＭＤＲについて、予め決定された計算式を用いて優先度の値を算出する。そして、例えば、優先度が最大のＭＤＲ、または優先度が所定値以上のＭＤＲを意見優先すべきＭＤＲ（優先ＭＤＲ）に決定する。
（３）優先ＭＤＲまたは参考ＭＤＲ以外のＭＤＲ（その他ＭＤＲと定義する）については、２相コミットの第１相において問い合せは行わず、第２相において処理の確定結果のみを通知する。
　｛２相コミットの第１相の回答の選択肢｝
　本実施形態においては、第１相の関係者（ＭＤＲ）の回答に、「Don´t Care（どちらでもよい）」を加える。あるＭＤＲの更新の可否に関わらず、全体の処理を進めてもよい場合、ＭＤＲは「Don´t Care」と返答する。これは、更新に時間がかかる場合に有効である。
　｛２相コミットの処理方針｝
　上述したようにして、２相コミットに参加するＭＤＲを、「優先ＭＤＲ」、「参考ＭＤＲ」または「その他ＭＤＲ」に分類し、各ＭＤＲ別に処理方針を定める。
（１）優先ＭＤＲの意見優先
　ＦＣＭＤＢは優先ＭＤＲに対して更新依頼を送り、その返答が１つでも更新不可であった場合は、全体としてロールバックを行う。優先ＭＤＲが１つだった場合、その優先ＭＤＲはセキュア状態を保つ必要がない。これは、優先ＭＤＲが１つだけの場合、ＦＣＭＤＢはその優先ＭＤＲの返答結果を、そのまま、処理方針とするからである。
（２）参考ＭＤＲの意見参考
　ＦＣＭＤＢは参考ＭＤＲに更新依頼を送った場合、その返答を参考とするが、返答が更新不可の場合でも、全体としてコミットしてよい。これは、優先ＭＤＲが無い場合や、優先ＭＤＲが「Don´t Care」を返した場合に意味を持つ。どちらの場合でも、優先ＭＤＲが更新不可を返すことはないからである。
（３）その他ＭＤＲ（優先ＭＤＲまたは参考ＭＤＲのいずれでもないＭＤＲ）
　ＦＣＭＤＢは、その他ＭＤＲに対しては、更新依頼を送らず、第２相における処理決定の通知のみを行う。その他ＭＤＲはセキュア状態を保つ必要がない。換言するならば、第１相においてその他ＭＤＲには更新依頼が送られてこないので、その他ＭＤＲはセキュア状態を保つ必要はない。
　｛処理方針を数式で記述した場合の優先ＭＤＲの決定方法｝
　本実施形態では、上述したように、マスタＭＤＲのポイント、特定ＭＤＲのポイント及びＦＣＭＤＭのポイントを予め定める。例えば、マスタＭＤＲのポイント＝５０、ＭＤＲ１のポイント＝３０、ＦＣＭＤＢのポイント＝２０とする（この場合、ＭＤＲ１以外のＭＤＲのポイントは“０”と定められる）。また、優先度の算出に使用する計算式も予め決めておく。
　例えば、計算式を、
　優先度＝Ｍａｓｔｅｒ×２＋ＭＤＲany＋ＦＣＭＤＢ　　　　・・・（１）
　　Ｍａｓｔｅｒ：マスタＭＤＲのポイントを表す記号
　　ＭＤＲany：任意のＭＤＲのポイントを表す記号
　　ＦＣＭＤＢ：ＦＣＭＤＢのポイントを表す記号
とする。
　上記式（１）を用いて各ＭＤＲｎの優先度を算出する際には、式（１）中のＭＤＲanyをＭＤＲnのポイントに置き換える。また、式（１）において、ＦＣＭＤＢは、ＦＣＭＤＢの内部に設けられるＭＤＲ（構成情報データベース）を意味する。
　上記以外にも、計算式は、より広い／狭いデータ単位で定義されるものを用い、ポイントは、Ｍａｓｔｅｒ＝５０、ＭＤＲ１＝３０、ＦＣＭＤＢ＝２０に指定する。または、ポイントは、より広い／狭いデータ単位で定義されるものを用い、計算式は上記式（１）を指定するなどの方法が考えられる。また、優先度算出の計算式には、加算と乗算以外にも減算を使用することも可能である。
　優先ＭＤＲ、参考ＭＤＲの判定方法としては、例えば、
・優先度が所定値ｎ１以上のＭＤＲは「優先ＭＤＲ」、それ以外で、優先度が所定値ｎ２（ｎ２＜ｎ１）以上のＭＤＲは「参考ＭＤＲ」とする
・優先度が高いほうから２つを優先ＭＤＲ、次の３つを参考ＭＤＲとする（但し、この判定の際には、更新対象のデータを持たないＭＤＲは除外して数える）
　などが考えられる。
　｛データ単位と処理方針｝
　ＦＣＭＤＢ及びＭＤＲに格納されるデータ単位は、細かいほうから、プロパティ、レコード、ＣＩとなる。この場合、細かい単位で（例えば、プロパティ単位）で設定された『ＭＤＲｎの意見優先』を採用した上で、より広いデータ単位の処理方針を参照」という方針も可能とする。これは、例えば、あるレコードの全プロパティについて、そのレコードと同様の処理方針を適用する場合、各プロパティの処理方針は「より広いデータ単位の処理方針を参照」とするように設定しておけばよい。
　ＣＩの各データ単位に対する処理方針の設定パターンには種々の形態が考えられる。例えば、
（１）プロパティのみに設定
（２）レコードのみに設定
（３）ＣＩのみに設定
（４）プロパティとレコードに設定
（５）プロパティ、レコード及びＣＩの全てに設定
　などの設定形態がある。
　｛優先ＭＤＲ、参考ＭＤＲ、その他ＭＤＲの決定の仕方｝
　ＭＤＲが、優先ＭＤＲ、参考ＭＤＲ、またはその他ＭＤＲのどれかになるかは、事前の方針に沿って静的・動的に決定される。例えば、あるＭＤＲについて、そのＭＤＲのデータがＦＣＭＤＢシステムのデータと一致する必要がある場合には、そのＭＤＲが「優先ＭＤＲ」となるように方針を立てる。また、ＦＣＭＤＢシステムのデータと一致する必要がない場合には、そのＭＤＲが「参考ＭＤＲ」または「その他ＭＤＲ」となるようにする。実際には、ＦＣＭＤＢの性質上、参考ＭＤＲまたはその他ＭＤＲとなるＭＤＲの方が多くなる。
　｛非セキュアＭＤＲの救済｝
　優先ＭＤＲが複数有り、その中に、２相コミットの第１相において非セキュア状態となっているＭＤＲが含まれている場合、データの同期更新が破綻する可能性がある。破綻しそうな場合の扱いとしては、
・破綻しないように方針を立てるものとし、特に扱わない
・破綻しそうな場合には警告を出し、人手での解決を促す
などの方策が考えられる。
　｛優先ＭＤＲ・参考ＭＤＲの用い方｝
　ここでは、ＣＩとして「管理ユーザ」を取上げ、そのプロパティとして「連絡先メールアドレス」がある場合を考える。ＦＣＭＤＢシステムにおいて、このＣＩを格納するＭＤＲとして、下記（１）～（３）のＭＤＲが存在するものとする。
（１）人事情報管理ＭＤＲ
　人事マスタとなる情報なので、優先ＭＤＲに設定する。
（２）運用管理ＭＤＲ
　障害時の連絡先となる情報であり重要であるが、人事マスタより優先度は低いので参考ＭＤＲに設定する。
（３）資産管理ＭＤＲ
　連絡先として用いることはないので、その他ＭＤＲに設定する。
　｛２相コミットの動作｝
　＜第１相＞
ａ）優先ＭＤＲも参考ＭＤＲもない場合には、コミットとみなし、第２相に移行する。
ｂ）優先ＭＤＲないしは参考ＭＤＲが１つ以上有る場合
（１）ＦＣＭＤＢは優先ＭＤＲ及び参考ＭＤＲに更新依頼を出し、それらから更新可否の返答を受け取る。
（２）上記返答結果を分析し、更新可否を判定する。
（３）コミットまたはロールバックを決定し、第２相に移行する。
　＜第２相＞
ａ）コミットの場合
　優先・参考・その他ＭＤＲに、更新通知を送る。
ｂ）ロールバックの場合
　優先・参考ＭＤＲに、ロールバック通知を送る。
　ここで、本実施形態における２相コミットの第１相の動作例を説明する
　図１は、ＦＣＭＤＢが、２相コミットの第１相において、優先ＭＤＲとその他ＭＤＲに対して更新依頼を行う場合の動作を説明する図である。
　図１において、ＭＤＲ１２－１は「優先ＭＤＲ」、ＭＤＲ１２－２は「その他ＭＤＲ」となっている。この場合、図１（Ａ）に示すように、ＦＣＭＤＢ１１は、優先ＭＤＲ１２－１に対しては「更新してもよいか」の問い合せを行うが、その他ＭＤＲ１２－２に対しては問い合せを行わない。図１（Ｂ）に示すように、ＦＣＭＤＢ１１から更新依頼の問い合せを受け取った優先ＭＤＲ１２－１は、ＦＣＭＤＢ１１に対して「同意（コミット）」、「反対（ロールバック）」または「どうでもいい（Don´t Care）」のいずれかを返答する。
　図２は、ＦＣＭＤＢが、２相コミットの第１相において、参考ＭＤＲのみに対して更新依頼を行う場合の動作を説明する図である。
　図２において、ＭＤＲ１２－１、１２－２は、共に、「参考ＭＤＲ」となっている。この場合、図２（Ａ）に示すように、ＦＣＭＤＭ１１は、参考ＭＤＲ１２－１、１２－２に対して更新してもよいか」の問い合せを行う。図２（Ｂ）に示すように、参考ＭＤＲ１２－１、１２－２は、上記問い合せに対して、ＦＣＭＤＢ１１に対して「同意（コミット）」、「反対（ロールバック）」または「どうでもいい（Don´t Care）」のいずれかを返答する。
上述したように、参考ＭＤＲは、「更新可」の返答に対し、ＦＣＭＤＢ１１から「ロールバック」を指示されてもデータの更新を行ってよい。このため、参考ＭＤＲ１２－１、１２－２はセキュア状態を保つ必要がない。
　図３は、優先ＭＤＲが複数ある場合に、２相コミットの第１相が失敗する例を説明する図である。
　図３において、ＭＤＲ１２－１、１２－２は、共に、優先ＭＤＲとなっている。図３（Ａ）に示すように、ＦＣＭＤＢ１１は上述した図１（Ａ）の場合と同様にして、優先ＭＤＲ１２－１、１２－２に対して「更新してもよいか」を問い合せる。このとき、図３（Ｂ）に示すように、優先ＭＤＲ１２－１は非セキュア状態となっていると、ＦＣＭＤＢ１１に対して「もう更新してしまいデータを元に戻すことはできない」旨の返答を行う。一方、優先ＭＤＲ１２－２は、ＦＣＭＤＢ１１に対して「ロールバック希望」の返答を行う。この場合、ＦＣＭＤＢ１１は、優先ＭＤＲ－１を救済するために、図３（Ｃ）に示すように、「ＭＤＲ１２－１（ＭＤＲ１）でロールバックが不可能である」旨の警告を管理者に通知する。
　［実施形態の構成］
　｛システムの全体構成｝
　図４は、本実施形態のＦＣＭＤＢシステムの全体構成を示す図である。
　図４に示すＦＣＭＤＢシステム２０は、ＦＣＭＤＢ１００とｎ個のＭＤＲ２００（ＭＤＲ１、ＭＤＲ２、ＭＤＲ３、・・・ＭＤＲｎ）を備えている。
　ＦＣＭＤＢ１００は、構成情報ＤＢ（構成情報データベース）１１０、更新・登録入力部１２０、登録処理部１３０、更新処理部１４０、構成情報保持部１５０、検索入力部１６０及び検索処理部１７０を備えている。
　構成情報データベース１１０は、ｎ個のＭＤＲ２００を統合管理するデータベースである。構成情報データベース１１０は、上述した図１３に示す方式で、ＭＤＲ２００－１（ＭＤＲ１）、ＭＤＲ２００－２（ＭＤＲ２）、ＭＤＲ２００－３（ＭＤＲ３）、・・・ＭＤＲ２００－ｎ（ＭＤＲｎ）に重複して格納されているＣＩの構成情報を統合管理している。
構成情報データベース１１０自体も、ＦＣＭＤＢシステム２０内に設けられたＭＤＲである。構成情報データベース１１０は、「優先ＭＤＲ」、「参考ＭＤＲ」または「その他ＭＤＲ」のいずれにもなりうる。ここで、ＦＣＭＤＢシステム２０を分散データベースとみなした場合、ＦＣＭＤＢ１００は統合データベース、ｎ個のＭＤＲ及びＦＣＭＤＢ１００内の構成情報データベース１１０は要素データベースとみなすことができる。
　更新・登録入力部１２０は、全てのＭＤＲ２００からＣＩに関する構成情報（属性情報）の更新・登録要求を受け付け、適宜、それらの要求を各処理部に振り分ける。更新・登録入力部１２０は、構成情報の登録要求を登録処理部１３０に送る。また、構成情報の更新要求を更新処理部１４０に送る。
　登録処理部１３０は、更新・登録入力部１２０から構成情報の登録要求を受け取ると、登録情報を構成情報保持部１５０に送る。
　更新処理部１４０は、更新・登録入力部１２０から構成情報の更新要求を受け取ると、上述した２相コミットプロトコルを用いて、構成情報を保持している優先ＭＤＲと参考ＭＤＲの情報（データ）を同期更新させる。また、更新処理部１４０は、優先度入力者２１０から構成情報の優先度情報を受け取り、この優先度情報を内部に保持する。
　構成情報保持部１５０は、構成情報データベース１１０に対する構成情報の登録・更新を管理する。構成情報保持部１５０は、登録処理部１３０から、構成情報データベース１１０に登録する構成情報を受け取り、構成情報を構成情報データベース１１０に登録する。また、更新処理部１４０から２相コミット制御を受けて、構成情報データベース１１０に登録されている構成情報の更新を行う。
　検索入力部１６０は、検索ユーザ２２０から構成情報の検索要求を受け付ける。検索入力部１６０は、検索要求で指示されている構成情報の検索を検索処理部１７０に依頼する。
　検索処理部１７０は、検索入力部１６０から依頼された構成情報を構成情報データベース１１０から読み出す。そして、その構成情報を検索ユーザ２２０に送る。
　｛ＦＣＭＤＭ１００の更新処理部１４０の構成｝
　図５は、ＦＣＭＤＢ１００の更新処理部１４０の構成を示す図である。
　図５に示すように、更新処理部１４０は、優先度入力部１４０１、優先度データベース（優先度ＤＢ）１４０２、更新入力部１４０３、優先度判定部１４０４、更新依頼通信部１４０５、更新可否判定部１４０６、更新処理通信部１４０７を備えている。
　優先度入力部１４０１は、優先度入力者２１０（図４参照）が入力した優先度情報を入力し、その優先度情報を優先度ＤＢ１４０２に登録する。この優先度情報は、システムが管理している各ＣＩに関する「処理方針」である。この処理方針は、ＣＩ単位、レコード単位、プロパティ単位で設定可能である。
　優先度ＤＢ１４０２は、優先度入力部１４０１により管理されるデータベースであり、システムが管理している各ＣＩについて、その優先度情報（処理方針）を格納している。　　更新入力部１４０３は、各ＭＤＲｉ（ｉ＝１～ｎ）からＣＩの更新要求を入力する。そして、その更新要求のあったＣＩを優先度判定部１４０４に通知する。
　優先度判定部１４０４は、更新入力部１４０３からＣＩを通知されると、優先度ＤＢ１４０２に登録されているＣＩの優先度情報（処理方針）を参照し、ＣＩを保持しているＭＤＲｋ（ｋ＝１～ｎ）について、各ＭＤＲｋが、「優先ＭＤＲ」、「参考ＭＤＲ」、または「その他ＭＤＲ」のいずれであるかを決定する。そして、その決定結果を更新依頼通信部１４０５に通知する。
　更新依頼通信部１４０５は、上記更新要求のあったＣＩに対する２相コミットプロトコルによるデータ更新の内、第１相の処理を担当する。更新依頼通信部１４０５は、優先度判定部１４０４から受け取った情報（上記決定結果）を基に、優先ＭＤＲ及び参考ＭＤＲに決定されたＭＤＲｍ（ｍ＝１～ｎ）に対して更新依頼を送信する。
　更新可否判定部１４０６は、更新依頼通信部１４０５が更新依頼を送ったＭＤＲから返答を受け取る。この返答は、「コミット」、「ロールバック」または「Don´t Care」のいずれかである。更新可否判定部１４０６は、ＭＤＲから受け取った返答結果を基に、データ更新をコミットまたはロールバックするか決定する。そして、その決定結果を更新処理通信部１４０７に通知する。
　更新処理通信部１４０７は、更新可否判定部１４０６からコミット決定の通知を受け取ると、優先ＭＤＲ、参考ＭＤＲ、その他ＭＤＲ及び構成情報保持部１５０にコミットを指示する。また、更新可否判定部１４０６からロールバック決定の通知を受け取ると、優先ＭＤＲ、参考ＭＤＲ及び構成情報保持部１５０にロールバックを指示する。
　｛構成情報の表現形式｝
　図６は、構成情報の表現形式の一例を示す図である。
　図６は、３種類のＣＰＵ１、２、３を実装可能なサーバＡの構成情報を、ＸＭＬ(extensible markup language)形式で表現したサーバＡの構成情報を示す図である。サーバＡのＣＩは、ｎａｍｅ（名前），ｍｏｄｅｌ（モデル），ｉｄ（識別子）という３種類のプロパティ（属性）を含むレコードを備えている。各ＣＰＵ１、２、３のＣＩは、ｎａｍｅ，ｍｏｄｅｌ，ｓｏｃｋｅｔ（ＣＰＵソケット），ｉｄ（識別子），ｆｒｅｑｕｅｎｃｙ（動作周波数）という５種類のプロパティを含むレコードを備えている。
　｛構成情報のデータ構造｝
　図７は、図６においてＸＭＬ形式で表現されている構成情報のデータ構造を示す図である。
　図６に示すＸＭＬ形式で記述された構成情報は、図７に示すようなデータ構造を有する表として、構成情報データベース１１０内に格納される。図７に示す表３００の各行が構成情報の各ＣＩに該当している。表３００の各行には、データクラス３０１、データＩＤ３０２及び属性情報３０３の各項目が格納される。表３００の１行目にはサーバＡのＣＩ３１０が、２行目～４行目には、それぞれ、ＣＰＵ１、２、３のＣＩ３２０、３３０、３４０が格納される。ここで、データクラス３０１は各ＣＩの分類を示す項目である。表３００の1行目のＣＩ３１０は「サーバ」に分類される。表３００の２～４行目にそれぞれ格納されるＣＩ３１０～３４０は、いずれも、「ＣＰＵ」に分類される。データＩＤ３０２は、ＣＩの識別ＩＤを示す項目である。属性情報３０３は、各ＣＩが備える全ての属性情報を格納する項目である。属性情報３０３の項目欄に格納されている属性情報の集合は、ＣＩのレコードに該当する。図７に示す表３００に格納されるＣＩ３１０～３４０は、いずれも、１レコードのみを備えるＣＩの例である。本発明のＣＩは、複数のレコードを備える構成であってもよい。この場合、ＣＩは、例えば、複数の属性情報３０３を備えるようなデータ構造となる。
　｛構成情報登録元メタ情報｝
　図８は、図７に示す構成情報のメタ情報（構成情報登録元メタ情報）のデータ構造を示す図である。
　構成情報登録元メタ情報は、構成情報の登録元を示すメタ情報である。この構成情報登録元メタ情報は、構成情報データベース１１０に保持される。図８に示す構成情報登録元メタ情報４００は、各行に、データＩＤ４０１と構成情報登録元４０２が格納される表となっている。構成情報登録元メタ情報４００のデータＩＤ４０１は、構成情報３００のデータＩＤ３０２に等しい。すなわち、構成情報登録元メタ情報４００と構成情報３００は、データＩＤによりリンクされている。
　構成情報登録元４０２は、同一行内のデータＩＤ４０１を有するＣＩの構成情報を保持しているマスタＭＤＲを示す情報である。図８に示す構成情報登録元メタ情報４００においては、その１行目にサーバＡの構成情報登録元メタ情報４１０が、２～４行目に、それぞれ、ＣＰＵ１(name=“１”)、２(name=“２”)、３(name=“３”)の構成情報登録元メタ情報４２０、４３０、４４０が格納されている。尚、構成情報とは、「ＣＩが存在するという情報も含む、ＣＩの構成情報」である。
　｛優先度情報｝
　図９は、優先度ＤＢ１４０２に格納される優先度情報のデータ構造を示す図である。
　優先度情報は、構成情報の各データ単位に処理方針を設定する情報である。図９に示す優先度情報５００は、ＣＩに対して処理方針を設定している優先度情報の例である。
図９に示す例では、優先度情報５００は、各行に、データＩＤ５０１と処理方針５０２という２つの項目が格納される形式の表となっている。データＩＤ５０１は、構成情報３００のデータＩＤ３０２に等しい。すなわち、構成情報３００と優先度情報５００は、データＩＤによってリンクがとられている。処理方針５０２は、同一行内のデータＩＤ５０１を有するＣＩのデータに対する処理方針である。プロパティに対して処理方針を設定する場合の優先度情報は、データＩＤの項目が「データＩＤ」もしくは「データＩＤ＋レコード名＋プロパティ名」となるだけで、その他の構造は優先度情報５００と同様である。また、レコードに対して処理方針を設定する場合の優先度情報は、データＩＤの項目が「データＩＤ」もしくは「データＩＤ＋レコード名」となるだけで、その他の構造は優先度情報５００と同様である。すなわち、図９に示す表において、データＩＤの項目内容を変更するだけで、ＣＩ、レコード、またはプロパティの処理方針を設定することが可能である。
　図９に示す優先度情報５００においては、１行目にサーバＡに分類されるＣＩの処理方針が、２、３、４行目に、それぞれ、ＣＰＵ１、２、３に分類されるＣＩの処理方針が格納されている。図９に示す例では、サーバＡに分類されるＣＩの処理方針５０２は「ＦＣＭＤＢ参考」となっている。これは、サーバＡに分類されるＣＩのデータ更新においては、ＦＣＭＤＢ１００の構成情報データベース１１０を参考ＭＤＲとすることを意味している。また、ＣＰＵ１に分類されるＣＩの処理方針５０２は「マスタＭＤＲ参考」となっている。これは、ＣＰＵ１に分類されるＣＩのデータ更新においては、マスタＭＤＲを参考ＭＤＲとすることを意味している。また、ＣＰＵ２に分類されるＣＩの処理方針５０２は「ＭＤＲ１優先」となっている。これは、ＣＰＵ２に分類されるＣＩのデータ更新において、ＭＤＲ１を優先ＭＤＲとすることを意味している。また、ＣＰＵ３に分類されるＣＩの処理方針５０２は「Ｍａｓｔｅｒ＝１，ＭＤＲ１＝５，ＦＣＭＤＢ＝５で、Ｍａｓｔｅｒ＋ＭＤＲａｎｙ＋ＦＣＭＤＢを評価し、値の一番大きいものを優先」となっている。このように、図９に示す例では、ＣＰＵ３に分類されるＣＩの処理方針のみが「各ＭＤＲの優先度の数値算出式と、その式を用いて算出された各ＭＤＲの優先度の数値に基づいて優先ＭＤＲを決定する条件の記述」となっており、その他のＣＩは「確定的な記述」または「役割指定による、やや抽象的な記述」となっている。
　図９に示す例では、サーバＡに分類されるＣＩの処理方針とＣＰＵ１に分類されるＣＩの処理方針は、それぞれ、「ＦＣＭＤＢ参考」、「マスタＭＤＲ参考」となっており、優先ＭＤＲが存在しない例となっている。また、ＣＰＵ２に分類されるＣＩの処理方針は、「ＭＤＲ１優先」となっており、ＭＤＲ１（ＭＤＲ２００－１）のみを優先ＭＤＲに決定するような確定的な記載となっている。また、ＣＰＵ３に分類されるＣＩの処理方針に記述されている優先度算出式においては、ＭＤＲ１以外のＭＤＲのポイントはマスタとなっていない場合は“０”、マスタとなっている場合は“１”であり、ＭＤＲ１とＦＣＭＤＢ１００のＭＤＲ（構成情報保持部１５０）のポイントはＣＩを管理している場合に基底として“５”、さらに２つのＭＤＲの内、マスタとなっているＭＤＲのポイントを“１”高く設定するように定義している。このため、ＣＰＵ３に分類されるＣＩの処理方針を適用すると、ＭＤＲ１またはＦＣＭＤＢ１００のＭＤＲ（構成情報保持部１５０）がＣＩを管理している場合はこれらの内、マスタＭＤＲとなっているＭＤＲの方が優先ＭＤＲに設定され、どちらもマスタＭＤＲとなっていない場合は両方が優先ＭＤＲに設定され、さらにどちらもＣＩを管理していない場合はその他のＭＤＲでマスタであるものが優先ＭＤＲに設定される。
　上述したように、処理方針の設定方式は、図９に示す例に限定されるものではない。図9に示す例以外にも、以下のような設定方式が考えられる。
（１）レコードのみに処理方針を設定
（２）プロパティのみに処理方針を設定
（３）プロパティとレコードに処理方針を設定
（４）プロパティ、レコード及びＣＩの全てに処理方針を設定
　本実施形態においては、あるデータ単位に処理方針が設定されていない場合には、そのデータ単位の処理方針には、より広い（より上位の）データ単位の処理方針が適用される。例えば、あるプロパティの処理方針が設定されていない場合には、そのプロパティの処理方針として、そのプロパティを要素として含むレコードの処理方針を用いる。この場合、そのレコードにも処理方針が設定されていない場合には、そのレコードを内包するＣＩの処理方針が、上記プロパティの処理方針となる。
　［動作］
　上記構成のＦＣＭＤＢシステムにおける構成情報の更新処理を説明する。
　ＦＣＭＤＢシステム２０においては、ある構成情報が、複数のＭＤＲ２００に重複して登録されている場合がある。また、複数のＭＤＲ２００の中には、セキュア状態を保ちながらデータを更新することができないものも存在する。したがって、ＦＣＭＤＢシステム２０内の複数のＭＤＲ２００は分散データベースを構築しているが、この分散データベースにおけるデータ更新は、通常の２相コミット制御では不可能である。
　本実施形態のＦＣＭＤＢシステム２０は、セキュア状態を保つことができないＭＤＲ２００を前記参考ＭＤＲまたは前記その他ＭＤＲに設定することで、上述したような本実施形態特有の２相コミット制御により、構成情報の更新を可能としている。本実施形態においては、この２相コミット制御は、ＦＣＭＤＢ１００内の更新処理部１４０によって実施される。本実施形態においては、セキュア状態を保つことができないＭＤＲ２００は、参考ＭＤＲまたはその他ＭＤＲに設定される。この設定は、優先度入力者２１０が行う。優先度入力者２１０は、優先度情報を更新処理部１４０に入力する。優先度情報は、更新処理部１４０の優先度入力部１４０１に入力され、優先度入力部１４０１により優先度ＤＢ１４０２に登録される。構成情報の単位は、粒度の大きい順に、ＣＩ、レコード、プロパティに分類される。ＣＩは１または複数のレコードから構成され、レコードは１または複数のプロパティから構成される。上述したように、本実施形態の優先度情報は、「データＩＤ」と「処理方針」から構成される。
　｛更新処理部１４０の全体フロー｝
　図１０は、ＦＣＭＤＢシステム２０の更新処理部１４０の全体的な処理の流れを示すフローチャートである。更新処理部１４０は、更新入力部１４０３が各ＭＤＲ２００－ｉ（ｉ＝１～ｎ）からＣＩの構成情報の更新要求を入力する毎に、図１０のフローチャートに示す処理を実行する。
　まず、優先度判定部１４０４は、優先度ＤＢ１４０２に登録されている更新対象となるプロパティの処理方針を参照する（ステップＳ１１）。そして、プロパティの処理方針が優先度ＤＢ１４０２に存在し、かつ、その処理方針が終端であるか判断する（ステップＳ１２）。ここで、「処理方針が終端か」とは、処理方針が「より広いデータ単位の処理方針を参照する」と設定されていないことを意味する。換言すれば、「処理方針が存在し、終端である」ということは、処理方針が「より広いデータ単位の処理方針を参照する」という内容ではなく、例えば、「ＦＣＭＤＢ参考」、「ＭＤＲ１優先」などのように、優先／参考となるＦＣＭＤまたはＭＤＲが具体的に指示されている内容であることを意味する。
　ステップＳ１２において、優先度判定部１４０４は、更新対象のプロパティの処理方針が存在しないか、または、その処理方針が終端でない場合には（ステップＳ１２、ｎｏ）ステップＳ１３に進む。一方、「プロパティの処理方針が存在し、かつ、終端である」ならば（ステップＳ１２、ｙｅｓ）ステップＳ１８に進む。
　ステップＳ１３において、優先度判定部１４０４は、優先度ＤＢ１４０２に登録されている更新対象となるレコード（更新対象のプロパティを含むレコード）の処理方針を参照する。そして、レコードの処理方針が存在し、かつ、その処理方針が終端であるか判断する（ステップＳ１４）。優先度判定部１４０４は、レコードの処理方針が存在しないか、または存在してもレコードの処理方針が終端でないと判断すれば（ステップＳ１４、ｎｏ）ステップＳ１５に進み、レコードの処理方針が存在し、かつ、レコードの処理方針が終端であれば（ステップＳ１４、ｙｅｓ）ステップＳ１８に進む。
　ステップＳ１５において、優先度判定部１４０４は、優先度ＤＢ１４０２に登録されている更新対象となる項目（更新対象のプロパティを含む項目（ＣＩ））の処理方針を参照する。そして、更新対象となる項目の処理方針が存在するか判断する（ステップＳ１６）。優先度判定部１４０４は、更新対象となる項目の処理方針が存在しないと判断すれば（ステップＳ１６、ｎｏ）ステップＳ１７に進み、更新対象となる項目の処理方針が存在すれば（ステップＳ１６、ｙｅｓ）ステップＳ１８に進む。
　ステップＳ１７において、優先度判定部１４０４は、更新対象のプロパティの処理方針を「ＦＣＭＤＢ優先」に決定する。そして、ステップＳ１８に進む。
　ステップ１８において、優先度判定部１４０４は、ステップＳ１２、Ｓ１４もしくはＳ１６において、「処理方針が存在し、かつ、その処理方針が終端である」と判断した場合には、終端となっている処理方針を適用して優先・参考となるＭＤＲを決定する。この場合、その処理方針が、例えば、「ＭＤＲｉ（ｉ＝１～ｎ）優先」や「ＦＣＭＤＢ参考」などのように、優先または参考となるＭＤＲを直接的に記載している場合、または、ステップＳ１７において処理方針を「ＦＣＭＤＢ優先」とした場合には、それらの処理方針を採用して優先または参考となるＭＤＲを決定する。一方、プロパティ、レコードまたはＣＩの処理方針が、数値条件（優先度算出式とその算出結果に基づく優先または参考となるＭＤＲの決定）となっている場合には、優先度を算出し、その算出結果と条件を適用して優先・参考となるＭＤＲを決定する。
　優先度判定部１４０４は、ステップＳ１８の処理が終了すると、優先・参考となるＭＤＲはＦＣＭＤＢ（ＦＣＭＤＢの構成情報データベース）のみか判断する（ステップＳ１９）。そして、優先・参考となるＭＤＲがＦＣＭＤＢのみと判断すると（ステップＳ１９、ｙｅｓ）ステップＳ２１に進み、優先・参考となるＭＤＲがＦＣＭＤＢのみでないと判断すると（ステップＳ１９、ｎｏ）ステップＳ２０に進む。
　ステップＳ２０において、更新依頼通信部１４０５は、優先・参考となるＭＤＲ及びＦＣＭＤＢに更新依頼を送り、その返答を待ち、ステップＳ２１に進む。
　ステップＳ２１において、更新可否判定部１４０６は、更新依頼通信部１４０５が更新依頼を送ったＭＤＲまたはＦＣＭＤＢからの返答を受け取り、その返答結果を基に、更新のコミットまたはロールバックを決定する。そして、更新に関係する全てのＭＤＲ（ＦＣＭＤＢの構成情報保持部も含む）に上記決定結果（コミットまたはロールバック）を通知し（ステップＳ２２）、本フローチャートの処理を終了する。
　｛更新可否判定部１４０６のフロー｝
　図１１は、更新可否判定部１４０６による２相コミット制御の処理（図１０のステップＳ２１の処理の詳細）を示すフローチャートである。
　更新可否判定部１４０６は、更新依頼通信部１４０５が更新依頼を送った優先・参考ＭＤＲの全てから返答を受信する（ステップＳ４０）。更新可否判定部１４０６は、返答したＭＤＲの中に優先ＭＤＲが存在するか判断し（ステップＳ４１）、存在すれば（ステップＳ４１、ｙｅｓ）ステップＳ４２に進み、存在しなければステップＳ４７に進む。
　ステップＳ４２において、更新可否判定部１４０６は、全ての優先ＭＤＲの返答を参照する。そして、返答が全て“Don´t Care”であるか判断する（ステップＳ４３）。そして、返答が全て“Don´t Care”であるのでなければ（ステップＳ４３、ｎｏ）ステップＳ４４に進み、全て“Don´t Care”であれば（ステップＳ４３、ｙｅｓ）ステップＳ４７に進む。
　ステップＳ４４において、更新可否判定部１４０６は、優先ＭＤＲの返答の中に“更新不可”が存在するか判断する。そして、“更新不可”が存在すれば（ステップＳ４４、ｙｅｓ）、更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に対して更新処理のロールバックを通知し（ステップＳ４５）、本フローチャートの処理を終了する。一方、ステップＳ４４において、優先ＭＤＲの返答の中に“更新不可”が存在しないと判断すれば（ステップＳ４４、ｎｏ）、更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に対して更新処理のコミットを通知し（ステップＳ４６）、本フローチャートの処理を終了する。
　このように、更新可否判定部１４０６は、優先ＭＤＲの返答の中に１つでも“更新不可”があれば、ロールバックを更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に通知する。
　ステップＳ４７において、更新可否判定部１４０６は参考ＭＤＲの返答を参照する。そして、返答の中に“更新不可”が存在するか判断し（ステップＳ４８）、“更新不可”が存在すれば（ステップＳ４８、ｙｅｓ）、更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に対して更新処理のロールバックを通知し（ステップＳ４９）、本フローチャートの処理を終了する。一方、“更新不可”が存在しなければ（ステップＳ４８、ｎｏ）、更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に対して更新処理のコミットを通知し（ステップＳ５０）、本フローチャートの処理を終了する。
　このように、更新可否判定部１４０６は、「更新処理の参加者の中に優先ＭＤＲが存在しない」または「更新処理の参加者の中に優先ＭＤＲが存在しても、優先ＭＤＲの全ての返答が“Don´t Care”である」場合には、参考ＭＤＲの返答を参照する。そして、参考ＭＤＲの返答の中に１つでも“更新不可”があれば、ロールバックを更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に通知する。
　以上説明したように、本実施形態においては、非優先に設定されたＭＤＲは、ＦＣＭＤＢからの更新依頼に対して、セキュア状態を保ちながら返答をする必要がない。このため、本本実施形態においては、構成情報データベースシステムに、ＦＣＭＤＢからの更新依頼に対してセキュア状態を保ちながら返答をすることができないＭＤＲが含まれていても、データの更新時に同期をとって、データの整合性を保持することが可能となる。また、本本実施形態においては、あるデータについて、優先ＭＤＲが１つであった場合、そのデータを更新する際には、いずれのＭＤＲもセキュア状態を保つ必要がなくなる。また、本本実施形態においては、更新依頼を受け取ってから返答するまでに大幅に時間がかりそうなＭＤＲがあった場合には、そのＭＤＲが早期に「Don´t Care」を返答するようにすることで、更新処理全体の所要時間を短縮することが可能となる。
　本発明は、上述した実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲内で種々に変形して実施することができる。
　本発明は、ＩＴＩＬ準拠の情報システムの構成管理に好適である。

Claims (20)

  1. 　管理対象となる情報システムの構成情報を保持する複数の要素データベースと、該複数の要素データベースを統合管理する統合データベースを備える統合管理データベースシステムであって、
    　前記統合データベースは、
    　前記複数の要素データベースに保持されている構成情報を一元的に管理する構成情報データベースと、
    　該構成情報データベースに登録されている構成情報の各データについて、予め処理方針を登録する処理方針登録手段と、
    　前記構成情報データベースに格納されているデータを更新する際、前記処理方針登録手段に登録されている更新対象のデータに関する処理方針を参照し、該更新すべきデータを保持している優先度の高い要素データベースのみに更新依頼を送信する更新依頼手段と、
    　該更新依頼手段が更新依頼を送信した要素データベースからの回答を受信し、該受信した回答結果に基づいて、更新をコミットするか否かを決定する更新可否決定手段と、
    　該更新可否決定手段の決定結果にしたがって、前記更新データを保持している全ての要素データベースにコミットまたはロールバックを指示する更新処理通信手段と、
    　を備える。
  2. 　前記処理方針は、各要素データベースが保持している更新データの優先度に応じて、要素データベース及び統合データベースの構成情報データベースを、優先要素データベース、参考要素データベースまたはその他要素データベースに分類する情報であり、
    　前記更新依頼手段は、更新データの処理方針に従って、各要素データベースを、優先要素データベース、参考要素データベース、またはその他要素データベースに決定し、該優先要素データベースと該参考要素データベースのみに更新依頼を通知することを特徴とする請求項１記載の統合管理データベースシステム。
  3. 　前記処理方針は、システム内において主の情報源となっている構成情報を保持している要素データベースが優先要素データベースまたは参考要素データベースとなるように設定されることを特徴とする請求項２記載の統合管理データベースシステム。
  4. 　前記処理方針は、特定の要素データベースが、優先要素データベースまたは参考要素データベースに設定されるように設定されることを特徴とする請求項２記載の統合管理データベースシステム。
  5. 　前記処理方針は、前記統合データベースの構成情報データベースが、優先または参考のデータベースとなるように設定されることを特徴とする請求項２記載の統合管理データベースシステム。
  6. 　前記処理方針は、優先度算出用の計算式と該優先度に基づいて優先要素データベースまたは参考要素データベースを判定する条件を含むことを特徴とする請求項２記載の統合管理データベースシステム。
  7. 　前記計算式は、各要素データベースに付与されるポイント、統合データベースの構成情報データベースに付与されるポイント、及びシステム内において主の情報源となっている構成情報を保持しているマスタ要素データベースに付与されるポイントを係数として含むことを特徴とする請求項６記載の統合管理データベースシステム。
  8. 　前記要素データベースの回答の選択肢には、コミット希望、ロールバック希望及びDon´t Careの３種類があり、
    　前記更新可否決定手段は、Don´t Careの回答は無視して、その他の回答を基に、データ更新処理をコミットまたはロールバックするかを決定することを特徴とする請求項２記載の統合管理データベースシステム。
  9. 　前記更新可否決定手段は、優先要素データベースからの回答の中に１つでも更新不可の回答が含まれている場合には、データ更新処理をロールバックするように決定することを特徴とする請求項８記載の統合管理データベースシステム。
  10. 　前記更新可否決定手段は、参考要素データベースからの回答の中に更新不可の回答が含まれていた場合であっても、データ更新処理をコミットするように決定してよいことを特徴とする請求項８記載の統合管理データベースシステム。
  11. 　前記更新可否決定手段は、全ての優先要素データベースの回答がDon´t Careであった場合には、参考要素データベースの回答結果を基に、データ更新処理をコミットまたはロールバックするかを決定することを特徴とする請求項８記載の統合管理データベースシステム。
  12. 　前記更新可否決定手段は、優先要素データベースの回答が無い場合には、参考要素データベースの回答を基に、データ更新処理をコミットまたはロールバックするかを決定することを特徴とする請求項２記載の統合管理データベースシステム。
  13. 　前記構成情報の管理単位である構成項目のデータは、上位から順に、構成項目、レコード、プロパティの各データ単位に分かれており、前記処理方針は、該データ単位毎に個別に設定可能であることを特徴とする請求項１記載の統合管理データベースシステム。
  14. 　前記更新依頼手段は、より下位のデータ単位の処理方針から順に参照し、処理方針が設定されているデータ単位の処理方針を適用することを特徴とすることを特徴とする請求項１３記載の統合管理データベースシステム。
  15. 　あるデータ単位に設定された処理方針は、より上位のデータ単位に設定された処理方針を適用するように指定するものであることを特徴とする請求項１４記載の統合管理データベースシステム。
  16. 　あるデータがシステムのデータと一致する必要がある場合には、そのデータを保持する要素データベースが優先要素データベースとなるように、そのデータの処理方針を設定することを特徴とする請求項２記載の統合管理データベースシステム。
  17. 　前記参考要素データベースは、セキュア状態を保つ必要がなく、更新可の返答に対して更新処理通信手段からロールバックの指示を受け取っても、データを更新してよいことを特徴とする請求項２記載の統合管理データベースシステム。
  18. 　管理対象となる情報システムの構成情報を保持する複数の要素データベースと、該複数の要素データベースを統合管理する統合データベースを備える統合管理データベースシステムであって、
    　前記統合データベースは、
    　前記複数の要素データベースに保持されている構成情報を一元的に管理する構成情報データベースと、
    　該構成情報データベースに構成情報を書き込む構成情報保持部と、
    　該構成情報データベースに管理されている各構成情報に関する処理方針を含む優先度情報を受け付ける優先度入力部と、
    　該優先度入力部が受け付けた優先度情報を保持する優先度データベースと、
    　要素データベースからデータの更新・登録を受け付ける更新登録・入力部と、
    　該更新登録・入力部が受け付けた更新データについて、該優先度データベースに保持されている該更新データの処理方針を参照して、該更新データの更新を依頼すべき要素データベースを決定する優先度判定部と、
    　該優先度判定部により前記更新を依頼するように決定された要素データベースに対して、前記更新データの更新依頼を通知する更新依頼通信部と、
    　該更新依頼部から更新依頼通知を受け取った要素データベースから回答を受け取り、該回答を基に、前記構成情報の更新処理のコミットまたはロールバックを決定する更新可否決定部と、
    　該更新可否決定部の決定結果を基に、システム内の要素データベース及び前記構成情報データベースに対して前記構成情報のコミットまたはロールバックを通知する更新処理通信部と、
    　を備える。
  19. 　管理対象となる情報システムの構成情報を保持する複数の要素データベースと、該複数の要素データベースを統合管理する統合データベースを備える統合管理データベースシステムの更新同期方法であって、
    　前記複数の要素データベースに保持されている構成情報を一元的に管理する構成情報データベースに登録されている構成情報の各データについて、予め処理方針を登録する処理方針登録ステップと、
    　前記構成情報データベースに格納されているデータを更新する際、該更新すべきデータに関する処理方針を参照し、該更新すべきデータを保持している優先度の高い要素データベースのみに更新依頼を送信する更新依頼ステップと、
    　該更新依頼ステップにおいて更新依頼を送信した要素データベースから回答を受信し、該受信した回答結果に基づいて、更新をコミットするか否かを決定する更新可否決定ステップと、
    　該更新可否決定ステップでの決定結果にしたがって、前記更新データを保持している全ての要素データベースにコミットまたはロールバックを指示する更新処理通信ステップと、
    　を備える。
  20. 　管理対象となる情報システムの構成情報を保持する複数の要素データベースを統合管理する統合データベース装置であって、
    　前記複数の要素データベースに保持されている構成情報を一元的に管理する構成情報データベースと、
    　該構成情報データベースに登録されている構成情報の各データについて、予め処理方針を登録する処理方針登録手段と、
    　前記構成情報データベースに格納されているデータを更新する際、前記処理方針登録手段に登録されている該更新すべきデータに関する処理方針を参照し、該更新すべきデータを保持している優先度の高い要素データベースのみに更新依頼を送信する更新依頼手段と、
    　該更新依頼手段が更新依頼を送信した要素データベースからの回答を受信し、該受信した回答結果に基づいて、更新をコミットするか否かを決定する更新可否決定手段と、
    　該更新可否決定手段の決定結果にしたがって、前記更新データを保持している全ての要素データベースにコミットまたはロールバックを指示する更新処理通信手段と、
    　を備える。
PCT/JP2008/002561 2008-09-17 2008-09-17 ２相コミットによるデータ更新同期方法及びシステム WO2010032278A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/JP2008/002561 WO2010032278A1 (ja) 2008-09-17 2008-09-17 ２相コミットによるデータ更新同期方法及びシステム
JP2010529512A JP5257455B2 (ja) 2008-09-17 2008-09-17 ２相コミットによるデータ更新同期方法及びシステム
EP08808502.2A EP2330511B1 (en) 2008-09-17 2008-09-17 Data update synchronization method and system by two-phase commit
US13/044,797 US8572047B2 (en) 2008-09-17 2011-03-10 Method and system for data update synchronization by two-phase commit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2008/002561 WO2010032278A1 (ja) 2008-09-17 2008-09-17 ２相コミットによるデータ更新同期方法及びシステム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/044,797 Continuation US8572047B2 (en) 2008-09-17 2011-03-10 Method and system for data update synchronization by two-phase commit

Publications (1)

Publication Number Publication Date
WO2010032278A1 true WO2010032278A1 (ja) 2010-03-25

Family

ID=42039132

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2008/002561 WO2010032278A1 (ja) 2008-09-17 2008-09-17 ２相コミットによるデータ更新同期方法及びシステム

Country Status (4)

Country Link
US (1) US8572047B2 (ja)
EP (1) EP2330511B1 (ja)
JP (1) JP5257455B2 (ja)
WO (1) WO2010032278A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013206123A (ja) * 2012-03-28 2013-10-07 Fujitsu Ltd 管理プログラム、管理装置および情報処理システム

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8489547B2 (en) * 2009-07-30 2013-07-16 International Business Machines Corporation System and method for transforming configuration data items in a configuration management database
US9020905B2 (en) * 2009-10-31 2015-04-28 International Business Machines Corporation Synchronizing database and non-database resources without a commit coordinator
US8266126B2 (en) * 2010-03-24 2012-09-11 Matrixx Software, Inc. System with multiple conditional commit databases
US8682846B2 (en) * 2011-09-09 2014-03-25 Hewlett-Packard Development Company, L.P. Content item reconciliation
JP5966765B2 (ja) * 2012-08-22 2016-08-10 富士通株式会社 情報処理システム、中継装置、情報処理プログラム、及び情報処理方法
US9910881B1 (en) 2013-12-12 2018-03-06 Amazon Technologies, Inc. Maintaining versions of control plane data for a network-based service control plane
US9747356B2 (en) 2014-01-23 2017-08-29 Oracle International Corporation Eager replication of uncommitted transactions
EP3467642B1 (en) * 2017-10-04 2023-10-04 ServiceNow, Inc. Guided configuration item class creation in a remote network management platform
US20190102841A1 (en) 2017-10-04 2019-04-04 Servicenow, Inc. Mapping engine configurations with task managed workflows and grid user interfaces

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0460850A (ja) * 1990-06-29 1992-02-26 Nec Corp トランザクション終了処理方式
JPH0611927A (ja) 1992-06-24 1994-01-21 Nec Corp カラー電子写真画像形成装置
JPH06119227A (ja) * 1992-10-06 1994-04-28 Oki Electric Ind Co Ltd 分散データベース制御システム
JPH1185595A (ja) * 1997-09-16 1999-03-30 Oki Electric Ind Co Ltd 分散データベース管理システムおよび分散データベース管理方法

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5193162A (en) * 1989-11-06 1993-03-09 Unisys Corporation Cache memory with data compaction for use in the audit trail of a data processing system having record locking capabilities
JP3293839B2 (ja) * 1990-05-16 2002-06-17 インターナショナル・ビジネス・マシーンズ・コーポレーション 作業ユニットに合わせてコミット範囲を調整するコンピュータ・システム
US5796999A (en) * 1994-04-15 1998-08-18 International Business Machines Corporation Method and system for selectable consistency level maintenance in a resilent database system
JPH08286964A (ja) 1995-04-13 1996-11-01 Mitsubishi Electric Corp 分散トランザクション処理方法
US5668958A (en) * 1995-09-12 1997-09-16 International Business Machines Corporation Heterogeneous filing system with common API and reconciled file management rules
JP3563591B2 (ja) * 1997-09-29 2004-09-08 株式会社リコー 分散型データベースシステムの一貫性管理方法およびその方法の各工程をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体
US6397247B1 (en) * 1998-03-25 2002-05-28 Nec Corporation Failure prediction system and method for a client-server network
US20040163020A1 (en) * 2002-01-25 2004-08-19 David Sidman Apparatus method and system for registration effecting information access
US20030046230A1 (en) * 2001-08-30 2003-03-06 Jacobs Dean Bernard Method for maintaining account consistency
US7028030B2 (en) * 2001-08-30 2006-04-11 Bea Systems, Inc. Cluster caching with concurrency checking
JP4162184B2 (ja) 2001-11-14 2008-10-08 株式会社日立製作所 データベース管理システムの実行情報を取得する手段を有する記憶装置
JP4158534B2 (ja) * 2003-01-21 2008-10-01 修平 西山 分散型データベースシステム
US20050144299A1 (en) * 2003-12-04 2005-06-30 Blevins Delmar E. System and method for supporting XA 2-phase commit protocols with a loosely coupled clustered database server
US7249277B2 (en) * 2004-03-11 2007-07-24 Hitachi, Ltd. Disk array including plural exchangeable magnetic disk unit
JP2005316762A (ja) * 2004-04-28 2005-11-10 Toshiba Corp ディスク記憶装置及びｒａｉｄ構築方法
US7653628B2 (en) * 2004-04-30 2010-01-26 Sap Ag Persistent data management with different isolation levels
JP2006221399A (ja) 2005-02-10 2006-08-24 Yokogawa Electric Corp 分散情報統合方法及びこれを用いたシステム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0460850A (ja) * 1990-06-29 1992-02-26 Nec Corp トランザクション終了処理方式
JPH0611927A (ja) 1992-06-24 1994-01-21 Nec Corp カラー電子写真画像形成装置
JPH06119227A (ja) * 1992-10-06 1994-04-28 Oki Electric Ind Co Ltd 分散データベース制御システム
JPH1185595A (ja) * 1997-09-16 1999-03-30 Oki Electric Ind Co Ltd 分散データベース管理システムおよび分散データベース管理方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2330511A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013206123A (ja) * 2012-03-28 2013-10-07 Fujitsu Ltd 管理プログラム、管理装置および情報処理システム

Also Published As

Publication number Publication date
JPWO2010032278A1 (ja) 2012-02-02
US20110161288A1 (en) 2011-06-30
EP2330511A4 (en) 2012-10-10
US8572047B2 (en) 2013-10-29
EP2330511A1 (en) 2011-06-08
EP2330511B1 (en) 2016-07-20
JP5257455B2 (ja) 2013-08-07

Similar Documents

Publication Publication Date Title
JP5257455B2 (ja) ２相コミットによるデータ更新同期方法及びシステム
US20190180241A1 (en) System and method of commitment management
KR101169117B1 (ko) 확장 가능하고 자동으로 복제되는 서버 팜 구성 관리인프라스트럭처를 위한 서버 팜, 시스템 및 방법
US9984140B1 (en) Lease based leader election system
US9852204B2 (en) Read-only operations processing in a paxos replication system
US9292575B2 (en) Dynamic data aggregation from a plurality of data sources
US9141435B2 (en) System and methodology providing workload management in database cluster
CN104239439A (zh) 选择性的数据库复制
US9124609B2 (en) Ensuring consistency over time of data gathered by distinct software applications
US9081839B2 (en) Push replication for use with a distributed data grid
US8549129B2 (en) Live migration method for large-scale IT management systems
US8751711B2 (en) Storage topology manager
US20140304230A1 (en) System and Method for Selective Replication of Electronic Data
US9240965B2 (en) Methods and systems for business interaction monitoring for networked business process
WO2009122528A1 (ja) 統合構成管理装置、異種構成管理装置、バックアップデータ管理システム
CN109241194A (zh) 基于高性能集群分布的数据库系统的负载均衡方法及装置
US20220078829A1 (en) Scheduling database system
US10108923B2 (en) Method and system for inventory data sharing between airlines
US20150234866A1 (en) Data Distribution System
JP5480046B2 (ja) 分散トランザクション処理システム、装置、方法およびプログラム
Cardinale et al. Fuzzy ACID properties for self‐adaptive composite cloud services execution
Ibrahim Mobile transaction processing for a distributed war environment
JP6626327B2 (ja) ガントチャート生成プログラム、ガントチャート生成装置、および、ガントチャート生成方法
Barreiro et al. ATLAS production system
US20130036087A1 (en) Visibility and management of project data

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08808502

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010529512

Country of ref document: JP

REEP Request for entry into the european phase

Ref document number: 2008808502

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2008808502

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE