CN106776136A - 数据库处理方法和装置 - Google Patents

Abstract

本申请的实施方式提供了数据库处理方法和装置。本申请中由于预解析结果是对操作日志文件进行预解析获得的，预解析即不需要将操作日志文件中的所有内容都解析出来。这样，解析结果的数据量将小于现有技术中的数据量。而且，预解析的速度也会高于现有技术中的解析速度。从而能够降低对操作日志文件进行解析所耗费的时间。此外，根据预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。这样，用户可以通过按时序展示的结果，一目了然的了解各事务的操作时间，从而能够使用户快速的查找到恢复点。从而，进一步提高确定恢复点的效率，为用户带来了更好的应用体验。

Description

数据库处理方法和装置

技术领域

本申请的实施方式涉及信息处理领域，更具体地，本申请的实施方式涉及数据库处理方法和装置。

背景技术

本部分旨在为权利要求书中陈述的本申请的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

目前，随着数据量的不断增大，数据库成为用户管理数据的优选方式。

具体来说，在管理数据的过程中需要不断对数据库进行更新。有时候，基于某种特定需求，需要将数据库恢复到某个特定的状态。例如，将已更新的数据库恢复到前一天的状态。

现有技术中进行数据库恢复时，通常采用PIT(point in time recovery，恢复点)恢复。该恢复点可以是一个具体的时间点，也可以是数据库的操作日志文件(例如BinLog文件)中的一个具体的偏移位置。

发明内容

出于现有技术中没有给出如何确定恢复点的具体方案的原因，现有技术中，如果要确定一个恢复点时，通常需要解析出操作日志文件的所有信息；然后打开解析结果，人工从海量的解析结果中查找恢复点。

因此在现有技术中，由于数据库的操作日志文件中包含大量的数据，而恢复点淹没在大量的无关数据中。用户很难在密密麻麻的数据中查找到恢复点。故此，现有技术中恢复点的确定十分繁琐，效率低下。此外，通常情况下，操作日志文件的数据量比较大，将如此大的文件解析出来需要耗费很多的时间，解析效率低。故此，进一步导致恢复点的确定需要耗费较多的时间。这是非常令人烦恼的过程。

为此，非常需要一种改进的数据库处理方法和装置，以使用户能够便捷地确定恢复点，以便于提高数据库的恢复效率，提高用户的应用体验。

在本上下文中，本申请的实施方式期望提供一种数据库处理方法和装置。

在本申请实施方式的第一方面中，提供了一种数据库处理方法，包括：

从预存的预解析结果中获取待展示事务的起止时间，其中，所述预解析结果为对数据库的操作日志文件进行预解析后获得的结果；

根据待展示事务的起止时间，确定待展示事务在预设时间轴上对应的时间点；

根据所述预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。

在本申请实施方式的第二方面中，提供了一种数据库处理装置，包括：

待展示事务获取模块，用于从预存的预解析结果中获取待展示事务的起止时间，其中，所述预解析结果为对数据库的操作日志文件进行预解析后获得的结果；

时间点确定模块，用于根据待展示事务的起止时间，确定待展示事务在预设时间轴上对应的时间点；

事务展示模块，用于根据所述预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。

在本申请实施方式的第三方面中，提供了一种数据库处理设备，例如，可以包括存储器和处理器，其中，处理器可以用于读取存储器中的程序，执行下列过程：

从预存的预解析结果中获取待展示事务的起止时间，其中，所述预解析结果为对数据库的操作日志文件进行预解析后获得的结果；

根据待展示事务的起止时间，确定待展示事务在预设时间轴上对应的时间点；

根据所述预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。

在本申请实施方式的第四方面中，提供了一种程序产品，其包括程序代码，当所述程序产品运行时，所述程序代码用于执行以下过程：

从预存的预解析结果中获取待展示事务的起止时间，其中，所述预解析结果为对数据库的操作日志文件进行预解析后获得的结果；

根据待展示事务的起止时间，确定待展示事务在预设时间轴上对应的时间点；

根据所述预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。

根据本申请实施方式的数据库处理方法和装置，由于预解析结果是对操作日志文件进行预解析获得的，预解析即不需要将操作日志文件中的所有内容都解析出来。这样，解析结果的数据量将小于现有技术中的数据量。而且，预解析的速度也会高于现有技术中的解析速度。从而能够降低对操作日志文件进行解析所耗费的时间。此外，根据预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。这样，用户可以通过按时序展示的结果，一目了然的了解各事务的操作时间，从而能够使用户快速的查找到恢复点。从而，进一步提高确定恢复点的效率，为用户带来了更好的应用体验。

附图说明

通过参考附图阅读下文的详细描述，本申请示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本申请的若干实施方式，其中：

图1示意性地示出了根据本申请实施方式的应用场景示意图；

图2示意性地示出了根据本申请另一实施例的数据库处理方法的流程示意图；

图3示意性地示出了根据本申请又一实施例的展示界面的示意图；

图4示意性地示出了根据本申请再一实施例的展示界面的示意图；

图5示意性地示出了根据本申请再一实施例的展示界面的示意图；

图6示意性地示出了根据本申请再一实施例的展示界面的示意图；

图7示意性地示出了根据本申请再一实施例的数据库处理方法的流程示意图；

图8示意性地示出了根据本申请再一实施例的数据库处理装置的结构示意图；

图9示意性地示出了根据本申请再一实施例的数据库处理装置的结构示意图；

图10示意性地示出了根据本申请一实施例的数据库处理的程序产品的结构示意图；

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本申请的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本申请，而并非以任何方式限制本申请的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本申请的实施方式可以实现为一种***、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本申请的实施方式，提出了一种数据库处理方法和装置。

在本文中，需要理解的是，所涉及的术语：

1、事务：是恢复和并发控制的基本单位；事务由事务开始(begin transaction)和事务结束(end transaction)之间执行的全体操作组成，故此一个事务包括起止时间(即事务开始时间和事务结束时间的总称)。其中，在关系数据库中，一个事务可以是一条SQL(Structured Query Language，结构化查询语言)语句，一组SQL语句或整个程序。

2、操作日志文件：指用于记录数据库的操作日志的文件，例如BinLog文件。

操作日志文件中可以包括多个操作事件，例如Insert(***)、Delete(删除)、Update(更新)等DML(data manipulation language，数据操作语言)类型的Event(事件)，也可以包括Query(查询)Event等其他类型Event

3、PIT恢复：指将数据库数据恢复到确定的某一点上，该点可以是时间点，也可能是操作日志文件中某个偏移位置。

4、向前回放：一种基于PIT恢复的数据库恢复方式，在指定开始恢复点和终止恢复点之后，采用回放操作日志文件的方式进行数据库恢复。

5、向后回溯：一种基于PIT恢复的数据库恢复方式，在指定开始恢复点和终止恢复点之后，采用回滚的方式进行数据库恢复，例如，数据库操作是删除A信息，则回滚时的操作是添加A信息。

此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本申请的若干代表性实施方式，详细阐释本申请的原理和精神。

发明概述

本申请人发现，现有技术中，没有给出如何确定恢复点的具体方案的原因，现有技术中，如果要确定一个恢复点时，通常需要解析出操作日志文件的所有信息；然后打开解析结果，人工从海量的解析结果中查找恢复点。因此在现有技术中，由于数据库的操作日志文件中包含大量的数据，而恢复点淹没在大量的无关数据中。用户很难在密密麻麻的数据中查找到恢复点。故此，现有技术中恢复点的确定十分繁琐，效率低下。此外，通常情况下，操作日志文件的数据量比较大，将如此大的文件解析出来需要耗费很多的时间，解析效率低。故此，进一步导致恢复点的确定需要耗费较多的时间。导致用户的应用体验差。

本申请实施例中，由于预解析结果是对操作日志文件进行预解析获得的，预解析即不需要将操作日志文件中的所有内容都解析出来。这样，解析结果的数据量将小于现有技术中的数据量。而且，预解析的速度也会高于现有技术中的解析速度。从而能够降低对操作日志文件进行解析所耗费的时间。此外，根据预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。这样，用户可以通过按时序展示的结果，一目了然的了解各事务的操作时间，从而能够使用户快速的查找到恢复点。从而，进一步提高确定恢复点的效率，为用户带来了更好的应用体验。

在介绍了本申请的基本原理之后，下面具体介绍本申请的各种非限制性实施方式。

应用场景总览

首先参考图1其为本申请实施例提供的数据库处理方法的应用场景示意图。该场景例如可以包括用户10、用户终端11和服务器12。其中，所述用户终端11中可安装有各种客户端，如数据查询客户端、网易新闻客户端、优酷视频客户端等。用户10可基于所述用户终端11中的客户端，向所述客户端或服务器12下发查找恢复点的指令；由所述用户终端11中的客户端或服务器12根据所述指令，从预存的预解析结果中获取待展示事务的起止时间；根据待展示事务的起止时间，确定该待展示事务在预设时间轴上对应的时间点；并根据所述预设时间轴，在确定的时间点的预设对应位置显示该待展示事务的事务标识。

其中，对数据库的操作日志文件的预解析可以由用户终端11或客户端完成；当然也可以由服务器12完成。当由服务器完成对操作日志文件的预解析并存储解析结果时，用户可以基于所述用户终端11中的客户端，向所述客户端下发查找恢复点的指令；由用户终端11中的客户端根据该指令，请求服务器从预存的预解析结果中获取待展示事务的起止时间；服务器获取待展示事务的起止时间后发送给客户端，由客户端根据待展示事务的起止时间，确定该待展示事务在预设时间轴上对应的时间点；并，根据所述预设时间轴，在确定的时间点的预设对应位置显示该待展示事务的事务标识。此外，也可以由服务器管理员直接向服务器输入指令，由服务器获取待展示事务的起止时间，根据待展示事务的起止时间，确定该待展示事务在预设时间轴上对应的时间点；并，由服务器相应的显示设备，根据所述预设时间轴，在确定的时间点的预设对应位置显示该待展示事务的事务标识。

也就是说，本申请实施例提供的数据库处理方法既可以由网络侧的服务器实施，也可以由安装于用户终端中的客户端，甚至用户终端实施，亦或者，可以部分由服务器实施，部分由客户端或终端实施，本申请对此不作任何限定。

其中，用户终端11和服务器12可通过通信网络进行通信连接，该网络可以为局域网、广域网等。用户终端11可以为手机、平板电脑、笔记本电脑、个人计算机等，服务器12可以为任何能够支持相应的数据库处理的服务器设备。

示例性方法

下面结合图1的应用场景，参考图2-10来描述根据本申请示例性实施方式的数据库处理方法。需要注意的是，上述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。相反，本申请的实施方式可以应用于适用的任何场景。

如图2所示，为本申请提供的数据库处理方法的流程示意图，包括：

步骤201：从预存的预解析结果中获取待展示事务的起止时间，其中，预解析结果为对数据库的操作日志文件进行预解析后获得的结果。

步骤202：根据待展示事务的起止时间，确定待展示事务在预设时间轴上对应的时间点。

其中，在一个实施例中，每个待展示事务包括起止时间，即事务开始时间和事务结束时间。具体实施时，针对各待展示事务，可以将该待展示事务的事务开始时间确定为该待展示事务在预设时间轴上对应的时间点；同理，也可以将该待展示事务的事务结束时间确定为该待展示事务在预设时间轴上对应的时间点；此外，还可以从事务开始时间至事务结束时间之间的时间段内选择一个时间点，并将选择的时间点确定为待展示事务在预设时间轴上对应的时间点。

步骤203：根据预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。

例如，如图3所示，假设待展示事务包括4个，如图3中的事务1、事务2、事务3和事务4，然后在对应位置显示各待展示事务的事务标识。在图3中，时间轴上的T1、T2、T3、T4可以是步骤202中确定的待展示事务在预设时间轴上对应的时间点，也可以是时间轴上的时间刻度。具体实施时，可以根据实际需要确定时间轴上时间点表示的内容，只要能够使用户通过时间轴能够了解各待展示事务的操作时间即可，本申请对此不作限定。

其中，在一个实施例中，为了便于用户准确的确认恢复点，本申请实施例中，用户可以通过查看事务的详细信息来确定查看的事务是否是需要的恢复点。例如，在同一时间段，事务数量较多的情况下，也许用户需要查看事务的详细信息来确定哪个事务是恢复点。故此，本申请实施例中，在步骤203(即根据预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识)之后，方法还包括：

步骤A1：接收到对事务标识的选择指令后，显示选择的事务的起止时间。

步骤A2：获取选择的事务包含的DML类型的操作事件及操作事件的操作时间并显示。

例如，继续沿用图3所示的例子。用户可以通过点击选择事务2，然后，展示出如图4所示的界面。在图4所示的界面中显示出了事务2的事务开始时间，事务结束时间以及包含的DML操作为Insert、Delete。其中，Insert的操作时间为2016.11.2.10:02:04；Delete的操作时间为2016.11.2.10:04:05。这样，用户可以通过事务2的详细信息，进一步确认恢复点是否是事务2。需要说明的是，图4仅用于示例性说明如何展示选择的事务的详细信息，具体实施时，可以根据实际需求确定界面的展示方式，本申请对此不作限定。

当然，还需要说明的是，具体实施时，执行步骤203时，还可以将各待展示事务的起止时间和包含的DML操作与事务标识同时展示出来，而无需用户选择指定事务后展示。这样，可避免用户执行选择指定事务的操作步骤，简化操作流程。

其中，在一个实施例中，步骤A2中获取选择的事务包含的DML类型的操作事件及操作事件的操作时间，可具体包括以下两种实施方式：

方式1：预解析操作日志文件的时候，可以将事务包含的DML类型的操作事件及操作事件的操作时间一同解析出来存储在月解析后获得的结果中。这样，可以从预解析结果中获取选择的事务包含的DML类型的操作事件及操作事件的操作时间。

方式2：预解析的时候，可以解析出各事务在操作日志文件中的位置信息，并存储在预解析结果中。然后，可以从预解析结果中获取选择的事务在操作日志文件中的位置信息，根据位置信息，从操作日志文件中解析出选择的事务包含的DML类型的操作事件及操作事件的操作时间。

这样，具体实施时，可以根据实际需要和存储空间，确定预解析的时候解析出何种信息存储。能够满足用户的实际需求，提高用户的应用体验。

其中，在一个实施例中，为便于进一步确认哪个事务是恢复点，还可以从预解析结果中获取选择的事务涉及的数据库和/或表信息并显示。这样，相当于使用户进一步根据事务涉及的数据库和/或表信息来确认哪个事务是恢复点。以便于提高确定恢复点的准确性。

其中，在一个实施例中，还可以通过以下方法获取和查看事务的详细信息，以便于确定恢复点。具体的，包括：

步骤B1：接收到请求获取指定事务的详细信息的指令后，确定指定事务的数据量。

指定事务的详细信息，例如是上述的包含的DML类型的操作事件、操作事件的操作时间、涉及的数据库、涉及的表信息中的至少一种。当然，详细信息还可以包括事务在相应操作日志文件中的位置信息，例如起始位置和结束位置。进一步的详细信息中还可以包括操作时间的具体内容，例如insert1，update3到4，即具体执行了何种操作，以及操作结果可以包含在详细信息中。

步骤B2：若数据量小于预设数据量，则解析指定事务的详细信息并显示；若数据量大于或等于预设数据量，则解析指定事务的详细信息后将解析结果存储到对象存储服务器上，并展示存储地址。

例如，客户端展示待展示事务，而由服务器解析指定事务的详细信息时，服务器可以根据指定事务的数据量来确定是返回给客户端存储地址还是返回解析出来的详细信息。这样，可以根据实际需要返回给客户端的具体内容。

其中，在一个实施例中，可以根据以下方法之一或组合，来确定待展示事务，具体的：

方法一：将选择的操作日志文件包含的事务确定为待展示事务：

其中，在一个实施例中，操作日志文件可以有多个。通常情况下每个操作日志文件中会包含多个事务。故此，本申请实施例中，为了能够在有限的展示空间中尽可能的展示用户最需要的事务，预解析结果中还包括操作日志文件的创建时间和关闭时间；从预存的预解析结果中获取待展示事务的起止时间之前，方法还包括：

步骤C1：根据预设时间轴，显示操作日志文件的文件标识及其对应的创建时间和结束时间。

步骤C2：接收到对文件标识的选择指令后，将选择的操作日志文件包含的事务确定为待展示事务。

例如，图5为显示操作日志文件的文件标识及其对应的创建时间和结束时间的示意图。在图5中，文件标识A对应的创建时间为A1，结束时间为A2；文件标识B对应的创建时间为B1，结束时间为B2；文件标识C对应的创建时间为C1，结束时间为C2。当然，需要说明的是，图5仅是示例性说明本申请实施例。具体实施时，界面如何设计以及以何种方式显示创建时间和结束时间可以根据实际需求确定，本申请对此不作限定。

也就是说，可以先展示各个操作日志文件及对应的时间，然后根据用户的选择，确定待展示事务然后进入到图3的界面中展示各待展示事务。这样，用户可以根据时间轴和自己已知的大概的时间范围，快速地查找到需要详细了解的操作日志文件及待展示事务。

方法二：根据用户的查询条件确定待展示事务：

接收用户输入的查询条件，将符合查询条件的事务确定为待展示事务；其中，查询条件包括以下中的至少一种：

1)、指定时间段：例如，查找20116年11月21日上午8:00:00-10:00:00这段时间的事务作为待展示事务。这样，可以过滤掉其他时间段无关的事务，而在界面中展示有关的事务，能够进一步帮助用户确定恢复点，提高确定恢复点的效率。

2)、指定数据库：例如，用户建立的数据库包括数据库A和数据库B，而查找的事务仅仅与数据库A有关，则可以指定查找涉及数据库A的事务作为待展示事务。

3)、指定表信息：例如，可以查找与表b和表c有关的事务作为待展示事务。

4)、指定DML操作类型：例如，可以进查找包含Insert类型的事务作为待展示事务。

5)、指定需要过滤的数据库：例如，用户不知道与哪些数据库有关，却能够确定与哪些数据库无关时，可以设定查找条件为过滤到指定需要过滤的数据库。例如，确定与数据库B无关，则确定的待展示事务为与数据库B无关的事务。

6)、指定需要过滤的表信息：例如，用户确认与哪些表无关时，可以指定需要过滤的表信息。这样，将与指定需要过滤的表信息无关的事务作为待展示事务。

7)、指定需要过滤的DML操作类型：例如，指定需要过滤的DML操作类型为Update，则将除Update之外的DML操作类型的事务作为待展示事务。

当然，查询条件可以组合使用，例如查询条件为要求返回指定数据库在指定时间段内的指定DML操作类型的事务。这样，用户可以根据自己的需要，精确的确定查找何种事务。从而便于减少待展示事务的数量，那么用户就可以根据少量的待展示事务确定恢复点，从而提高恢复点的确定效率，提高用于的应用体验。

简言之用户可以根据自身的需求配置查询条件。这样，通过查询条件，可以过滤掉无关的事务，而返回用户需要的事务作为待展示事务。这样能够减少展示的事务的数量，用户可以从数量较少的事务中确定恢复点，从而提高恢复点的确定效率。

上述确定待展示事务的方法一和方法二也可以结合。例如是，根据方法一确定对哪个操作日志文件进行查询，然后根据方法二的查询条件将需要查询的操作日志文件中根据查询条件的得到的事务作为待展示事务进行操作。这样，可以仅在选择的操作日志文件中查询事务，能够提高查询的效率。

其中，在一个实施例中，当需要展示的内容较多时(例如操作日志文件较多或待展示事务较多时)，为了便于用户查看和查找恢复点，还可包括以下方法：

步骤D1：接收用于缩放时间轴的缩放指令。

步骤D2：根据缩放指令，缩放预设时间轴。

例如，当时间轴的某一时间段内对应展示有100个待展示事务，但是100个待展示事务集中在一起展示，事务标识之间将会有互相重叠和遮挡的情况。那么，用户将无法了解各待展示事务的事务标识，所以用户可以放大时间轴。放大后，各待展示事务的标识可以完全展示出来，以便于用户清楚的辨识各个事务，从而方便地查找恢复点。

当然，具体实施时，当时间轴的指定单位时间段内展示的待展示事务数量较多时，如图6所示，可以单位时间段内选择预设数量的事务标识展示，并展示该指定单位时间段内用于的待展示事务数量。这样，展示的图既美观，也便于用户确定是否缩放时间轴。

其中，在一个实施例中，为了使数据库恢复到需要的状态，还可包括以下方法：

步骤E1：接收将选择的事务确定为恢复点的恢复请求。

步骤E2：根据恢复点进行数据库恢复。

这样，可以将恢复点的确定和数据库的恢复操作集成在一起完成，也即使得恢复点的确定和数据库的恢复这两个环节一气呵成，能够提高用户的应用体验。

其中，在一个实施例中，根据恢复点进行数据库恢复，可具体包括：若存在需要恢复的数据库的数据库实例，则将数据库实例恢复到恢复点。这样，可以优先根据数据库实例，精确地恢复数据库。

其中，在一个实施例中，根据恢复点进行数据库恢复，具体还可包括：

步骤E21：若存在需要恢复的数据库的多个全量备份，根据每个全量备份的操作日志计算每个全量备份恢复到恢复点所需要处理的数据量，并选择计算的数据量最小的全量备份；或者，选择全量备份的备份结束时间与恢复点的结束时间之间的时间差值最小的全量备份。

步骤E22：将选择的全量备份恢复到恢复点。

这里举例说明步骤E21-步骤E22：

例如，假设数据库恢复前满足以下条件：

条件1、恢复点为t；

条件2、具有名称分别为H1、H2和H3的三个全量备份，对应的备份结束时间分别为t1、t2、t3；

则可以通过以下两种方式确定选择哪个全量备份进行数据库恢复，具体的：

方式1，若每个全量备份都有对应的操作日志，则计算H1的操作日志中t1-t之间的数据量；计算H2的操作日志中t2-t之间的数据量；计算H3的操作日志中t3-t之间的数据量，选取计算的数据量最小的全量备份用于数据库恢复

方式2、计算t1、t2、t3分别和t的差值，作为对应全量备份的时间差值。例如若t2与t之间的差值最小，则选择H2用于数据库恢复。

也就是说，根据需要处理的数据量或时间差值来确定选择哪个全量备份进行恢复。这样，能够提高数据库恢复的效率。

其中，在一个实施例中，步骤E21中将选择的全量备份恢复到恢复点，具体包括：

步骤E211：比较选择的全量备份的备份结束时间与恢复点的结束时间之间的时间先后顺序。

步骤E212：若备份结束时间在恢复点的结束时间之后，则采用向后回溯的方式将选择的全量备份恢复到恢复点；若备份结束时间在恢复点的结束时间之前，则采用向前回放的方式将选择的全量备份恢复到恢复点。

这样，可以采用最佳的数据恢复方式进行数据恢复，提高数据恢复的准确性。

其中，在一个实施例中，若采用向后回溯的方式进行数据库恢复，则需要较大的内存空间。假设Binlog文件中需要进行向后回溯操作的内容为区间pos1-pos2，其中，恢复点为pos1。pos1-pos2包括的操作按时间先后顺序依次为delete4、update2到3(即将2更新为3)、insert1.则采用向后回溯方式进行恢复时，需要回滚数据。即，需要先将insert1解析为delete1后保存到内存中、将update2到3解析为update3到2保存在内存中且存储在delete1之前、将delete4解析为insert4保存在内存中且保存在update3到2之前。将区间pos1-pos2所以内容都解析且保存在内存之后，从内存中依次读取保存的操作，然后执行。如果区间pos1-pos2数据量较大，内存不足的情况下，将由于内存不足导致解析失败，最终导致无法恢复数据库。故此，为了能够顺利的进行数据恢复，本申请实施例中，根据恢复点进行数据库恢复，具体包括：

步骤F1：根据空闲内存空间，将需要恢复的数据库的从当前状态恢复到恢复点之间需要恢复的事务划分为多个事务集，其中，事务集的数据量小于或等于空闲内存空间。

可以根据空间内存空间和各事务的数据量来划分事务集。当然，也可以根据空闲内存空间和事务的实际数据量，将预设数量的事务划分到一个事务集中。具体实施时，可以根据实际需要划分事务集，只要能够避免内存不足导致解析失败即可，本申请对此不作限定。

步骤F2：按照恢复顺序和恢复点，根据划分好的多个事务集进行数据库恢复。

其中恢复顺序，即先恢复操作日志文件中起止时间最晚的事务。例如，事务1在上午操作，事务2在与事务1同一天的下午操作，则先恢复事务2再恢复事务1。

也就是说，本申请实施例中，以事务集为单位，将需要恢复的数据划分为多段来适应内存空间。这样，能够避免由于内存不足倒数的恢复失败。能够提高数据库恢复的效率。

其中，在一个实施例中，为了提高数据库恢复的准确性，有些操作的恢复需要针对不同的数据库和/或不同的表进行。例如同一操作，有些数据库需要恢复，但有效数据库不需要恢复。再例如，数据库恢复时，有些表需要恢复，但有些表却不需要恢复。故此，本申请实施例中，根据恢复点进行数据库恢复之前，方法还包括：

步骤G1：接收输入的恢复条件；恢复条件包括以下中的至少一种：指定需要过滤的数据库、指定需要恢复的数据库、指定需要过滤的表信息、指定需要恢复的表信息、指定需要恢复的DML操作类型。

其中，若恢复条件包括需要过滤的数据库，则可以认为是进行恢复时不对这类数据库进行操作；同理，指定需要恢复的数据库则可以认为是进行恢复时对这类数据库进行操作。其它信息，同理不再赘述。

这样，根据恢复点进行数据库恢复，可具体包括：根据恢复条件，和恢复点进行数据库恢复。

综上，本申请实施例中，通过预解析数据库的操作日志中的关键信息(如事务的起止时间)，并根据时间轴展示出来，从而便于用户能够直观地、一目了然的查找到视为恢复点的事务。从而能够提高恢复点确定的效率，进而提高数据库恢复的效率。

此外，本申请实施例中，在确定恢复点时，还可以允许用户输入查询条件，从而过滤掉无关事务，仅为用户展示需要的事务，从而减少展示的事务的数量，进一步帮助用户快速的确定恢复点，提高恢复点的确定效率，提高用户的应用体验。

此外，本申请实施例中，在进行数据库恢复时，也能实现更细粒度的恢复，例如可以仅针对某些数据库进行恢复操作，甚至仅针对某些表进行恢复操作，使得数据库的恢复更加准确、快速，同时还能避免无关的数据库或表受恢复操作的影响。

另外，本申请实施例中，通过根据空闲内存空间将需要恢复的事务划分为事务集，能够避免由于内存不足导致恢复失败，使得数据库恢复能够顺利进行。

下面，为便于进一步理解本申请实施例提供的数据库处理方法，参考图7，对该方法作进一步说明。

在图7所示实施例中，预解析时需要解析的内容可包括操作日志文件的创建时间和关闭时间、操作日志文件中包含的事务的起止时间、各事务包含的DML类型的操作事件及操作事件的操作时间、还有各事务涉及的数据库、各事务设计的表信息。并将预解析结果存放到解析结果数据库中以便于查询。其中，本实施例中可以由服务器完成操作日志文件的解析并维护解析结果数据库。具体进行数据库处理时，可包括以下步骤：

步骤701：终端发送待处理数据库标识给服务器。

步骤702：服务器从解析结果数据库查询与处理数据库标识对应的操作日志文件的创建时间和关闭时间，并发送给终端。

步骤703：终端根据预设时间轴，显示操作日志文件的文件标识及其对应的创建时间和结束时间。

步骤704：终端接收用户输入的查询条件，并接收到对文件标识的选择指令后将选择的文件标识对应的操作日志文件中符合查询条件的事务确定为待展示事务，并请求服务器返回待展示事务。

其中，服务器可以将待展示事务的起止时间、包含的数据操作语言DML类型、以及涉及的数据库和表信息发送给终端。

步骤705：终端根据待展示事务的起止时间，确定待展示事务在预设时间轴上对应的时间点。

步骤706：终端根据预设时间轴，在确定的时间点的预设对应位置显示该展示事务的事务标识。

步骤707：终端接收到对事务标识的选择指令后，显示选择的事务的起止时间、包含的DML类型的操作事件、以及涉及的数据库和表信息。

具体实施时，在步骤703之后和步骤708之前，还可以接收用于缩放时间轴的缩放指令；根据缩放指令，缩放预设时间轴。以便于用户查看数据库的事务。

步骤708：终端接收到请求获取指定事务的详细信息的指令后，发送查看指定事务的详细信息的请求服务器。

步骤709：服务器确定指定事务的数据量；若该数据量大于或等于预设数据量，则解析指定事务的详细信息后将解析结果存储到对象存储服务器上，并发送存储地址给终端显示；若该数据量小于预设数据量，则解析指定事务的详细信息并发送给终端显示。

详细信息，例如是指定事务中包含的操作事件的操作时间、操作的结果等。有助于用户进一步确认指定时间是否是恢复点。

步骤710：终端接收将选择的事务确定为恢复点的恢复请求。

步骤711：终端接收输入的恢复条件。

如前文所述，恢复条件包括以下中的至少一种：指定需要过滤的数据库、指定需要恢复的数据库、指定需要过滤的表信息、指定需要恢复的表信息、指定需要恢复的DML操作类型。

步骤712：查找是否存在待处理数据库的数据库实例，若是，执行步骤713，若否，执行步骤714。

步骤713：根据恢复条件，将数据库实例恢复到恢复点。

步骤714：若存在待处理数据库的多个全量备份，根据每个全量备份的操作日志计算每个全量备份恢复到恢复点所需要处理的数据量，并选择计算的数据量最小的全量备份；或者，选择全量备份的备份结束时间与恢复点的结束时间之间的时间差值最小的全量备份；根据恢复条件，将选择的全量备份恢复到恢复点。

具体实施时，步骤713和步骤714进行数据库恢复时，若采用向后回溯的方式进行数据库恢复，则根据空闲内存空间，将需要恢复的事务划分为多个事务集，其中，事务集的数据量小于或等于空闲内存空间；然后，按照恢复顺序和恢复点，根据划分好的多个事务集进行数据库恢复。这样，可以避免内存不足导致的数据库恢复失败。

综上所述，本申请实施例中，服务器对操作日志文件进行预解析，预解析时无需将操作结果的解析出来。相比于现有技术将操作日志文件全部解析出来能够提高解析的速度，能够占用较少的处理资源。而且，通过时间轴，展示操作日志文件及其事务的信息，能够帮助用户根据时间查找事务以及确定恢复点。此外，通过查询条件和恢复条件可以帮助用户更好的进行相关的操作，提高数据库恢复的效率。

示例性设备

在介绍了本申请示例性实施方式的数据库处理方法之后，接下来，参考图8对本申请示例性实施方式的数据库处理装置进行说明。

如图8所示，为本申请实施例提供的数据库处理装置的结构示意图，包括：

待展示事务获取模块801，用于从预存的预解析结果中获取待展示事务的起止时间，其中，所述预解析结果为对数据库的操作日志文件进行预解析后获得的结果；

时间点确定模块802，用于根据待展示事务的起止时间，确定待展示事务在预设时间轴上对应的时间点；

事务展示模块803，用于根据所述预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。

其中，在一个实施例中，所述根据所述预设时间轴，所述方法还包括：

事务起止时间展示模块804，用于在事务展示模块803确定的时间点的预设对应位置显示待展示事务的事务标识之后，接收到对事务标识的选择指令后，显示选择的事务的起止时间；

事件展示模块805，用于获取所述选择的事务包含的DML类型的操作事件及操作事件的操作时间并显示。

其中，在一个实施例中，所述装置还包括：

库表展示模块806，用于从所述预解析结果中获取所述选择的事务涉及的数据库和/或表信息并显示。

其中，在一个实施例中，所述事件展示模块805，具体包括：

DML事件第一获取单元807，用于从预解析结果中获取所述选择的事务包含的DML类型的操作事件及操作事件的操作时间；或者，

DML事件第二获取单元808，用于从预解析结果中获取所述选择的事务在操作日志文件中的位置信息，根据所述位置信息，从操作日志文件中解析出所述选择的事务包含的DML类型的操作事件及操作事件的操作时间。

其中，在一个实施例中，所述预解析结果中还包括操作日志文件的创建时间和关闭时间；所述装置还包括：

日志文件展示模块809，用于所述待展示事务获取模块801从预存的预解析结果中获取待展示事务的起止时间之前，根据所述预设时间轴，显示操作日志文件的文件标识及其对应的创建时间和结束时间；

待展示事务确定模块810，用于接收到对文件标识的选择指令后，将选择的操作日志文件包含的事务确定为待展示事务。

其中，在一个实施例中，所述装置还包括：

查询条件处理模块811，用于所述待展示事务获取模块801从预存的预解析结果中获取待展示事务的起止时间之前，接收用户输入的查询条件，将符合所述查询条件的事务确定为所述待展示事务；其中，所述查询条件包括以下中的至少一种：指定时间段、指定数据库、指定表信息、指定DML操作类型、指定需要过滤的数据库、指定需要过滤的表信息、指定需要过滤的DML操作类型。

其中，在一个实施例中，所述装置还包括：

数据量确定模块812，用于接收到请求获取指定事务的详细信息的指令后，确定所述指定事务的数据量；

第一解析模块813，用于若所述数据量小于预设数据量，则解析所述指定事务的详细信息并显示；

第二解析模块814，用于若所述数据量大于或等于所述预设数据量，则解析所述指定事务的详细信息后将解析结果存储到对象存储服务器上，并展示存储地址。

其中，在一个实施例中，所述装置还包括：

缩放指令接收模块815，用于接收用于缩放时间轴的缩放指令；

缩放模块816，用于根据所述缩放指令，缩放所述预设时间轴。

其中，在一个实施例中，所述装置还包括：

恢复请求接收模块817，用于接收将选择的事务确定为恢复点的恢复请求；

恢复模块818，用于根据所述恢复点进行数据库恢复。

其中，在一个实施例中，恢复模块818，具体包括：

数据库实例恢复单元819，用于若存在需要恢复的数据库的数据库实例，则将所述数据库实例恢复到所述恢复点。

其中，在一个实施例中，恢复模块818，具体包括：

全量备份选取单元820，用于若存在需要恢复的数据库的多个全量备份，根据每个全量备份的操作日志计算每个全量备份恢复到所述恢复点所需要处理的数据量，并选择计算的数据量最小的全量备份；或者，选择全量备份的备份结束时间与所述恢复点的结束时间之间的时间差值最小的全量备份；

恢复单元821，用于将选择的全量备份恢复到所述恢复点。

其中，在一个实施例中，恢复单元821，具体包括：

比较子单元，用于比较选择的全量备份的备份结束时间与所述恢复点的结束时间之间的时间先后顺序；

恢复子单元，用于若备份结束时间在恢复点的结束时间之后，则采用向后回溯的方式将选择的全量备份恢复到所述恢复点；若备份结束时间在恢复点的结束时间之前，则采用向前回放的方式将选择的全量备份恢复到所述恢复点。

其中，在一个实施例中，若采用向后回溯的方式进行数据库恢复；所述恢复模块818，具体包括：

事务集确定单元822，用于根据空闲内存空间，将需要恢复的数据库的从当前状态恢复到所述恢复点之间需要恢复的事务划分为多个事务集，其中，所述事务集的数据量小于或等于所述空闲内存空间；

事务集恢复单元823，用于按照恢复顺序和所述恢复点，根据划分好的多个事务集进行数据库恢复。

其中，在一个实施例中，所述装置还包括：

恢复条件获取模块824，用于所述恢复模块818根据所述恢复点进行数据库恢复之前，接收输入的恢复条件；所述恢复条件包括以下中的至少一种：指定需要过滤的数据库、指定需要恢复的数据库、指定需要过滤的表信息、指定需要恢复的表信息、指定需要恢复的DML操作类型；

所述恢复模块818，具体包括：

条件恢复单元825，用于根据所述恢复条件和所述恢复点进行数据库恢复。

综上所述，本申请实施例提供的数据库处理装置通过预解析数据库的操作日志中的关键信息(如事务的起止时间)，并根据时间轴展示出来，从而便于用户能够直观地、一目了然的查找到视为恢复点的事务。从而能够提高恢复点确定的效率，进而提高数据库恢复的效率。

此外，本申请实施例中，在确定恢复点时，还可以允许用户输入查询条件，从而过滤掉无关事务，仅为用户展示需要的事务，从而减少展示的事务的数量，进一步帮助用户快速的确定恢复点，提高恢复点的确定效率，提高用户的应用体验。

此外，本申请实施例中，在进行数据库恢复时，也能实现更细粒度的恢复，例如可以仅针对某些数据库进行恢复操作，甚至仅针对某些表进行恢复操作，使得数据库的恢复更加准确、快速，同时还能避免无关的数据库或表受恢复操作的影响。

另外，本申请实施例中，通过根据空闲内存空间将需要恢复的事务划分为事务集，能够避免由于内存不足导致恢复失败，使得数据库恢复能够顺利进行。

在介绍了本发明示例性实施方式的方法和装置之后，接下来，介绍根据本发明的另一示例性实施方式的数据库处理装置。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为***、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“***”。

在一些可能的实施方式中，根据本发明的数据库处理装置可以包括至少一个处理单元、以及至少一个存储单元。其中，所述存储单元存储有程序代码，当所述程序代码被所述处理单元执行时，使得所述处理单元执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的数据库处理方法中的各种步骤。例如，所述处理单元可以执行如图2中所示的步骤201，从预存的预解析结果中获取待展示事务的起止时间，其中，所述预解析结果为对数据库的操作日志文件进行预解析后获得的结果；步骤202，根据待展示事务的起止时间，确定待展示事务在预设时间轴上对应的时间点；步骤203，根据所述预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。

下面参照图9来描述根据本申请的这种实施方式的数据库处理装置90。图9显示的数据库处理装置仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图9所示，数据库处理装置90可以以通用计算设备的形式表现，例如其可以为服务器设备。数据库处理装置90的组件可以包括但不限于：上述至少一个处理单元91、上述至少一个存储单元92、连接不同***组件(包括存储单元92和处理单元91)的总线93。

总线93表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、***总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储单元92可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)921和/或高速缓存存储器922，还可以进一步包括只读存储器(ROM)923。

存储单元92还可以包括具有一组(至少一个)程序模块924的程序/实用工具925，这样的程序模块924包括但不限于：操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

数据库处理装置90也可以与一个或多个外部设备94(例如键盘、指向设备等)通信，还可与一个或者多个使得用户能与该数据库处理装置90交互的设备通信，和/或与使得该数据库处理装置90能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口95进行。并且，数据库处理装置90还可以通过网络适配器96与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器96通过总线93与数据库处理装置90的其它模块通信。应当明白，尽管图中未示出，可以结合数据库处理装置90使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。

示例性程序产品

在一些可能的实施方式中，本申请的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在服务器设备上运行时，所述程序代码用于使所述服务器设备执行本说明书上述“示例性方法”部分中描述的根据本申请各种示例性实施方式的方法中的步骤，例如，所述服务器设备可以执行如图2中所示的步骤201，从预存的预解析结果中获取待展示事务的起止时间，其中，所述预解析结果为对数据库的操作日志文件进行预解析后获得的结果；步骤202，根据待展示事务的起止时间，确定待展示事务在预设时间轴上对应的时间点；步骤203，根据所述预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

如图10所示，描述了根据本申请的实施方式的用于数据库处理的程序产品100，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在服务器设备上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本申请的精神和原理，但是应该理解，本申请并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本申请旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种数据库处理方法，包括：

从预存的预解析结果中获取待展示事务的起止时间，其中，所述预解析结果为对数据库的操作日志文件进行预解析后获得的结果；

根据待展示事务的起止时间，确定待展示事务在预设时间轴上对应的时间点；

根据所述预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。

2.根据权利要求1所述的方法，所述根据所述预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识之后，所述方法还包括：

接收到对事务标识的选择指令后，显示选择的事务的起止时间；并，

获取所述选择的事务包含的数据操作语言DML类型的操作事件及操作事件的操作时间并显示。

3.根据权利要求2所述的方法，所述方法还包括：

从所述预解析结果中获取所述选择的事务涉及的数据库和/或表信息并显示。

4.根据权利要求2所述的方法，所述获取所述选择的事务包含的DML类型的操作事件及操作事件的操作时间，具体包括：

从预解析结果中获取所述选择的事务包含的DML类型的操作事件及操作事件的操作时间；或者，

从预解析结果中获取所述选择的事务在操作日志文件中的位置信息，根据所述位置信息，从操作日志文件中解析出所述选择的事务包含的DML类型的操作事件及操作事件的操作时间。

5.根据权利要求1所述的方法，所述预解析结果中还包括操作日志文件的创建时间和关闭时间；所述从预存的预解析结果中获取待展示事务的起止时间之前，所述方法还包括：

根据所述预设时间轴，显示操作日志文件的文件标识及其对应的创建时间和结束时间；

接收到对文件标识的选择指令后，将选择的操作日志文件包含的事务确定为待展示事务。

6.根据权利要求1所述的方法，所述从预存的预解析结果中获取待展示事务的起止时间之前，所述方法还包括：

接收用户输入的查询条件，将符合所述查询条件的事务确定为所述待展示事务；其中，所述查询条件包括以下中的至少一种：指定时间段、指定数据库、指定表信息、指定DML操作类型、指定需要过滤的数据库、指定需要过滤的表信息、指定需要过滤的DML操作类型。

7.根据权利要求1所述的方法，所述方法还包括：

接收到请求获取指定事务的详细信息的指令后，确定所述指定事务的数据量；

若所述数据量小于预设数据量，则解析所述指定事务的详细信息并显示；

若所述数据量大于或等于所述预设数据量，则解析所述指定事务的详细信息后将解析结果存储到对象存储服务器上，并展示存储地址。

8.根据权利要求1所述的方法，所述方法还包括：

接收用于缩放时间轴的缩放指令；

根据所述缩放指令，缩放所述预设时间轴。

9.根据权利要求1-9中任一所述的方法，所述方法还包括：

接收将选择的事务确定为恢复点的恢复请求；

根据所述恢复点进行数据库恢复。

10.一种数据库处理装置，包括：

待展示事务获取模块，用于从预存的预解析结果中获取待展示事务的起止时间，其中，所述预解析结果为对数据库的操作日志文件进行预解析后获得的结果；

时间点确定模块，用于根据待展示事务的起止时间，确定待展示事务在预设时间轴上对应的时间点；

事务展示模块，用于根据所述预设时间轴，在确定的时间点的预设对应位置显示待展示事务的事务标识。