|Publication number||US7437355 B2|
|Application number||US 10/874,171|
|Publication date||Oct 14, 2008|
|Filing date||Jun 24, 2004|
|Priority date||Jun 24, 2004|
|Also published as||US20050289094|
|Publication number||10874171, 874171, US 7437355 B2, US 7437355B2, US-B2-7437355, US7437355 B2, US7437355B2|
|Original Assignee||Sap Ag|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (7), Referenced by (2), Classifications (14), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
Embodiments of the present invention generally relate to computers. More particularly, embodiments relate to methods and systems for parallel updates of computer databases.
2. Background of the Invention
It is generally known that data may be stored in a tabular form. Conceptually, tables are comprised of multiple records. In a two-dimensional table, each record is associated with one row. Each row may comprise one or more cells. Columns in the table each represent a specific field with the same meaning for all records. As used herein, tables are equivalent to database tables and accordingly, rows may be referred to alternatively as “rows” or “records,” or “database records.” Columns may be referred to alternatively as “columns” or “fields.” For purposes of description herein, a first row in a table is called a “header row.” The cells of the header row may contain a description or identification of the content of the cells below it.
The data stored in tables may be provided as input to numerous reports. Some reports, for example, may summarize the data stored in the many fields in a table. The reports may be useful for such things as tracking the objectives of a business or the availability of commodities. Examples of business objectives may include the total amount of costs attributed to a cost center in a certain month or over a certain period, the amount spent on servicing multiple accounts, or the year to date income from all sources to a cost center. Examples of availability of a commodity may include the number of toy rockets available for purchase from all stores in a nationwide chain of stores. These examples are meant to be illustrative and not limiting.
Generally, and for purposes of description herein, data in a table may be accessed either by an individual process or by a mass process. An individual process may be a dialog session in which an individual user gains access to the table for purposes that may include generating reports or updating the table. For example, the user may have an invoice verification application where the user may post an invoice for a given cost center. Such an application will typically require the entry of cost center identification information and invoice amount into a dialog box on a computer interface unit, such as a keyboard and video terminal. The entry will result in a change in value of a cell of a record, associated with the cost center. A mass process, on the other hand, may be exemplified as a background process run for a multitude of entries. For example, a mass process may post debit memos to the table for all customers. In mass processes, one may receive the information via an electronic file. This file may be processed in the background. In fact, more than one file may be received and may run in parallel. Each file in a mass process file may contain several hundred or several thousand postings for execution.
It is conceivable that mass processes running in parallel may be accomplishing the same task (e.g., posting invoices or payments in parallel). In one example, when a first process accesses the table to change a specific record in the table, the first process may be given exclusive control of the specific record; other processes will not be able to edit the specific record while it is under the exclusive control of the first process. Only after the first process has relinquished its exclusive control of the record will other processes be able to again edit this record. In a system used by more than one user or accessed by more than one process, the ability of multiple users or processes to gain access to any given record is problematic and may cause a bottleneck if the multiple users or processes attempt to access or use the same record contemporaneously. A typical solution may involve a database administration system, which may form a single queue for the multiple parallel processes, where each of the multiple parallel processes waits in the queue for its turn to serially update (e.g., sum or input data to) the subject record.
The various advantages of embodiments of the present invention will become apparent to one skilled in the art by reading the following specification and appended claims, and by referencing the following drawings.
In an embodiment, the invention provides for methods, systems, and computer readable storage medium for performing database updates by parallel processes. In an embodiment, the invention provides for a method for assigning identifiers to a plurality of processes, wherein the identifiers are selected from a predefined set of identifiers, and where no two processes running in parallel use the same identifier. In an embodiment, the invention provides for receiving a first request from a first process, having assigned thereto a first identifier, for updating a first record in a set of records stored in a database; determining if the first record is associated with the first identifier in the database; and updating the first record if the first record is associated with the first identifier in the database.
The problem of multiple parallel users or processes being excluded from simultaneous access to a given record in a table may be solved by adding a field to the table and by modifying an overall process control to account for the added field. One method of changing the design of the table, in accordance with an embodiment of the invention herein, may be to add a field to a table to demarcate individual records for use only by a given process. Such a field may be referred to herein as a process identification (“PROCESS ID”) field. The process identification field may allow a plurality of processes to operate on separate records while serving to prohibit various parallel processes from updating the same record. Furthermore, in accordance with an embodiment of the invention disclosed herein, a process may dynamically update the table by adding another row to the table if a row did not previously exist that could be demarcated for use by the process.
To compare and contrast the basic table of
By way of example, let it be assumed that two processes are to be executed, a first process will add 5 to Cost Center 1 and a second process will add 10 to Cost Center 1. A method that makes use of the basic table of
In contradistinction, in accordance with an embodiment of the invention, a method may be executed that allows multiple processes to access different records for the same cost center simultaneously, eliminating the series bottleneck associated with the prior described method. By way of example, using the expanded table of
Further, now assume that a new process, process n+1, has begun. The n+1th process may attempt to add a value of 15 to the amount field of Cost Center 1. The n+1th process may attempt to identify a set of records associated with PROCESS ID n+1, but, in the table as illustrated in
The expanded table 200 could be shared among any number of multiple processes. Each process may add as many records to the table as it may require. For reporting, the records that share identical first fields but whose PROCESS ID fields differ in value (e.g., records of rows 214 and 230) may then be merged and their values summed together. For example, records 220 and 221 in the third field 210 may be summed together because their associated records 216, 217, respectively, in the first field 202 are identical, while their associated records 218, 219, respectively, in the second field 206 differ.
The method of
It will be noted that the probability of a record being used by a second process, as evaluated at 308,
It is noted that a method to update values (e.g., amounts, quantities) that are assigned to an object (e.g., cost center, general ledger account, material) that allows parallel running processes to update the values of the same object(s) without hindering one another may include an assigning of a PROCESS ID to every running process taken from a predefined set of PROCESS IDs (e.g. 00, 01, . . . 99) in a way that no two processes running in parallel will use the same PROCESS ID. In one embodiment, processes that are finished may release their PROCESS ID. The PROCESS ID thus becomes available for another process that requires one. Those of skill in the art will know of methods in data processing which can ensure the required unique allocation of PROCESS Ids, accordingly, such methods are not described herein.
It is also noted that a method to update values that are assigned to an object that allows parallel running processes to update the values of the same object(s) without hindering one another may involve the use of a heretofore unknown structure of database records, where the values assigned to the objects are stored. The new structure may differ from the known structures that are technically designed to store all the relevant data (e.g., object key(s) and object value(s)) in so far, that a unique process identification field (e.g., PROCESS-ID) is added. This field may be used as a key field to distinguish records.
It is further noted that in an embodiment, any update or insert of records to the database table, that is executed by a process, will affect only records where the unique process identifier field includes the value assigned to the process (e.g., a first process may have a value of 00 assigned to it).
In accordance with one embodiment, if more than a foreseen number of PROCESS IDs are required at the same time (e.g., one-hundred-and-one PROCESS IDs are required, but the foreseen set is 00, 01, . . . , 99), the first PROCESS ID (here 00) may be taken for the one hundred and first process, accepting, that two or more processes now work with the same Process ID.
In accordance with an embodiment, any retrieval function (e.g., a function that may determine a total value assigned to a cost center, general ledger account, material, etc.) may read all records assigned to the object. All these records contain the same object key (e.g., identification of the cost center, general ledger account, material, etc.) but different values for the PROCESS IDs. The total value assigned to the object may be calculated as the sum of all records retrieved.
In an embodiment, the values to be used in the PROCESS ID field for mass processes and the values to be used for individual processes may be pre-defined in the system, taking into account the following:
A table with four fields plus a PROCESS ID and a summary field was created in an SAP system using a DB2 7.1.0 database. A test program generated 1,000 updates for each of five summary records. Each of the five summary records was thus changed 1,000 times, resulting in 5,000 updates per process.
The program was started simultaneously in two, three, and four parallel processes. In the first test sequence, the updates took place without different PROCESS IDs. In the second test sequence, they took place with different PROCESS IDs. The results are shown in Table A, below.
Duration in Seconds
Duration in Seconds
Same PROCESS ID
Different PROCESS ID
The measurement values indicate that processing times tend not to increase with additional number of processes when multiple PROCESS IDs are used. Processing times, however, do tend to increase with additional number of processes when the same PROCESS ID is used.
If these figures are extrapolated to an example with only four parallel processes in which 2,000,000 updates have to take place (for example, 400,000 documents, each with five posting items), 500,000 updates are allotted to each process, for which around 6,200 seconds are required if the PROCESS ID is the same and 2,200 seconds if the PROCESS IDs are different. The duration of the updates is thus reduced from around one hour and 43 minutes to 37 minutes.
Effect with Read Accesses
A differentiation between mass accesses and accesses to specific objects may be made (e.g., an object would be one specific cost center or one specific general ledger account). For example with a general ledger summary table, mass accesses (when all or a large proportion of entries are read) are required for preparing balance sheets. Accesses to specific objects are required, for example, if the overall status of an account needs to be displayed.
Typically, mass accesses are only required periodically (e.g., during closing operations) and do not cause performance problems because the number of summary records is considerably lower than the number of individual records from which the summaries are created.
Measurements described above were made for accesses to specific objects: records from five PROCESS IDs were read instead of a single record. The measurement results did not show any significant differences in the time taken to access the database. Reading the five records was never over 20% slower than reading one record.
Those skilled in the art can appreciate from the foregoing description that the broad techniques of the embodiments of the present invention can be implemented in a variety of forms. Therefore, while the embodiments of this invention have been described in connection with particular examples thereof, the true scope of the embodiments of the invention should not be so limited since other modifications will become apparent to the skilled practitioner upon a study of the drawings, specification, and following claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5664129 *||Aug 2, 1995||Sep 2, 1997||Hitachi, Ltd.||Visual programming method|
|US6457021 *||Aug 18, 1998||Sep 24, 2002||Microsoft Corporation||In-memory database system|
|US6714948 *||Mar 16, 2000||Mar 30, 2004||Charles Schwab & Co., Inc.||Method and system for rapidly generating identifiers for records of a database|
|US7047337 *||Apr 24, 2003||May 16, 2006||International Business Machines Corporation||Concurrent access of shared resources utilizing tracking of request reception and completion order|
|US7093761 *||Dec 10, 2003||Aug 22, 2006||E2Interactive, Inc.||System and method for distributing stored-value cards|
|US20040010502 *||Jul 12, 2002||Jan 15, 2004||Bomfim Joanes Depaula||In-memory database for high performance, parallel transaction processing|
|US20050125406 *||Dec 3, 2003||Jun 9, 2005||Miroslav Cina||Database access with multilevel lock|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8407183 *||Dec 21, 2007||Mar 26, 2013||Sap Ag||Business intelligence data extraction on demand|
|US20090164486 *||Dec 21, 2007||Jun 25, 2009||Gabi Foeldesi||Business intelligence data extraction on demand|
|U.S. Classification||1/1, 707/E17.044, 707/E17.005, 707/E17.007, 715/763, 707/999.003, 707/999.2, 707/999.1|
|International Classification||G06F7/00, G06F17/30|
|Cooperative Classification||Y10S707/99933, G06F17/30286|
|European Classification||G06F17/30S, G06F17/30C|
|Sep 15, 2004||AS||Assignment|
Owner name: SAP AKTIENGESELLSCHAFT, GERMANY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PLATE, KLAUS;REEL/FRAME:015787/0117
Effective date: 20040811
|Apr 4, 2012||FPAY||Fee payment|
Year of fee payment: 4
|Aug 26, 2014||AS||Assignment|
Owner name: SAP SE, GERMANY
Free format text: CHANGE OF NAME;ASSIGNOR:SAP AG;REEL/FRAME:033625/0334
Effective date: 20140707