CLIAMS:FIELD OF TECHNOLOGY
The present invention relates to communication technology and, in particular, to a method and an apparatus for guaranteeing transaction durability.

BACKGROUND
Database (DB) offers durability by a combination of transaction logs and checkpoint mechanism. Generally durability is a basic feature for a database. Every operation in a database transaction is tracked in logs generally known as transaction logs. These logs are also used to replay the operations during recovery time. Hence they are also known as “redo logs”. Generally, as shown in Fig. 1, the implementing manner for a Disk database to guarantee durability of each committed transaction comprises: writing the transaction logs to a durable storage like a HDD (Hard Disk Drive, HDD) until that commit is pointed to the disk and then performing the commit. The log writing and the commit returning to the user are synchronous operations. If the log writing fails, then the commit also fails.

This solution when moved to in-memory databases slows down transaction operation considerably. In-memory DBs generally do not have any I/O overhead, so their operations are fast. But to produce durability if every transaction has to write the logs to the disk it generates a log of I/O slowing down the operation. Many in-memory DB solutions avoid this problem by introducing “non-durable” or “deferred-durable” commits. In this solution, as shown in Fig. 2, the commit operation will return before the transaction log is written into the disk. The transaction logs are written into the disks at a later point in time. This could be on a specific timeout or on happening of a specific event like transaction log buffer full. This kind of solutions is also called “lazy commit”.

A “lazy commit” allows database transactions to be committed faster by not waiting for log records of the transaction to be written to disk. When a system crash occurs during the commit process, transactions may be lost because the log data is not available to recreate the transaction. While lazy commit speed up processing, they also increase the potential for data inconsistency.

SUMMARY
The present invention provides a method and an apparatus for guaranteeing transaction durability on specific conditions even when maintaining lazy commit without trading off performance, so as to minimize the probability of lost of transaction logs due to system crash or when imminent system power down occurs during the commit process.

A first aspect of the present invention provides a method for guaranteeing transaction durability in a database system, including:
monitoring the capability of the database system; wherein the capability comprising at least one of: battery/power level of the database system or size of the dirty transaction log;
storing dirty transaction logs into a persistent storage when the database system crashes or remaining battery capacity of the database system reaches a preset condition or amount of the dirty transaction logs of the database system reaches a first preset threshold, wherein, the dirty transaction logs refer to transaction logs which are not yet written to a disk of the database system.

Alternatively, the monitoring the capability of the database system includes:
monitoring the remaining battery capacity of the database system;
correspondingly, determining whether the remaining battery capacity of the database system reaches the preset condition specifically comprises: monitoring whether the remaining battery capacity reaches a preset second threshold.

Alternatively, the monitoring the capability of the database system includes:
monitoring an amount of current dirty transaction logs and current remaining battery capacity of the database system.

Alternatively, the determining whether the remaining battery capacity of the database system reaches a preset condition includes:
determining whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
if yes, it is determined that the remaining battery capacity of the database system reaches a preset condition.

Alternatively, the determining whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage includes:
acquiring a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), it is determined that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
wherein, D = ( BL1 – BL0 ) / t, BL1 is the current remaining battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

Alternatively, after monitoring the capability of the database system, and before storing the dirty transaction logs of the database system into the persistent storage, the method further includes:
intercepting process of the database system directly or sending a signal for intercepting the process to the database system.

Alternatively, before monitoring the capability of the database system, the method further includes:
registering the database system so as to track dirty transaction logs.

A second aspect of the present invention provides an apparatus for guaranteeing transaction durability in a database system, including:
a monitoring unit, configured to monitor the capability of the database system; wherein the capability comprising at least one of: battery/power level of the database system or size of the dirty transaction log; and
trigger a processing unit when the database system crashes or remaining battery capacity of the database system reaches a preset condition or amount of the dirty transaction logs of the database system reaches a first preset threshold;
the processing unit is configured to store dirty transaction logs into a persistent storage;
wherein, the dirty transaction logs refer to transaction logs which are not yet written to a disk of the database system.

Alternatively, the monitoring unit is specifically configured to:
monitor the remaining battery capacity of the database system, determine whether the remaining battery capacity of the database system reaches a preset second threshold.

Alternatively, the monitoring unit is further configured to:
monitor an amount of current dirty transaction logs and current remaining battery capacity of the database system.

Alternatively, the monitoring unit is further configured to:
determine whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
if yes, it is determine that the remaining battery capacity of the database system reaches a preset condition.

Alternatively, the monitoring unit is further configured to:
acquire a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), determine that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
wherein, D = ( BL1 – BL0 ) / t, BL1 is the current remaining battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

Alternatively, the processing unit is further configured to:
intercept process of the database system directly or send a signal for intercepting the process to the database system.

Alternatively, the processing unit is further configured to:
register the database system so as to track dirty transaction logs.

A third aspect of the present invention provides an apparatus for guaranteeing transaction durability in a database system, including at least one processor and a memory, the memory is configured to store executable programming codes, wherein, the processor reads the executable programming codes stored in the memory to operate a program corresponding to the executable programming codes, such that to:
monitor the capability of the database system; wherein the capability comprising at least one of: battery/power level of the database system or size of the dirty transaction log;
store dirty transaction log into a persistent storage when the database system crashes or remaining battery capacity of the database system reaches a preset condition or amount of the dirty transaction logs of the database system reaches a first preset threshold, wherein, the dirty transaction logs refer to transaction logs which are not yet written to a disk of the database system.

According to the method and apparatus for guaranteeing transaction durability, when the database system crashes or remaining battery capacity of the database system reaches a certain level or size of the dirty transaction logs of the database system reaches a certain threshold, dirty transaction logs are timely stored into a persistent storage, such that to avoid the dirty transaction logs from being lost, the dirty transaction logs stored in the persistent storage can be called later when in need, thus the transaction durability during commit process can be guaranteed.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
To make the technical solution of the present invention or the prior art more clear, the accompanying drawings used with the description of embodiments of the present invention or the prior art will be illustrated briefly as follows. Apparently, the accompanying drawings only show certain embodiments of the invention, persons skilled in the art can derive other drawings from them without creative work.

FIG. 1 is a durability implementation in databases provided by the prior-art;

FIG. 2 is a deferred durability (lazy commit) implementation in databases provided by the prior-art;

FIG. 3 is a schematic diagram of the method for guaranteeing transaction durability provided by the present invention;

FIG.4 is a database in a mobile phone (a battery powered device);

FIG. 5 is server connected to an UPS with battery backup;

FIG. 6 is a schematic flow of determination of OS capability of durability guarantee;

FIG. 7 is a schematic flow of DB choosing durability Mode based on condition of the system;

FIG. 8 is a schematic flow of OS tracking of transaction log pages;

FIG. 9 is a schematic flow of unset dirty flag on checkpoint/log writing;

FIG. 10 is a schematic flow of OS handling on low power threshold;

FIG. 11 is a schematic work flow of OS transaction log buffer dumping process;

FIG. 12 is a schematic work flow of recovery process;

FIG. 13 is a schematic flow diagram of a method for guaranteeing transaction durability provided by an embodiment of the present invention;

FIG. 14 is a schematic flow diagram of a method for guaranteeing transaction durability provided by another embodiment of the present invention;

FIG. 15 is a schematic flow diagram of a method for guaranteeing transaction durability provided by still another embodiment of the present invention;

FIG. 16 is a schematic structural diagram of an apparatus for guaranteeing transaction durability provided by an embodiment of the present invention;

FIG. 17 is a schematic structural diagram of an apparatus for guaranteeing transaction durability provided by another embodiment of the present invention.

DETAILED DESCRIPTION OF THE PRESENT INVENTION
The technical solutions in the embodiments of the present invention are hereinafter described clearly and comprehensively with reference to the accompanying drawings. It should be understood that the described embodiments are only a part rather than all of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

A method and apparatus for making commits durable and high performing is provided in the present disclose. The method allows in-memory database systems to use lazy commits, but provide durability to these lazy commits on process crashes and imminent system power down scenarios, every operation in a database transaction is tracked in logs generally known as transaction logs or journal logs, all of which are called transaction logs hereinafter. As shown in Fig.3, the method modifies the operating system (OS) to provide a handle in the operating system to track the changed pages in the transaction log buffer of the database system. The operating system monitors the size of the dirty transaction log buffer. The durability of the transaction log buffer is compromised in two scenarios:
a. DB process crash
b. System where DB is executing powers off

The case of the DB process crashing is more likely in in-memory DB systems because of direct API interfaces with the application. A bug in the application has the potential to crash the DB system.

If the process crashes, the operating system intercepts the crash and dumps the dirty transaction log buffer to a persistent storage.

The second case is that of the system where the DB is executing powering-off. If the power off is sudden there is nothing much which can be done. However in the current scenario there are many systems which run on battery. Examples are mobile phones, tablet PCs, laptops. The carrier network equipments use redundant power systems. Alongside with the usage of battery there is tremendous improvement in the battery level monitoring and power management systems in the operating system. Linux offers ACPI (Advanced Configuration and Power Interface) modules to monitor power and battery level. Similarly Android offers power monitoring mechanisms to handle battery power monitoring system.

The operating system monitors the power level of the system and determines when the power level of the system has gone down enough to start the DB persistence. In this scenario the OS either stops the DB process or signals the DB process using an interrupt. Then the OS start the dump of the transaction log. The OS also ensures other lower priority processes are suspended and access to the storage disk is controlled so as to ensure the dumping of the complete transaction log.

All these processing can be transparent to the user. For e.g. let us suppose the Operating System has capability to monitor the power level. In this case if the configuration of the DB is “non-cache” (guaranteed commit); the DB system can choose to use an optimistic “lazy commit” solution. The solution will fail only when there is a hard power-down of the DB system. This can be considered akin to hardware failure which cannot be protected by any simple durability mechanism.

One of the key application areas of the invention are systems which have a battery backup and which have capability to predict the battery power state accurately. These conditions are met by a mobile device like a phone or a tablet, as shown in Fig.4. Another use case is for carrier grade equipment which contains redundant power units and which can guarantee power back-up. Example could be Software-Switches, Routers which have redundant power units. Another use case is for various servers connected to UPS which can guarantee some kind of power backup prediction, as shown in Fig.5.

The first embodiment of the invention deals with the configuration of the OS and determination of the capability of the current system to offer any kind of “durability guarantee.

As shown in Fig.6, OS capability of write speed is pre-configured, for example, the max write speed can be set as 2MB(mega byte)/Second. Further, already multiple solutions are available to get information from batteries and UPS. The following are a few examples which offer ways to determine the capacity of an UPS or a battery:
1. APCUPSD for monitoring UPS on Linux and other Unix machines
2. ACPI (Advanced Configuration and Power Interface) modules supporting recommendations from ACPI group. These can monitor power on various OS.
3. SmartBattery solutions using SMBus in Linux.

Based on determination of a power level, it is possible to determine the theoretical maximum size of a file which could be written without exhausting the whole battery. This is done by retrieving the power consumption and Read/Write access speed. It has been proven that the power consumption for a HDD can be determined to an accuracy level of 7.5% by John Zedlewski et al., Modeling Hard-Disk Power Consumption, Proc. Second Conference on File and Storage Technologies, March 2003. Using these techniques we determine the theoretical maximum size of the file that can be guaranteed.

Further, an embodiment of the present invention introduces some durability modes for the database, which are shown in the following table.
Table 1 Commit Durability Modes
Durability Mode Definition Guarantee
PES_DURABILITY Pessimistic Durability: The DB ensures every committed transaction is written to a permanent disk store Maximum, Guarantee all committed transactions
OPT_DURABILITY Optimistic Durability: New Mode introduced. The DB ensures all committed data are written to a permanent disk store. However in case of un-predictable power outage, the data is not guaranteed Guarantee all committed transactions except in situation of un-predictable power outage
NO_DURABILITY No commitment is given for the durability of committed transactions No guarantees

In another embodiment the DB in co-operation with the OS determines the nature of durability implementation. If the user configures for OPT_DURABILITY mode, DB checks if it is feasible to offer this mode in the current system. If it is feasible the DB chooses this mode else it reverts back to PES_DURABILITY mode. When the user configures for OPT_DURABILITY mode, the user is expected to provide a minimum durability size, which is determined based on heuristics which is verified against the OS guarantee.

In another embodiment the DB in co-operation with the OS determines the nature of durability implementation. As shown in Fig.7, if the user configures for OPT_DURABILITY mode, DB checks if it is feasible to offer this mode in the current system. If it is feasible the DB chooses this mode else it reverts back to PES_DURABILITY mode. When the user configures for OPT_DURABILITY mode, the user is expected to provide a minimum durability size, which is determined based on heuristics which is verified against the OS guarantee.

In an embodiment once the DB registers for OS guarantee for the DB, as shown in Fig. 8, the OS tracks all dirty pages. This tracking is facilitated by utilizing a special system call to track the memory pages. When a checkpoint happens or when the log writer process of the DB writes the journal log files to the disk store, the DB invokes another system call which will unset the dirty bit on the pages (as shown in Fig. 9).

According to Fig. 10, in another embodiment the OS tracks the battery/power level to see it has reached a critical level to start writing the log files. The OS uses an equation is used to determine the current risk level of the durability. If the risk level reaches a specific threshold, then the OS signals the DB process. The signal could be an interrupt to the DB process. The DB process handles the signal by suspending further writes and then asks the OS to continue the dumping process.

As shown in Fig. 11, in another embodiment the OS can intercept crashes in the DB process. On the DB process crashing the OS intercepts the crash process if the DB process is registered for guarantee. Then the OS dumps all the dirty journal log pages and then shuts down the process.

In another embodiment the entity which observes the power condition and then intercepts for journal log durability could be outside the operating system. This could be another process co-located in the database itself or could a dedicated process.

In another embodiment the entity which observes the power condition and then intercepts for journal log durability could be located in the hardware which could be a dedicated hardware monitoring the power situation and triggering a dump of a specific area of memory. The area of the memory however has to be registered with the hardware.

In another embodiment the durability parameter could be associated with the network. The journal log could be written to a network system. This would be a typical case of a diskless node. The monitoring entity, the memory dumping entity could be specialized hardware chips.

In another embodiment the DB uses the data dumped by the OS in its recovery process, as shown in Fig. 12, this operation is straight forward. The DB process stitches the pages dumped by the OS and then replays the redo in the journal log to recover the DB.

Refer to the description of the above embodiments, another embodiment of the present invention provides a method for guaranteeing transaction durability, database software and the Operating System are the two entities which host this method, the executing subject of the method can be an apparatus for guaranteeing transaction durability, the apparatus for guaranteeing transaction durability can be a separately arranged apparatus apart from a database system, or can be integrated in the database system, this is determined according to actual needs and will not be described here. For example, the apparatus for guaranteeing transaction durability can be a mobile device, which comprises an operating system and database, as shown in Fig.4, or a server connected to UPS as shown in Fig.5.

FIG. 13 is a schematic flow diagram of a method for guaranteeing transaction durability in a database system that supports lazy commit, according to an embodiment of the present invention, as shown in FIG. 13, the method includes the following steps:

Step 101, monitoring the capability of the database system; wherein the capability comprising: battery/power level of the database system or size of the dirty transaction log, or both of them .

In the present embodiment, monitoring the capability of the database system can specifically be monitoring the database system when the database system adopting lazy commit. Monitoring the capability of the database system includes: monitoring the remaining battery capacity of the database system, or monitoring the remaining battery capacity of the database system together with the size of current dirty transaction logs of the database system, or only monitoring the size of the current dirty transaction logs. Monitoring the size of the current dirty transaction logs includes: monitoring the size of the current dirty transaction logs through tracking the changed pages in a transaction log buffer of the database system. The monitoring the database can also include: monitoring whether the database system is crashed. All of the above monitoring modes fall into the scope of monitoring a database system in the present embodiment and can be determined according to actual needs. During monitoring, the dirty transaction logs refer to transaction logs which are not yet written to the disk of the database system and are currently stored in a transaction buffer of the database, the transaction buffer can be a buffer only for storing the transaction logs, and the buffer is called a transaction log buffer.

Step 102, storing dirty transaction logs into a persistent storage when the database system crashes or remaining battery capacity of the database system reaches a preset condition or size of the dirty transaction logs of the database system reaches a first preset threshold.

In the present embodiment, the database is in a crash state refers to a crash procedure which is currently not finished. The crash state is procedure, after beginning of the crash state and before it is finished, the database is regarded as in a crash state. For example, when the database system is in a crash state, the operation of storing dirty transaction logs into a persistent storage is executed right after the database is determined as in a crash state . In the present embodiment, multiple means can be used to determine whether the database system is in a crash state or not, for example, checking whether the processing ID of the database process is alive or not, if not, it is determined that the database system is in a crash state, or checking if the database socket listening port is open or not by connecting to the port, if not, it is determined that the database system is in a crash state. Moreover, if the database is not determined to be in a crash state, storing dirty transaction logs into a persistent storage when determined that the remaining battery capacity of the database system reaches a preset condition; or, storing dirty transaction logs into the persistent storage when the size of the dirty transaction logs of the database system reaches a first preset threshold. The preset first threshold can be set according to actual needs, for example, 90% of the size of the transaction log buffer or the dirty transaction logs reach a size of for example 5GB etc. The persistent storage here can be a separated storage device or a storage device in the network.

In the present embodiment, the dirty transaction logs are stored into a persistent storage when the database system crashes or remaining battery capacity of the database system reaches a certain condition or size of the dirty transaction logs reaches certain threshold, so as to avoid the dirty transaction logs from being lost, the dirty transaction logs stored in the persistent storage can be called later when in need, thus the transaction durability during a commit process can be guaranteed.

Before step 101, the method may further include:
registering the database system so as to track the dirty transaction logs.

A transaction log comprises two parts: one part is the dirty transaction logs in the memory which is not written to a disk or other persistent storage and the other part is already stored in the disk or other persistent storage. In the present embodiment, only dirty transaction logs are tracked. Optionally all transaction logs can be tracked.

Take Linux system as an example, the above step of registering the database system so as to track the dirty logs can specifically be:

Once the database process is running, a registration system call is invoked and the operation is named as register_durability_guarantee. This registration system call has the following signature:
int register_durability_guarantee(int processId, long durability_size)

If the operating system (Operating System, OS) can guarantee this durability, the value will return to 0, else return to -1.

The transaction log buffer (cache in memory) is registered by the database process for tracking. This is done by the following new system call:
int register_dump_memory(void *p, int length)

When a checkpoint happens or the transaction logs have been written to the disk, the following new system call tells the OS that the transaction log buffer is dumped to the disk and the transaction logs are not required to be tracked. The checkpoint is a standard concept in databases. On the checkpoint all transaction logs are written to the disk from the transaction log buffer:
int set_dump_memory_valid(void *p, bool is_tracked)

In the present embodiment, the durability size, i.e. the threshold size of the dirty transaction logs, is set a minimum durability size, the minimum durability size is determined based on heuristics which is verified against the OS guarantee.

The verification is to be done on how much time can be provided to before the process shuts down. This time is generally below 1 second.

Minimum durability size Wmin differs based on the database workload. For example, comparing with other conventional systems, in a insert/delete intensive system, Wmin will be quite high.

A sample Wmin calculation is as follows:

Suppose for a given workload, there are 1000 inserts per second and each insert on an average produces about 1 KB of logging. In this case the transaction logs growth rate per second is about 1MB. This is the heuristics of this system.

In this scenario a transaction log buffer size of 100MB is reasonable. The minimum durability size can be the same as the transaction log buffer size.

On the basis of the above embodiment shown in FIG. 13, FIG. 14 is a schematic flow diagram of a method for guaranteeing transaction durability according to another embodiment of the present invention. Generally speaking, the method for guaranteeing transaction durability may be implemented in two modes. The method as shown in FIG. 14 adopts the first mode which includes:

Step 201, monitoring remaining battery capacity of a database system when it is recognized that the database system adopts lazy commit.

There are many ways to determine the capacity of an UPS or a battery, for example, when the database system is Linux system, the power source can be a UPS, the apparatus for guaranteeing transaction durability can monitor the UPS on Linux and other Unix machines, or an advanced configuration and power interface (Advanced Configuration and Power Interface, ACPI) modules monitor the power on the OS of various database systems. The ACPI supports recommendations from ACPI group, in the apparatus which monitors UPS on Linux and other Unix machines, also, the power source can be smart battery solutions using system management bus (System Management Bus, SMBus) in Linux.

Step 202, determining whether a remaining battery capacity reaches a preset second threshold, if yes, execute step 203, if not, return to step 201.

In the present embodiment, when the remaining battery capacity does not reach the preset second threshold, the monitoring the remaining battery capacity of the database system is continued, that is, execute step 201, and execute step 202.

The preset second threshold can be a preset value. For example, the preset second threshold can be a minimum power which is acquired according to actual operations and by which a current amount of dirty transaction logs is guaranteed to be stored into a persistent storage, the second threshold can be set such as 10% of battery capacity.

There exists multiple ways to acquire power level in the prior art.

For example, in Android system, power monitoring mechanisms are provided to handle battery power monitoring system. As an example, the battery capacity in Android system can specifically be:

Android Code Snippet for Battery Condition Determination

IntentFilter ifilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
Intent batteryStatus = context.registerReceiver(null, ifilter);
int level = battery.getIntExtra(BatteryManager.EXTRA_LEVEL, -1);
int scale = battery.getIntExtra(BatteryManager.EXTRA_SCALE, -1);
float batteryPct = level / (float) scale;

In the above shown snippet, we can register a handler to get notifications as to when the battery levels are changing (Intent. ACTION_BATTERY_CHANGED). Based on the notification we can judge the current level of the battery (depicted by variable “level” and “batteryPct”).

When a Linux system is adopted, ACPI modules are provided to monitor power and battery capacity.

Specifically, as an example, the determination of battery capacity in Linux system can be:

Linux Code Snippet for Battery Condition Determination
#include < linux/power_supply.h >
...
char name[]= "BAT0";
int battery_level = 0;
struct power_supply *psy = power_supply_get_by_name(name);
union power_supply_propval chargenow, chargefull;
battery_level = psy->get_property( psy, POWER_SUPPLY_PROP_CHARGE_NOW , &chargenow );

In the above shown API snippet, we use the linux API for checking the battery level. This battery level is termed as “CHARGE” in the linux API. The battery is termed as “POWER” in the linux API. Here we use an API (psy->get_property) to the battery level. The result of the battery level is stored in the variable “battery_level”.

Step 203, storing the dirty transaction logs into a persistent storage.

After step 202 and before step 203, the method can further include:
intercepting process of the database system directly or sending a signal for intercepting the process to the database system.

To be specific, the apparatus for guaranteeing transaction durability may directly intercept a current process of the database system, and store the transaction logs into the persistent storage, or the apparatus for guaranteeing transaction durability can send a signal to the database system, the signal is configured to instruct the database to intercept the current process.

In the present embodiment, through setting a battery capacity threshold to store the transaction logs into the persistent storage, such that all current transaction logs can be stored into the persistent storage, thereby guaranteeing durability of transaction.

FIG. 15 is a schematic flow diagram of a method for guaranteeing transaction durability according to another embodiment of the present invention, as shown in FIG. 3, the method is a second mode of the method for guaranteeing transaction durability which includes:

Step 301, monitoring size of current dirty transaction logs and current battery capacity of a database system when it is recognized that the database system adopts lazy commit.

As a transaction occurs, data in the database system is writing into the transaction logs continuously, thus, dirty transaction logs in the buffer also increase.

Step 302, determining whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage, if yes, it is determined that the remaining battery capacity reaches a preset condition, execute step 303, if not, return to step 301.

In the present embodiment, if the remaining battery capacity is larger than a required battery capacity to store all current dirty transaction logs into a persistent storage, the following operations of storing the dirty transaction logs into the persistent storage is not executed, but to keep on acquiring the size of current dirty transaction logs and current battery capacity of the database system, and repeat step 302 for determining.

Specifically, the determination is performed by determining the theoretical maximum size of a file which could be written without exhausting the whole battery. For example, determining whether the current battery capacity equal to a battery capacity with which the theoretical maximum size of a file which could be written without exhausting the whole battery.

This can specifically be done by retrieving the power consumption and R/W access speed. It has been proven that the power consumption for a HDD can be determined to an accuracy level by John Zedlewski et al., Modeling Hard-Disk Power Consumption, Proc. Second Conference on File and Storage Technologies, March 2003. Using these techniques we can determine that the theoretical maximum size of the dirty transaction logs that can be guaranteed.

An example of the above mechanism is given below.

The writing speed of the apparatus for guaranteeing transaction durability is expressed as Wc, which is represented in MB/sec.

Similarly by observing the battery power levels and the consumption pattern, the drain rate could be determined. This drain rate of the battery of the database system is expressed as D, which is represented in % battery power / sec.

The current battery capacity is expressed as BL, which is represented in % battery power

Using these two variables we can determine the maximum write guarantee as Wmax, which is represented in MB.
Wmax = Wc * (BL / D)
where D = ( BL1 – BL0 ) / t, BL1 is the current battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

That is, the step above can be:
acquiring a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), it is determined that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage.

An example is taken below:

If Wc is 1024MB/sec, BL = 10%, D = 2

Wmax = 1024 x (10 / 2) = 5 GB

If the current battery capacity can only maintain a successful written of 5GB dirty transaction logs, and at present there is only 5GB dirty transaction logs, then execute step 303.

It should be noted that, selection of the foregoing processing modes can be determined according to the write capacity of the apparatus for guaranteeing transaction durability. For example, then the writing speed of the apparatus for guaranteeing transaction durability reaches a third preset threshold, the above mode 2 can be adopted, if else, adopt above mode 1. For example, when the minimum durability size is 100MB, the third preset threshold is 1GB/sec, if the OS Wc is 1GB/sec, using mode 2 is safe, however, if the OS Wc is only 10MB/sec, mode 1 is preferably adopted to process transaction durability.

Step 303, storing the dirty transaction logs into the persistent storage.

In the present embodiment, through timely storing the transaction logs into the persistent storage, such that the transaction logs will not lost when the database system crashes or out of power, thereby guaranteeing durability of transaction.

An embodiment of the present invention provides an apparatus for guaranteeing transaction durability, the apparatus for guaranteeing transaction durability is configured to execute the method for guaranteeing transaction durability. The apparatus can be integrated in the database system or can be separately arranged.

As shown in FIG. 16, which is a schematic structural diagram of an apparatus for guaranteeing transaction durability provided by an embodiment of the present invention, the apparatus includes a monitoring unit 401 and a processing 402.

Wherein, the monitoring unit 401 is configured to monitor a data base system when it is recognized that the database system adopts lazy commit; and trigger a processing unit 402 when the database system crashes or remaining battery capacity of the database system reaches a preset condition or amount of the dirty transaction logs of the database system reaches a first preset threshold; the processing unit 402 is connected with the monitoring unit 401; the processing unit 402 is configured to store dirty transaction logs into a persistent storage; wherein, the dirty transaction logs refer to transaction logs which are not yet written to a disk of the database system.

Alternatively, the monitoring unit 401 is specifically configured to monitor the remaining battery capacity of the database system, determine whether the remaining battery capacity of the database system reaches a preset second threshold.

Or, alternatively, the monitoring unit 401 is further configured to monitor size of current dirty transaction logs and current battery capacity of the database system, at this time, the monitoring unit 401 monitors whether the battery capacity of the database system reaches a preset condition can specifically be:
determine whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
if yes, determine that the battery capacity of the database system reaches a preset condition.

Specifically, the monitoring unit is 401 can determine whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage by the following means:
acquire a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), determine that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
wherein, D = ( BL1 – BL0 ) / t, BL1 is the current battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

Alternatively, the processing unit is further configured to intercept process of the database system directly or send a signal for intercepting the process to the database system.

Alternatively, the processing unit is further configured to register the database system so as to track dirty transaction logs.

The operations of apparatus for guaranteeing transaction durability are the same with the steps executed by the corresponding method, which will not be described here.

According to the apparatus 400 for guaranteeing transaction durability provided by the present embodiment, when the database system crashes or remaining battery capacity of the database system reaches a certain level or size of the dirty transaction logs of the database system reaches a certain threshold, dirty transaction logs are timely stored into a persistent storage, such that to avoid the dirty transaction logs from being lost, the dirty transaction logs stored in the persistent storage can be called later when in need, thus the transaction durability during commit process can be guaranteed.

An embodiment of the present invention provides an apparatus for guaranteeing transaction durability. As shown in FIG. 17, which is a schematic structural diagram of an apparatus for guaranteeing transaction durability provided by another embodiment of the present invention. The apparatus includes at least one processor 501, a communication bus 502, a memory 503 and at least one communication port 504.

Wherein, the communication bus 502 is configured to achieve the connection and communication of the above unit, the communication port 504 is configured to connect a network device and communicate with it. The bus can be industry standard architecture (Industry Standard Architecture, ISA) bus, peripheral component interface (Peripheral Component Interface, PCI) bus or extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus etc. The bus can be one or more physical bus, when there are multiple buses, the buses can be divided as address bus, data bus and control bus etc.

Wherein, the memory 503 is configured to store executable programming codes, wherein, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, such that to:
monitor a database system when it is recognized that the database system adopts lazy commit;
store dirty transaction logs into a persistent storage when the database system crashes or remaining battery capacity of the database system reaches a preset condition or amount of the dirty transaction logs of the database system reaches a first preset threshold, wherein, the dirty transaction logs refer to transaction logs which are not yet written to a disk of the database system.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, such that to monitor the database system can specifically be:
monitor the remaining battery capacity of the database system;
correspondingly, determine whether the remaining battery capacity of the database system reaches the preset condition specifically comprises: monitoring whether the battery capacity reaches a preset second threshold.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, such that to monitor the database system can specifically be:
monitor an amount of current dirty transaction logs and current battery capacity of the database system.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, such that to determine that the battery capacity of the database system reaches a preset condition can specifically be:
determine whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
if yes, it is determined that the battery capacity of the database system reaches a preset condition.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, such that to determine that whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage can specifically be:
acquire a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), it is determined that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
wherein, D = ( BL1 – BL0 ) / t, BL1 is the current battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, after monitor the database system and before store the dirty transaction logs of the database system into the persistent storage, such that to:
intercept process of the database system directly or sending a signal for intercepting the process to the database system.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, before monitor the database system, such that to:
register the database system so as to track dirty transaction logs.

According to the apparatus 500 for guaranteeing transaction durability provided by the present embodiment, when the database system crashes or battery capacity of the database system reaches a certain level or size of the dirty transaction logs of the database system reaches a certain threshold, dirty transaction logs are timely stored into a persistent storage, such that to avoid the dirty transaction logs from being lost, the dirty transaction logs stored in the persistent storage can be called later when in need, thus the transaction durability during commit process can be guaranteed.

When being implemented as a software function unit and sold or used as a stand-alone product, the functions may be stored in a computer-readable storage medium. Based on this understanding, the essence of the technical solution of the present invention, or the part which contributes to the prior art, or part of the technical solutions, may be embodied in a software product. The software product may be stored in a computer-readable storage medium and incorporates several instructions for instructing a computer device (for example, personal computer, server, or network device etc) to execute all or part of the steps of the method specified in any embodiment of the present invention. Examples of the storage medium include various media capable of storing program codes, such as a USB flash disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk, or an optical disk etc.

A person of ordinary skill in the art may understand that, all or a part of the steps of the foregoing method embodiments may be implemented by a program instructing relevant hardware. The aforementioned program may be stored in a computer readable storage medium. When the program runs, the steps of the forgoing method embodiments are performed. The storage medium includes any medium capable of storing program code, such as a ROM, a RAM, a magnetic disk, or an optical disc.

Finally, it should be noted that the foregoing embodiments are merely intended for describing the technical solutions of the present invention rather than limiting the present invention. Although the present invention is described in detail with reference to the foregoing embodiments, persons of ordinary skill in the art should understand that they may still make modifications to the technical solutions described in the foregoing embodiments, or make equivalent replacements to some or all the technical features thereof, as long as such modifications and replacements do not cause the essence of corresponding technical solutions to depart from the scope of the technical solutions of the embodiments of the present invention.

The term "and/or" in the embodiments of the present invention indicates only an association between associated objects, and represents that three relationships may exist, for example, A and/or B may represent the three cases: Only A exists, both A and B exist, and only B exists. In addition, the character "/" in this document generally represents that the former and latter associated objects are in an "or" relationship.

WE CLAIM :
1. A method for guaranteeing transaction durability in a database system, characterized by comprising:
monitoring capability of the database system, wherein the capability comprising a battery/power level of the database system and/or a size of the dirty transaction log;
storing dirty transaction logs into a persistent storage when an process of the database system crashes and/or remaining battery capacity of the database system reaches a preset condition or size of the dirty transaction logs of the database system reaches a first preset threshold, wherein, the dirty transaction logs refer to transaction logs which are not currently written to a disk of the database system.

2. The method for guaranteeing transaction durability as claimed in claim 1, wherein monitoring the capability of the database system comprises:
monitoring the remaining battery capacity of the database system;
correspondingly, determining whether the remaining battery capacity of the database system reaches the preset condition specifically comprises: monitoring whether the remaining battery capacity reaches a preset second threshold.

3. The method for guaranteeing transaction durability as claimed in claim 1, wherein, monitoring the capability of the database system comprises:
monitoring an amount of current dirty transaction logs and/or current remaining battery capacity of the database system.

4. The method for guaranteeing transaction durability according to claim 3, wherein, determining whether the remaining battery capacity of the database system reaches a preset condition comprises:
determining whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
if yes, it is determined that the remaining battery capacity of the database system reaches a preset condition.

5. The method for guaranteeing transaction durability as claimed in claim 4, wherein, determining whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage comprises:
acquiring a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), it is determined that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
wherein, D = ( BL1 – BL0 ) / t, BL1 is the current remaining battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

6. The method for guaranteeing transaction durability as claimed in claim 1, wherein, after monitoring the capability of the database system, and before storing the dirty transaction logs of the database system into the persistent storage, further comprises:
intercepting process of the database system directly or sending a signal for intercepting the process to the database system.

7. The method for guaranteeing transaction durability as claimed in any one of claims 1-6, wherein, before monitoring the capability of the database system, the method further comprises:
registering the database system so as to track dirty transaction logs.

8. An apparatus for guaranteeing transaction durability in a database system, characterized by comprising:
a monitoring unit, configured to monitor the capability of the database system, wherein the capability comprising a battery/power level of the database system and/or size of the dirty transaction log; and
a processing unit configured to:
be triggered when the database system crashes and/or remaining battery capacity of the database system reaches a preset condition and/or amount of the dirty transaction logs of the database system reaches a first preset threshold; and
to store dirty transaction logs into a persistent storage, wherein the dirty transaction logs refer to transaction logs which are not currently written to a disk of the database system.

9. The apparatus for guaranteeing transaction durability as claimed in claim 8, wherein, the monitoring unit is specifically configured to:
monitor the remaining battery capacity of the database system, determine whether the remaining battery capacity of the database system reaches a preset second threshold.

10. The apparatus for guaranteeing transaction durability as claimed in claim 8, wherein the monitoring unit is further configured to:
monitor an amount of current dirty transaction logs and current remaining battery capacity of the database system.

11. The apparatus for guaranteeing transaction durability as claimed in claim 10, wherein the monitoring unit is further configured to:
determine whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
if yes, it is determined that the remaining battery capacity of the database system reaches a preset condition.

12. The apparatus for guaranteeing transaction durability as claimed in claim 11, wherein the monitoring unit is further configured to:
acquire a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), it is determined that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
wherein, D = ( BL1 – BL0 ) / t, BL1 is the current remaining battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

13. The apparatus for guaranteeing transaction durability as claimed in claim 8, wherein the processing unit is further configured to:
intercept process of the database system directly or send a signal for intercepting the process to the database system.

14. The apparatus for guaranteeing transaction durability as claimed in any one of claims 8-13, wherein the processing unit is further configured to:
register the database system so as to track dirty transaction logs.

15. An apparatus for guaranteeing transaction durability in a database system, comprising at least one processor coupled to a memory, and the processor operable to:
monitor capability of the database system, wherein the capability comprising a battery/power level of the database system and/or size of the dirty transaction log; and
store dirty transaction logs into a persistent storage when the database system crashes or remaining battery capacity of the database system reaches a preset condition or amount of the dirty transaction logs of the database system reaches a first preset threshold, wherein, the dirty transaction logs refer to transaction logs which are not yet written to a disk of the database system.
,TagSPECI:FIELD OF TECHNOLOGY
The present invention relates to communication technology and, in particular, to a method and an apparatus for guaranteeing transaction durability.

BACKGROUND
Database (DB) offers durability by a combination of transaction logs and checkpoint mechanism. Generally durability is a basic feature for a database. Every operation in a database transaction is tracked in logs generally known as transaction logs. These logs are also used to replay the operations during recovery time. Hence they are also known as “redo logs”. Generally, as shown in Fig. 1, the implementing manner for a Disk database to guarantee durability of each committed transaction comprises: writing the transaction logs to a durable storage like a HDD (Hard Disk Drive, HDD) until that commit is pointed to the disk and then performing the commit. The log writing and the commit returning to the user are synchronous operations. If the log writing fails, then the commit also fails.

This solution when moved to in-memory databases slows down transaction operation considerably. In-memory DBs generally do not have any I/O overhead, so their operations are fast. But to produce durability if every transaction has to write the logs to the disk it generates a log of I/O slowing down the operation. Many in-memory DB solutions avoid this problem by introducing “non-durable” or “deferred-durable” commits. In this solution, as shown in Fig. 2, the commit operation will return before the transaction log is written into the disk. The transaction logs are written into the disks at a later point in time. This could be on a specific timeout or on happening of a specific event like transaction log buffer full. This kind of solutions is also called “lazy commit”.

A “lazy commit” allows database transactions to be committed faster by not waiting for log records of the transaction to be written to disk. When a system crash occurs during the commit process, transactions may be lost because the log data is not available to recreate the transaction. While lazy commit speed up processing, they also increase the potential for data inconsistency.

SUMMARY
The present invention provides a method and an apparatus for guaranteeing transaction durability on specific conditions even when maintaining lazy commit without trading off performance, so as to minimize the probability of lost of transaction logs due to system crash or when imminent system power down occurs during the commit process.

A first aspect of the present invention provides a method for guaranteeing transaction durability in a database system, including:
monitoring the capability of the database system; wherein the capability comprising at least one of: battery/power level of the database system or size of the dirty transaction log;
storing dirty transaction logs into a persistent storage when the database system crashes or remaining battery capacity of the database system reaches a preset condition or amount of the dirty transaction logs of the database system reaches a first preset threshold, wherein, the dirty transaction logs refer to transaction logs which are not yet written to a disk of the database system.

Alternatively, the monitoring the capability of the database system includes:
monitoring the remaining battery capacity of the database system;
correspondingly, determining whether the remaining battery capacity of the database system reaches the preset condition specifically comprises: monitoring whether the remaining battery capacity reaches a preset second threshold.

Alternatively, the monitoring the capability of the database system includes:
monitoring an amount of current dirty transaction logs and current remaining battery capacity of the database system.

Alternatively, the determining whether the remaining battery capacity of the database system reaches a preset condition includes:
determining whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
if yes, it is determined that the remaining battery capacity of the database system reaches a preset condition.

Alternatively, the determining whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage includes:
acquiring a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), it is determined that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
wherein, D = ( BL1 – BL0 ) / t, BL1 is the current remaining battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

Alternatively, after monitoring the capability of the database system, and before storing the dirty transaction logs of the database system into the persistent storage, the method further includes:
intercepting process of the database system directly or sending a signal for intercepting the process to the database system.

Alternatively, before monitoring the capability of the database system, the method further includes:
registering the database system so as to track dirty transaction logs.

A second aspect of the present invention provides an apparatus for guaranteeing transaction durability in a database system, including:
a monitoring unit, configured to monitor the capability of the database system; wherein the capability comprising at least one of: battery/power level of the database system or size of the dirty transaction log; and
trigger a processing unit when the database system crashes or remaining battery capacity of the database system reaches a preset condition or amount of the dirty transaction logs of the database system reaches a first preset threshold;
the processing unit is configured to store dirty transaction logs into a persistent storage;
wherein, the dirty transaction logs refer to transaction logs which are not yet written to a disk of the database system.

Alternatively, the monitoring unit is specifically configured to:
monitor the remaining battery capacity of the database system, determine whether the remaining battery capacity of the database system reaches a preset second threshold.

Alternatively, the monitoring unit is further configured to:
monitor an amount of current dirty transaction logs and current remaining battery capacity of the database system.

Alternatively, the monitoring unit is further configured to:
determine whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
if yes, it is determine that the remaining battery capacity of the database system reaches a preset condition.

Alternatively, the monitoring unit is further configured to:
acquire a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), determine that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
wherein, D = ( BL1 – BL0 ) / t, BL1 is the current remaining battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

Alternatively, the processing unit is further configured to:
intercept process of the database system directly or send a signal for intercepting the process to the database system.

Alternatively, the processing unit is further configured to:
register the database system so as to track dirty transaction logs.

A third aspect of the present invention provides an apparatus for guaranteeing transaction durability in a database system, including at least one processor and a memory, the memory is configured to store executable programming codes, wherein, the processor reads the executable programming codes stored in the memory to operate a program corresponding to the executable programming codes, such that to:
monitor the capability of the database system; wherein the capability comprising at least one of: battery/power level of the database system or size of the dirty transaction log;
store dirty transaction log into a persistent storage when the database system crashes or remaining battery capacity of the database system reaches a preset condition or amount of the dirty transaction logs of the database system reaches a first preset threshold, wherein, the dirty transaction logs refer to transaction logs which are not yet written to a disk of the database system.

According to the method and apparatus for guaranteeing transaction durability, when the database system crashes or remaining battery capacity of the database system reaches a certain level or size of the dirty transaction logs of the database system reaches a certain threshold, dirty transaction logs are timely stored into a persistent storage, such that to avoid the dirty transaction logs from being lost, the dirty transaction logs stored in the persistent storage can be called later when in need, thus the transaction durability during commit process can be guaranteed.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
To make the technical solution of the present invention or the prior art more clear, the accompanying drawings used with the description of embodiments of the present invention or the prior art will be illustrated briefly as follows. Apparently, the accompanying drawings only show certain embodiments of the invention, persons skilled in the art can derive other drawings from them without creative work.

FIG. 1 is a durability implementation in databases provided by the prior-art;

FIG. 2 is a deferred durability (lazy commit) implementation in databases provided by the prior-art;

FIG. 3 is a schematic diagram of the method for guaranteeing transaction durability provided by the present invention;

FIG.4 is a database in a mobile phone (a battery powered device);

FIG. 5 is server connected to an UPS with battery backup;

FIG. 6 is a schematic flow of determination of OS capability of durability guarantee;

FIG. 7 is a schematic flow of DB choosing durability Mode based on condition of the system;

FIG. 8 is a schematic flow of OS tracking of transaction log pages;

FIG. 9 is a schematic flow of unset dirty flag on checkpoint/log writing;

FIG. 10 is a schematic flow of OS handling on low power threshold;

FIG. 11 is a schematic work flow of OS transaction log buffer dumping process;

FIG. 12 is a schematic work flow of recovery process;

FIG. 13 is a schematic flow diagram of a method for guaranteeing transaction durability provided by an embodiment of the present invention;

FIG. 14 is a schematic flow diagram of a method for guaranteeing transaction durability provided by another embodiment of the present invention;

FIG. 15 is a schematic flow diagram of a method for guaranteeing transaction durability provided by still another embodiment of the present invention;

FIG. 16 is a schematic structural diagram of an apparatus for guaranteeing transaction durability provided by an embodiment of the present invention;

FIG. 17 is a schematic structural diagram of an apparatus for guaranteeing transaction durability provided by another embodiment of the present invention.

DETAILED DESCRIPTION OF THE PRESENT INVENTION
The technical solutions in the embodiments of the present invention are hereinafter described clearly and comprehensively with reference to the accompanying drawings. It should be understood that the described embodiments are only a part rather than all of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

A method and apparatus for making commits durable and high performing is provided in the present disclose. The method allows in-memory database systems to use lazy commits, but provide durability to these lazy commits on process crashes and imminent system power down scenarios, every operation in a database transaction is tracked in logs generally known as transaction logs or journal logs, all of which are called transaction logs hereinafter. As shown in Fig.3, the method modifies the operating system (OS) to provide a handle in the operating system to track the changed pages in the transaction log buffer of the database system. The operating system monitors the size of the dirty transaction log buffer. The durability of the transaction log buffer is compromised in two scenarios:
a. DB process crash
b. System where DB is executing powers off

The case of the DB process crashing is more likely in in-memory DB systems because of direct API interfaces with the application. A bug in the application has the potential to crash the DB system.

If the process crashes, the operating system intercepts the crash and dumps the dirty transaction log buffer to a persistent storage.

The second case is that of the system where the DB is executing powering-off. If the power off is sudden there is nothing much which can be done. However in the current scenario there are many systems which run on battery. Examples are mobile phones, tablet PCs, laptops. The carrier network equipments use redundant power systems. Alongside with the usage of battery there is tremendous improvement in the battery level monitoring and power management systems in the operating system. Linux offers ACPI (Advanced Configuration and Power Interface) modules to monitor power and battery level. Similarly Android offers power monitoring mechanisms to handle battery power monitoring system.

The operating system monitors the power level of the system and determines when the power level of the system has gone down enough to start the DB persistence. In this scenario the OS either stops the DB process or signals the DB process using an interrupt. Then the OS start the dump of the transaction log. The OS also ensures other lower priority processes are suspended and access to the storage disk is controlled so as to ensure the dumping of the complete transaction log.

All these processing can be transparent to the user. For e.g. let us suppose the Operating System has capability to monitor the power level. In this case if the configuration of the DB is “non-cache” (guaranteed commit); the DB system can choose to use an optimistic “lazy commit” solution. The solution will fail only when there is a hard power-down of the DB system. This can be considered akin to hardware failure which cannot be protected by any simple durability mechanism.

One of the key application areas of the invention are systems which have a battery backup and which have capability to predict the battery power state accurately. These conditions are met by a mobile device like a phone or a tablet, as shown in Fig.4. Another use case is for carrier grade equipment which contains redundant power units and which can guarantee power back-up. Example could be Software-Switches, Routers which have redundant power units. Another use case is for various servers connected to UPS which can guarantee some kind of power backup prediction, as shown in Fig.5.

The first embodiment of the invention deals with the configuration of the OS and determination of the capability of the current system to offer any kind of “durability guarantee.

As shown in Fig.6, OS capability of write speed is pre-configured, for example, the max write speed can be set as 2MB(mega byte)/Second. Further, already multiple solutions are available to get information from batteries and UPS. The following are a few examples which offer ways to determine the capacity of an UPS or a battery:
1. APCUPSD for monitoring UPS on Linux and other Unix machines
2. ACPI (Advanced Configuration and Power Interface) modules supporting recommendations from ACPI group. These can monitor power on various OS.
3. SmartBattery solutions using SMBus in Linux.

Based on determination of a power level, it is possible to determine the theoretical maximum size of a file which could be written without exhausting the whole battery. This is done by retrieving the power consumption and Read/Write access speed. It has been proven that the power consumption for a HDD can be determined to an accuracy level of 7.5% by John Zedlewski et al., Modeling Hard-Disk Power Consumption, Proc. Second Conference on File and Storage Technologies, March 2003. Using these techniques we determine the theoretical maximum size of the file that can be guaranteed.

Further, an embodiment of the present invention introduces some durability modes for the database, which are shown in the following table.
Table 1 Commit Durability Modes
Durability Mode Definition Guarantee
PES_DURABILITY Pessimistic Durability: The DB ensures every committed transaction is written to a permanent disk store Maximum, Guarantee all committed transactions
OPT_DURABILITY Optimistic Durability: New Mode introduced. The DB ensures all committed data are written to a permanent disk store. However in case of un-predictable power outage, the data is not guaranteed Guarantee all committed transactions except in situation of un-predictable power outage
NO_DURABILITY No commitment is given for the durability of committed transactions No guarantees

In another embodiment the DB in co-operation with the OS determines the nature of durability implementation. If the user configures for OPT_DURABILITY mode, DB checks if it is feasible to offer this mode in the current system. If it is feasible the DB chooses this mode else it reverts back to PES_DURABILITY mode. When the user configures for OPT_DURABILITY mode, the user is expected to provide a minimum durability size, which is determined based on heuristics which is verified against the OS guarantee.

In another embodiment the DB in co-operation with the OS determines the nature of durability implementation. As shown in Fig.7, if the user configures for OPT_DURABILITY mode, DB checks if it is feasible to offer this mode in the current system. If it is feasible the DB chooses this mode else it reverts back to PES_DURABILITY mode. When the user configures for OPT_DURABILITY mode, the user is expected to provide a minimum durability size, which is determined based on heuristics which is verified against the OS guarantee.

In an embodiment once the DB registers for OS guarantee for the DB, as shown in Fig. 8, the OS tracks all dirty pages. This tracking is facilitated by utilizing a special system call to track the memory pages. When a checkpoint happens or when the log writer process of the DB writes the journal log files to the disk store, the DB invokes another system call which will unset the dirty bit on the pages (as shown in Fig. 9).

According to Fig. 10, in another embodiment the OS tracks the battery/power level to see it has reached a critical level to start writing the log files. The OS uses an equation is used to determine the current risk level of the durability. If the risk level reaches a specific threshold, then the OS signals the DB process. The signal could be an interrupt to the DB process. The DB process handles the signal by suspending further writes and then asks the OS to continue the dumping process.

As shown in Fig. 11, in another embodiment the OS can intercept crashes in the DB process. On the DB process crashing the OS intercepts the crash process if the DB process is registered for guarantee. Then the OS dumps all the dirty journal log pages and then shuts down the process.

In another embodiment the entity which observes the power condition and then intercepts for journal log durability could be outside the operating system. This could be another process co-located in the database itself or could a dedicated process.

In another embodiment the entity which observes the power condition and then intercepts for journal log durability could be located in the hardware which could be a dedicated hardware monitoring the power situation and triggering a dump of a specific area of memory. The area of the memory however has to be registered with the hardware.

In another embodiment the durability parameter could be associated with the network. The journal log could be written to a network system. This would be a typical case of a diskless node. The monitoring entity, the memory dumping entity could be specialized hardware chips.

In another embodiment the DB uses the data dumped by the OS in its recovery process, as shown in Fig. 12, this operation is straight forward. The DB process stitches the pages dumped by the OS and then replays the redo in the journal log to recover the DB.

Refer to the description of the above embodiments, another embodiment of the present invention provides a method for guaranteeing transaction durability, database software and the Operating System are the two entities which host this method, the executing subject of the method can be an apparatus for guaranteeing transaction durability, the apparatus for guaranteeing transaction durability can be a separately arranged apparatus apart from a database system, or can be integrated in the database system, this is determined according to actual needs and will not be described here. For example, the apparatus for guaranteeing transaction durability can be a mobile device, which comprises an operating system and database, as shown in Fig.4, or a server connected to UPS as shown in Fig.5.

FIG. 13 is a schematic flow diagram of a method for guaranteeing transaction durability in a database system that supports lazy commit, according to an embodiment of the present invention, as shown in FIG. 13, the method includes the following steps:

Step 101, monitoring the capability of the database system; wherein the capability comprising: battery/power level of the database system or size of the dirty transaction log, or both of them .

In the present embodiment, monitoring the capability of the database system can specifically be monitoring the database system when the database system adopting lazy commit. Monitoring the capability of the database system includes: monitoring the remaining battery capacity of the database system, or monitoring the remaining battery capacity of the database system together with the size of current dirty transaction logs of the database system, or only monitoring the size of the current dirty transaction logs. Monitoring the size of the current dirty transaction logs includes: monitoring the size of the current dirty transaction logs through tracking the changed pages in a transaction log buffer of the database system. The monitoring the database can also include: monitoring whether the database system is crashed. All of the above monitoring modes fall into the scope of monitoring a database system in the present embodiment and can be determined according to actual needs. During monitoring, the dirty transaction logs refer to transaction logs which are not yet written to the disk of the database system and are currently stored in a transaction buffer of the database, the transaction buffer can be a buffer only for storing the transaction logs, and the buffer is called a transaction log buffer.

Step 102, storing dirty transaction logs into a persistent storage when the database system crashes or remaining battery capacity of the database system reaches a preset condition or size of the dirty transaction logs of the database system reaches a first preset threshold.

In the present embodiment, the database is in a crash state refers to a crash procedure which is currently not finished. The crash state is procedure, after beginning of the crash state and before it is finished, the database is regarded as in a crash state. For example, when the database system is in a crash state, the operation of storing dirty transaction logs into a persistent storage is executed right after the database is determined as in a crash state . In the present embodiment, multiple means can be used to determine whether the database system is in a crash state or not, for example, checking whether the processing ID of the database process is alive or not, if not, it is determined that the database system is in a crash state, or checking if the database socket listening port is open or not by connecting to the port, if not, it is determined that the database system is in a crash state. Moreover, if the database is not determined to be in a crash state, storing dirty transaction logs into a persistent storage when determined that the remaining battery capacity of the database system reaches a preset condition; or, storing dirty transaction logs into the persistent storage when the size of the dirty transaction logs of the database system reaches a first preset threshold. The preset first threshold can be set according to actual needs, for example, 90% of the size of the transaction log buffer or the dirty transaction logs reach a size of for example 5GB etc. The persistent storage here can be a separated storage device or a storage device in the network.

In the present embodiment, the dirty transaction logs are stored into a persistent storage when the database system crashes or remaining battery capacity of the database system reaches a certain condition or size of the dirty transaction logs reaches certain threshold, so as to avoid the dirty transaction logs from being lost, the dirty transaction logs stored in the persistent storage can be called later when in need, thus the transaction durability during a commit process can be guaranteed.

Before step 101, the method may further include:
registering the database system so as to track the dirty transaction logs.

A transaction log comprises two parts: one part is the dirty transaction logs in the memory which is not written to a disk or other persistent storage and the other part is already stored in the disk or other persistent storage. In the present embodiment, only dirty transaction logs are tracked. Optionally all transaction logs can be tracked.

Take Linux system as an example, the above step of registering the database system so as to track the dirty logs can specifically be:

Once the database process is running, a registration system call is invoked and the operation is named as register_durability_guarantee. This registration system call has the following signature:
int register_durability_guarantee(int processId, long durability_size)

If the operating system (Operating System, OS) can guarantee this durability, the value will return to 0, else return to -1.

The transaction log buffer (cache in memory) is registered by the database process for tracking. This is done by the following new system call:
int register_dump_memory(void *p, int length)

When a checkpoint happens or the transaction logs have been written to the disk, the following new system call tells the OS that the transaction log buffer is dumped to the disk and the transaction logs are not required to be tracked. The checkpoint is a standard concept in databases. On the checkpoint all transaction logs are written to the disk from the transaction log buffer:
int set_dump_memory_valid(void *p, bool is_tracked)

In the present embodiment, the durability size, i.e. the threshold size of the dirty transaction logs, is set a minimum durability size, the minimum durability size is determined based on heuristics which is verified against the OS guarantee.

The verification is to be done on how much time can be provided to before the process shuts down. This time is generally below 1 second.

Minimum durability size Wmin differs based on the database workload. For example, comparing with other conventional systems, in a insert/delete intensive system, Wmin will be quite high.

A sample Wmin calculation is as follows:

Suppose for a given workload, there are 1000 inserts per second and each insert on an average produces about 1 KB of logging. In this case the transaction logs growth rate per second is about 1MB. This is the heuristics of this system.

In this scenario a transaction log buffer size of 100MB is reasonable. The minimum durability size can be the same as the transaction log buffer size.

On the basis of the above embodiment shown in FIG. 13, FIG. 14 is a schematic flow diagram of a method for guaranteeing transaction durability according to another embodiment of the present invention. Generally speaking, the method for guaranteeing transaction durability may be implemented in two modes. The method as shown in FIG. 14 adopts the first mode which includes:

Step 201, monitoring remaining battery capacity of a database system when it is recognized that the database system adopts lazy commit.

There are many ways to determine the capacity of an UPS or a battery, for example, when the database system is Linux system, the power source can be a UPS, the apparatus for guaranteeing transaction durability can monitor the UPS on Linux and other Unix machines, or an advanced configuration and power interface (Advanced Configuration and Power Interface, ACPI) modules monitor the power on the OS of various database systems. The ACPI supports recommendations from ACPI group, in the apparatus which monitors UPS on Linux and other Unix machines, also, the power source can be smart battery solutions using system management bus (System Management Bus, SMBus) in Linux.

Step 202, determining whether a remaining battery capacity reaches a preset second threshold, if yes, execute step 203, if not, return to step 201.

In the present embodiment, when the remaining battery capacity does not reach the preset second threshold, the monitoring the remaining battery capacity of the database system is continued, that is, execute step 201, and execute step 202.

The preset second threshold can be a preset value. For example, the preset second threshold can be a minimum power which is acquired according to actual operations and by which a current amount of dirty transaction logs is guaranteed to be stored into a persistent storage, the second threshold can be set such as 10% of battery capacity.

There exists multiple ways to acquire power level in the prior art.

For example, in Android system, power monitoring mechanisms are provided to handle battery power monitoring system. As an example, the battery capacity in Android system can specifically be:

Android Code Snippet for Battery Condition Determination

IntentFilter ifilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
Intent batteryStatus = context.registerReceiver(null, ifilter);
int level = battery.getIntExtra(BatteryManager.EXTRA_LEVEL, -1);
int scale = battery.getIntExtra(BatteryManager.EXTRA_SCALE, -1);
float batteryPct = level / (float) scale;

In the above shown snippet, we can register a handler to get notifications as to when the battery levels are changing (Intent. ACTION_BATTERY_CHANGED). Based on the notification we can judge the current level of the battery (depicted by variable “level” and “batteryPct”).

When a Linux system is adopted, ACPI modules are provided to monitor power and battery capacity.

Specifically, as an example, the determination of battery capacity in Linux system can be:

Linux Code Snippet for Battery Condition Determination
#include < linux/power_supply.h >
...
char name[]= "BAT0";
int battery_level = 0;
struct power_supply *psy = power_supply_get_by_name(name);
union power_supply_propval chargenow, chargefull;
battery_level = psy->get_property( psy, POWER_SUPPLY_PROP_CHARGE_NOW , &chargenow );

In the above shown API snippet, we use the linux API for checking the battery level. This battery level is termed as “CHARGE” in the linux API. The battery is termed as “POWER” in the linux API. Here we use an API (psy->get_property) to the battery level. The result of the battery level is stored in the variable “battery_level”.

Step 203, storing the dirty transaction logs into a persistent storage.

After step 202 and before step 203, the method can further include:
intercepting process of the database system directly or sending a signal for intercepting the process to the database system.

To be specific, the apparatus for guaranteeing transaction durability may directly intercept a current process of the database system, and store the transaction logs into the persistent storage, or the apparatus for guaranteeing transaction durability can send a signal to the database system, the signal is configured to instruct the database to intercept the current process.

In the present embodiment, through setting a battery capacity threshold to store the transaction logs into the persistent storage, such that all current transaction logs can be stored into the persistent storage, thereby guaranteeing durability of transaction.

FIG. 15 is a schematic flow diagram of a method for guaranteeing transaction durability according to another embodiment of the present invention, as shown in FIG. 3, the method is a second mode of the method for guaranteeing transaction durability which includes:

Step 301, monitoring size of current dirty transaction logs and current battery capacity of a database system when it is recognized that the database system adopts lazy commit.

As a transaction occurs, data in the database system is writing into the transaction logs continuously, thus, dirty transaction logs in the buffer also increase.

Step 302, determining whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage, if yes, it is determined that the remaining battery capacity reaches a preset condition, execute step 303, if not, return to step 301.

In the present embodiment, if the remaining battery capacity is larger than a required battery capacity to store all current dirty transaction logs into a persistent storage, the following operations of storing the dirty transaction logs into the persistent storage is not executed, but to keep on acquiring the size of current dirty transaction logs and current battery capacity of the database system, and repeat step 302 for determining.

Specifically, the determination is performed by determining the theoretical maximum size of a file which could be written without exhausting the whole battery. For example, determining whether the current battery capacity equal to a battery capacity with which the theoretical maximum size of a file which could be written without exhausting the whole battery.

This can specifically be done by retrieving the power consumption and R/W access speed. It has been proven that the power consumption for a HDD can be determined to an accuracy level by John Zedlewski et al., Modeling Hard-Disk Power Consumption, Proc. Second Conference on File and Storage Technologies, March 2003. Using these techniques we can determine that the theoretical maximum size of the dirty transaction logs that can be guaranteed.

An example of the above mechanism is given below.

The writing speed of the apparatus for guaranteeing transaction durability is expressed as Wc, which is represented in MB/sec.

Similarly by observing the battery power levels and the consumption pattern, the drain rate could be determined. This drain rate of the battery of the database system is expressed as D, which is represented in % battery power / sec.

The current battery capacity is expressed as BL, which is represented in % battery power

Using these two variables we can determine the maximum write guarantee as Wmax, which is represented in MB.
Wmax = Wc * (BL / D)
where D = ( BL1 – BL0 ) / t, BL1 is the current battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

That is, the step above can be:
acquiring a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), it is determined that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage.

An example is taken below:

If Wc is 1024MB/sec, BL = 10%, D = 2

Wmax = 1024 x (10 / 2) = 5 GB

If the current battery capacity can only maintain a successful written of 5GB dirty transaction logs, and at present there is only 5GB dirty transaction logs, then execute step 303.

It should be noted that, selection of the foregoing processing modes can be determined according to the write capacity of the apparatus for guaranteeing transaction durability. For example, then the writing speed of the apparatus for guaranteeing transaction durability reaches a third preset threshold, the above mode 2 can be adopted, if else, adopt above mode 1. For example, when the minimum durability size is 100MB, the third preset threshold is 1GB/sec, if the OS Wc is 1GB/sec, using mode 2 is safe, however, if the OS Wc is only 10MB/sec, mode 1 is preferably adopted to process transaction durability.

Step 303, storing the dirty transaction logs into the persistent storage.

In the present embodiment, through timely storing the transaction logs into the persistent storage, such that the transaction logs will not lost when the database system crashes or out of power, thereby guaranteeing durability of transaction.

An embodiment of the present invention provides an apparatus for guaranteeing transaction durability, the apparatus for guaranteeing transaction durability is configured to execute the method for guaranteeing transaction durability. The apparatus can be integrated in the database system or can be separately arranged.

As shown in FIG. 16, which is a schematic structural diagram of an apparatus for guaranteeing transaction durability provided by an embodiment of the present invention, the apparatus includes a monitoring unit 401 and a processing 402.

Wherein, the monitoring unit 401 is configured to monitor a data base system when it is recognized that the database system adopts lazy commit; and trigger a processing unit 402 when the database system crashes or remaining battery capacity of the database system reaches a preset condition or amount of the dirty transaction logs of the database system reaches a first preset threshold; the processing unit 402 is connected with the monitoring unit 401; the processing unit 402 is configured to store dirty transaction logs into a persistent storage; wherein, the dirty transaction logs refer to transaction logs which are not yet written to a disk of the database system.

Alternatively, the monitoring unit 401 is specifically configured to monitor the remaining battery capacity of the database system, determine whether the remaining battery capacity of the database system reaches a preset second threshold.

Or, alternatively, the monitoring unit 401 is further configured to monitor size of current dirty transaction logs and current battery capacity of the database system, at this time, the monitoring unit 401 monitors whether the battery capacity of the database system reaches a preset condition can specifically be:
determine whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
if yes, determine that the battery capacity of the database system reaches a preset condition.

Specifically, the monitoring unit is 401 can determine whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage by the following means:
acquire a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), determine that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
wherein, D = ( BL1 – BL0 ) / t, BL1 is the current battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

Alternatively, the processing unit is further configured to intercept process of the database system directly or send a signal for intercepting the process to the database system.

Alternatively, the processing unit is further configured to register the database system so as to track dirty transaction logs.

The operations of apparatus for guaranteeing transaction durability are the same with the steps executed by the corresponding method, which will not be described here.

According to the apparatus 400 for guaranteeing transaction durability provided by the present embodiment, when the database system crashes or remaining battery capacity of the database system reaches a certain level or size of the dirty transaction logs of the database system reaches a certain threshold, dirty transaction logs are timely stored into a persistent storage, such that to avoid the dirty transaction logs from being lost, the dirty transaction logs stored in the persistent storage can be called later when in need, thus the transaction durability during commit process can be guaranteed.

An embodiment of the present invention provides an apparatus for guaranteeing transaction durability. As shown in FIG. 17, which is a schematic structural diagram of an apparatus for guaranteeing transaction durability provided by another embodiment of the present invention. The apparatus includes at least one processor 501, a communication bus 502, a memory 503 and at least one communication port 504.

Wherein, the communication bus 502 is configured to achieve the connection and communication of the above unit, the communication port 504 is configured to connect a network device and communicate with it. The bus can be industry standard architecture (Industry Standard Architecture, ISA) bus, peripheral component interface (Peripheral Component Interface, PCI) bus or extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus etc. The bus can be one or more physical bus, when there are multiple buses, the buses can be divided as address bus, data bus and control bus etc.

Wherein, the memory 503 is configured to store executable programming codes, wherein, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, such that to:
monitor a database system when it is recognized that the database system adopts lazy commit;
store dirty transaction logs into a persistent storage when the database system crashes or remaining battery capacity of the database system reaches a preset condition or amount of the dirty transaction logs of the database system reaches a first preset threshold, wherein, the dirty transaction logs refer to transaction logs which are not yet written to a disk of the database system.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, such that to monitor the database system can specifically be:
monitor the remaining battery capacity of the database system;
correspondingly, determine whether the remaining battery capacity of the database system reaches the preset condition specifically comprises: monitoring whether the battery capacity reaches a preset second threshold.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, such that to monitor the database system can specifically be:
monitor an amount of current dirty transaction logs and current battery capacity of the database system.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, such that to determine that the battery capacity of the database system reaches a preset condition can specifically be:
determine whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
if yes, it is determined that the battery capacity of the database system reaches a preset condition.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, such that to determine that whether the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage can specifically be:
acquire a size Wmax of the current dirty transaction logs of the database system, a drain rate D of the battery of the database system, a current remaining battery capacity BL of the database system and a writing speed Wc of storing the dirty transaction logs into the persistent storage;
when Wmax = Wc * ( BL / D ), it is determined that the remaining battery capacity is equal to a required battery capacity to store all current dirty transaction logs into a persistent storage;
wherein, D = ( BL1 – BL0 ) / t, BL1 is the current battery level of the database system, BL0 is the initial battery level of the database system, t is the time which the battery has been used.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, after monitor the database system and before store the dirty transaction logs of the database system into the persistent storage, such that to:
intercept process of the database system directly or sending a signal for intercepting the process to the database system.

Alternatively, the processor 501 reads the executable programming codes stored in the memory 503 to operate a program corresponding to the executable programming codes, before monitor the database system, such that to:
register the database system so as to track dirty transaction logs.

According to the apparatus 500 for guaranteeing transaction durability provided by the present embodiment, when the database system crashes or battery capacity of the database system reaches a certain level or size of the dirty transaction logs of the database system reaches a certain threshold, dirty transaction logs are timely stored into a persistent storage, such that to avoid the dirty transaction logs from being lost, the dirty transaction logs stored in the persistent storage can be called later when in need, thus the transaction durability during commit process can be guaranteed.

When being implemented as a software function unit and sold or used as a stand-alone product, the functions may be stored in a computer-readable storage medium. Based on this understanding, the essence of the technical solution of the present invention, or the part which contributes to the prior art, or part of the technical solutions, may be embodied in a software product. The software product may be stored in a computer-readable storage medium and incorporates several instructions for instructing a computer device (for example, personal computer, server, or network device etc) to execute all or part of the steps of the method specified in any embodiment of the present invention. Examples of the storage medium include various media capable of storing program codes, such as a USB flash disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk, or an optical disk etc.

A person of ordinary skill in the art may understand that, all or a part of the steps of the foregoing method embodiments may be implemented by a program instructing relevant hardware. The aforementioned program may be stored in a computer readable storage medium. When the program runs, the steps of the forgoing method embodiments are performed. The storage medium includes any medium capable of storing program code, such as a ROM, a RAM, a magnetic disk, or an optical disc.

Finally, it should be noted that the foregoing embodiments are merely intended for describing the technical solutions of the present invention rather than limiting the present invention. Although the present invention is described in detail with reference to the foregoing embodiments, persons of ordinary skill in the art should understand that they may still make modifications to the technical solutions described in the foregoing embodiments, or make equivalent replacements to some or all the technical features thereof, as long as such modifications and replacements do not cause the essence of corresponding technical solutions to depart from the scope of the technical solutions of the embodiments of the present invention.

The term "and/or" in the embodiments of the present invention indicates only an association between associated objects, and represents that three relationships may exist, for example, A and/or B may represent the three cases: Only A exists, both A and B exist, and only B exists. In addition, the character "/" in this document generally represents that the former and latter associated objects are in an "or" relationship.