CN101639839B - 一种基于临时表的多归档文件查询方法 - Google Patents
一种基于临时表的多归档文件查询方法 Download PDFInfo
- Publication number
- CN101639839B CN101639839B CN2008101422240A CN200810142224A CN101639839B CN 101639839 B CN101639839 B CN 101639839B CN 2008101422240 A CN2008101422240 A CN 2008101422240A CN 200810142224 A CN200810142224 A CN 200810142224A CN 101639839 B CN101639839 B CN 101639839B
- Authority
- CN
- China
- Prior art keywords
- archive file
- temporary table
- record
- data base
- archive
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种基于临时表的多归档文件查询方法,其包括以下步骤:A、根据查询要求,过滤出待查询归档文件;B、估算出装载所述归档文件需要的临时数据库的空间大小;若临时数据库的空间足够,则执行步骤C;C、采用批量复制方式将待查询归档文件中的记录逐个恢复到所述临时数据库中的临时表中,并使用两级缓存机制来实现多次查询之间以归档文件为单位的数据共享;D、根据查询条件,从所述临时表中获取数据。本发明能通过加快文件装载到临时表中的速度,并对已装载的归档进行两级缓存来优化多归档文件查询的效率。
Description
技术领域
本发明涉及使用数据库(Database)作为数据存储介质的软件开发技术领域,具体涉及一种基于临时表的多归档文件查询方法。
背景技术
大型的数据库应用系统中,为了避免数据库空间溢出,必须对历史数据进行归档,同时支持对归档文件进行查询。比如,在电信网络管理系统中,大量的历史告警、性能等数据必须定期归档,对归档文件的查询采用了基于临时表的方式,这也是目前广泛使用的一种方式,其具体方案如下:
(1)在临时数据库中创建一个临时表;
(2)将归档文件的内容装载到临时表中
(3)从临时表中查询符合条件的记录
上述查询方案能满足单个归档文件的查询需求,但有时用户需要一次查询多个归档文件,比如在电信网络管理系统中需要统计一段时间的告警记录,如果让用户逐个查询该时间段内的归档文件再进行汇总肯定不能很好地满足用户需求,这就需要一次性查询出该段时间内的所有告警归档文件;这种情况采用上述方案就同时存在空间和效率方面的问题。首先,如果一次查询涉及的归档文件多,比如要查询过去一个月的或者一个季度的,记录量太大,可能会导致临时数据库空间溢出;其次,如果采用逐条将归档文件中的记录插入临时表在记录量大的情况下整个装载过程会非常慢。另外,查询归档文件一般采用分页查询的方式,如果每一页查询都重新装载,效率上用户肯定不能接受,这个可以通过缓存装载的归档进行一定的优化,比如通过在系统中保存一个已装载的文件链表的方式,如果要查询的归档文件已经装载过就不需要重新装载,这对查单个归档文件来说是一个较好的解决方案,但对多归档文件就仍然满足不了需求。如果所有的归档文件都恢复到一个临时表中,缓存的粒度就太大,两次查询之间只要有一个文件不相同所有的文件都必须重新装载,而且也影响恢复的效率;如果每个文件恢复到一个单独的临时表中,可以实现以文件为单位的共享,但一次要同时查询多个表实现分页查询或全网排序有难度,也不是理想的解决方案。
可见现有技术中存在一定的问题,需要进一步地改进。
发明内容
本发明的目的在于提供一种基于临时表的多归档文件查询方法,其能通过加快文件装载到临时表中的速度,并对已装载的归档进行两级缓存来优化多归档文件查询的效率。
为实现上述目的,本发明采用如下技术方案:
本发明提供了一种基于临时表的多归档文件查询方法,所述方法包括以下步骤:
A、根据查询要求,过滤出待查询归档文件;
B、估算出装载所述归档文件需要的临时数据库的空间大小;若临时数据库的空间足够,则执行步骤C;
C、采用批量复制(BCP)方式将待查询归档文件中的记录逐个恢复到所述临时数据库中的临时表中,并使用两级缓存机制来实现多次查询之间以归档文件为单位的数据共享;
D、根据查询条件,从所述临时表中获取数据。
所述的方法,其中,所述步骤B中,若所述临时数据库的空间不够,则提示用户改变所述查询要求或扩展所述临时数据库的空间,并提供给用户所需要的临时数据库空间的最小值作为扩容参考。
所述的方法,其中,所述查询要求为用户下发的查询时间段;所述步骤A包括以下步骤:
A1、遍历默认归档目录下的所有归档文件,
A2、读取每个归档文件的备注信息文件,得到每个归档文件记录的时间段;
A3、比较获得的时间段与所述查询时间段,将满足所述查询时间段要求的归档文件过滤出来,作为待查询归档文件。
所述的方法,其中,所述步骤B中,所述估算过程按照以下步骤进行:
B1、计算出待查询归档文件的记录条数总和;
B2、从所述临时数据库中查询出每兆空间可存放的记录条数;
B3、按照下述公式计算装载所述归档文件需要的临时数据库的空间大小,
其中,Q为所要计算的临时数据库的空间大小,M为所述步骤B1获得的记录条数总和,N为所述步骤B2获得的每兆空间可存放的记录条数,K为一至少大于2的比例系数。
所述的方法,其中,所述步骤C包括以下步骤:
C1、判断一公共临时表中存放的记录是否对应本次待查询的所有归档文件,如果否,则执行步骤C2;
C2、判断待查询归档文件是否已装载到临时创建的中间临时表中,如果否,则执行步骤C3;
C3、采用批量复制(BCP)方式将待查询归档文件中的记录恢复到临时创建的中间临时表中,记录该归档文件和中间临时表的对应关系,并设置归档文件的装载时间;
C4、将所有中间临时表中的归档文件导入所述公共临时表中,并记录归档文件和公共临时表的对应关系。
所述的方法,其中,所述公共临时表在系统初始化时创建,并且每种历史数据类型在临时数据库中对应一个和归档数据表同名同结构的公共临时表。
所述的方法,其中,所述中间临时表在查询过程中动态创建,并且每种厉史数据类型对应至少一个中间临时表。
所述的方法,其中,所述步骤C2还包括以下步骤:若待查询归档文件没有装载到中间临时表中,则执行步骤C21;
C21、判断临时数据库已使用空间是否达到门限值,如果是,则卸载掉装载时间最早的归档文件,删除该归档文件对应的中间临时表,清空该归档文件对应的公共临时表,并返回步骤C21;如果否,执行步骤C3。
所述的方法,其中,所述步骤C3和C4之间还包括以下步骤:C31、判断是否所有待查询归档文件都已装载完毕,如果否,则返回至步骤C2;如果是,则清空公共临时表,并执行步骤C4。
所述的方法,其中,所述步骤C3中,采用批量复制(BCP)方式将待查询归档文件中的记录恢复到中间临时表的过程,包括以下步骤:
C31、从数据库系统表中获取待查询归档文件中归档数据表的字段信息;
C32、申请一个批量复制(BCP)访问接口对象,分配批量复制(BCP)缓存,初始化相关参数,该相关参数中包括一次批量复制(BCP)操作的记录条数;
C33、读取待查询归档文件中归档数据文件的第一行,获取参与归档的字段名,并申请字段缓存,将字段信息和批量复制(BCP)访问接口绑定起来;
C34、从待查询归档文件中读取一条记录,解析各个字段,并存放在预先分配好的字段缓存中;
C35、调用执行函数将字段缓存中的各个字段值压入数据库的批量复制(BCP)缓存中,当记录条数达到设定的一次批量复制(BCP)操作的记录条数时,将批量复制(BCP)缓存中的记录提交入临时数据库;
C36、判断待查询归档文件是否读取完毕,如果没有,则返回至C34,否则,将批量复制(BCP)缓存中最后一批记录提交入临时数据库。
C37、释放申请的字段缓存和批量复制(BCP)访问接口对象。
有益效果:与现有技术相比,本发明优化了目前使用的基于临时表的归档文件查询方法,采用批量复制(BCP)方式将归档文件中的记录恢复到数据库中使得装载归档文件的速度有了数量级的提高,同时采用两级缓存机制最大程度地减少了不必要的文件装载,实现了多次查询之间以文件为单位的数据共享,使得用户在一次查询多个归档文件时能获得较快的查询速度,且不会导致临时数据库空间溢出,同样,本发明也适用于单个归档文件的查询。
附图说明
图1是本发明多归档文件查询的流程图;
图2是归档文件装载的流程图;
图3是采用批量复制(BCP)方式将归档文件中的记录恢复到临时表的流程图。
具体实施方式
采用本发明的方法进行归档文件的查询时,首先有如下几个约定:(1)归档文件有固定的格式,一个完整的归档包括一个归档备注信息文件和一个归档数据文件;其中,归档备注信息文件中记录该归档文件的数据库表名、归档时间字段、归档记录条数、归档记录的时间范围等等;归档数据文件第一行是归档数据表字段名,以逗号分隔,第二行起是实际的数据,每行一条记录,记录字段之间也是以逗号分隔。(2)归档文件之间没有重复记录,系统启动后的第一次归档是全量归档,之后的归档均是增量归档,就是只归档上次归档时间之后产生的记录,所以归档文件之间的记录是时间上连续且没有重叠的。
采用本发明的方法进行一次查询多个归档文件的操作过程,如图1所示,
110,根据用户下发的查询要求,过滤出待查询归档文件;
120,估算出装载这些归档文件所需要的临时数据库的空间大小,如果临时数据库空间不够,则执行步骤150;否则,执行步骤140;
140,采用批量复制(BCP)方式将需要装载的归档文件中的记录逐个恢复到所述临时数据库中的临时表中,装载管理器使用两级缓存机制来避免不必要的文件装载,实现多次查询之间以归档文件为单位的数据共享;
150,提示用户改变查询要求或扩展临时数据库空间,并提供给用户所需要的临时数据库空间的最小值作为扩容参考,本次查询过程结束;
160,从临时表中,根据查询条件获取所需要的数据。
在上述步骤110中,所述查询要求为用户下发查询时间段,具体过程如下,
首先,遍历默认归档目录下的所有归档文件;
然后,读取每个归档的备注信息,得到每个归档文件记录的时间段;
最后,比较获得的时间段与查询时间段,将满足所述查询时间段要求的归档文件过滤出来,作为待查询归档文件。假设,用户下发的时间段为[t1,t2],归档文件的记录时间段为[t3,t4],则需要查询的归档文件需要满足t3≤t2并且t4≥t1。
上述步骤120中,所述临时数据库空间大小的估算过程按照以下步骤进行:
首先,计算出待查询归档文件的记录条数总和;
然后,从所述临时数据库中查询出每兆空间可存放的记录条数;
其次,按照下述公式计算装载所述归档文件需要的临时数据库的空间大小,
其中,Q为所要计算的临时数据库的空间大小,M为上述步骤中获得的记录条数总和,N为获得的每兆空间可存放的记录条数,K为一至少大于2的比例系数。从上述公式可以看出,本发明主要根据两个参数来估算归档文件所需要的临时数据库空间大小,一个是数据库中记录的每种类型的历史数据每M字节可以存放的记录条数N,这是一个统计平均值;另一个是归档备注信息中记录的归档记录条数M。而对于K值得设定,可以参见以下相关说明。本发明在查询过程中预先估算所需要的临时数据库空间,从而避免了装载过程中临时数据库空间溢出,导致归档文件装载失败。
上述步骤140中,利用BCP方式和两级缓存装载机制将归档文件逐个装载到上述临时数据库空间中,以实现以归档文件为单位的数据共享的方法如图2所示。下面先解释一下两级缓存机制,本发明在归档文件的装载过程中,会在临时数据库中创建两类临时表,一是公共临时表,其是在系统初始化时,为每种历史数据类型在临时数据库中创建的一个和归档数据表同名同结构的表;二是中间临时表,这是在查询过程中动态创建的,每种数据类型可能会有多个,以归档数据历史表名后加一个数字后缀来命名,这个数字后缀是从0开始并全局递增的。那么,内存中就会有两个数据结构,一个是需要记录归档文件和中间临时表的对应关系,这是一个1对1的对应关系,装载过程中每个归档文件会被恢复到一个中间临时表中;另一个是需要记录公共临时表和归档文件的对应关系,这个可能是1对多或1对1的关系,取决于特定的一次查询涉及到几个归档文件。一次查询涉及的多个归档文件恢复到若干个中间临时表后,再逐个导入公共临时表供用户查询。从上述装载过程的描述可知,装载所需要的临时数据库空间为所有归档文件中记录存储量之和的两倍,那么上述步骤120估算临时数据库空间大小的公式中,K至少应该为2,同时在结合实际操作过程中需要预留的空间大小,那么K至少要比2大。下面参见图2详细说明,上述步骤140的装载过程。
121,根据公共临时表和归档文件的对应关系,判断公共临时表中存放的记录是否对应本次待查询的所有归档文件,
如果是,则更新所有归档文件的装载时间,本次装载过程结束;如果否,则执行步骤122;
122,根据中间临时表和归档文件的对应关系,判断待查询归档文件是否已装载到中间临时表中,这里可以依次对每一个待查询归档文件进行判断,对于没有装载的归档文件,依次进行步骤124和125的过程。
如果是,则执行步骤123;否则,创建一个中间临时表,并执行步骤124;
123,更新该归档文件的装载时间,并转至步骤127;
124,判断临时数据库已使用空间是否达到门限值,该门限值的设定是为了预留一部分用于其它的数据库操作,
如果是,则执行步骤126;如果否,则执行步骤125;
125,用BCP方式将归档文件中的记录恢复到中间临时表中,记录归档文件和中间临时表的对应关系,并设置归档文件的装载时间;
126,卸载掉装载时间最早的归档文件,并返回步骤124。卸载归档时以文件为单位,并同时要删除其对应的中间临时表,并清空对应的公共临时表。
127,判断是否所有待查询归档文件都已装载完毕,
如果否,则返回至步骤122,否则,执行步骤128;
128,将所有待查询的归档文件对应的中间临时表逐个导入公共临时表中,并记录归档文件和公共临时表的对应关系,装载过程结束。
上述过程中体现了两类表的应用过程,其中通过在多次查询之间,判断待查询的归档文件是否与临时表中装载的归档文件全部或部分相同,则只要这些归档文件还没有被卸载,就可以在多次查询过程之间以文件为单位共享,最大程度地减少不必要的装载,这样可以大大提高分页查询过程中翻页的效率,对某个时间范围进行分段查询效率也可以得到很好的改善。上述步骤121、122及128是主要的装载过程,而其中增加步骤124的判断,是为了保证临时数据库空间的大小符合装载需要,避免因数据库空间不足而导致装载失败;增加步骤127的判断,是为了确保对所有待查询归档文件进行装载,避免遗漏。
上述步骤125中,BCP方式是一种批量复制方式,用于数据库表和文本文件之间的记录导入导出,一次导入或导出的记录数越多效率越高。具体实现可以采用不同数据库提供的BCP编程接口。以sybase数据库为例,BCP方式将归档文件中的记录导入数据库步骤如图3所示。
341,从数据库系统表中获取待查询归档文件中归档数据表的字段信息,其中包括字段类型、长度等信息;
342,申请一个BCP访问接口对象,调用blk_alloc()、blk_init()执行函数分配BCP缓存,初始化相关参数,该相关参数包括一次BCP操作的记录条数;
343,读取待查询归档文件中归档数据文件的第一行,获取参与归档的字段名,并申请字段缓存,通过调用blk_bind()执行函数将这些字段的字段号、类型、长度、缓存地址等信息和BCP访问接口绑定起来;
344,从待查询归档文件中读取一条记录,解析各个字段,并存放在预先分配好的字段缓存中;
345,调用blk_rowxfer()执行函数将字段缓存中的各个字段值压入sybase数据库的BCP缓存中;
346,判断记录条数是否达到一次BCP操作的记录条数,
若是,则执行步骤347;若否,则执行步骤348;
347,当记录条数达到设定的一次BCP操作的记录条数,就调用blk_done()函数将BCP缓存中的记录提交入上述临时数据库;
348,判断归档文件中的记录是否读取完毕,
如果否,则返回至步骤344;否则,执行步骤349;
349,调用blk_done()执行函数将最后一批记录提交入上述临时数据库(这一次调用可能不够设定的一次BCP操作记录条数),释放申请的字段缓存和BCP访问接口对象。
另外,考虑到查询归档操作并不是非常频繁,为了避免大量的归档数据长期占用临时数据库影响其它数据库操作的效率,需要一个卸载定时器周期卸载掉一段时间不用的归档文件。
下面以电信网络管理系统中的常见操作-查询历史告警归档文件为为例,结合图1至图3详细说明采用本发明方法的查询过程。历史告警数据存放在历史库中的HistoryAlarm表中。系统初始化时会在临时数据库中创建临时表HistoryAlarm,结构同历史库中的HistoryAlarm表。
第1步,根据用户下发的查询时间段过滤出需要查询的归档文件。假设,用户需要查询2007年11月份的告警归档记录,该时间段内的归档文件有5个,详细信息如下表1所示。归档时间精确到秒,20071030120723表示2007年10月30日11点7分23秒。
表1
归档文件名 | 归档起始时间 | 归档结束时间 | 记录条数 |
Alm0711011444 | 20071030120723 | 20071101144409 | 170338 |
Alm0711062158 | 20071101144409 | 20071106215803 | 239807 |
Alm0711161442 | 20071106215803 | 20071116144224 | 235577 |
Alm0711191142 | 20071116144224 | 20071119114221 | 235375 |
Alm0711221103 | 20071119114221 | 20071122110307 | 239407 |
第2步,估算出装载这些归档文件所需要的临时数据库空间大小,如果临时数据库空间不够则提示用户缩短查询时间段或扩展临时数据库空间,并提供给用户一个临时数据库空间最小值作为扩容参考,其中,估算数据库空间大小的过程如下:
(2.1)计算出需要查询的归档文件总的记录条数。本例中5个归档文件总记录条数为112,3174条。
(2.2)从数据库表TableRecordSize中查询出每M空间可以存放的历史告警条数,查询结果为9000条。
(2.3)计算装载这些归档文件所需要的临时数据库空间:
1123174/9000×2=250M
上述系数为2,是因为需要再临时数据库中建立两个临时表用于加载上述归档文件,但是基于临时数据库还要预留一部分空间用于其它的数据库操作,假设预留50%,则需要将上述结果再乘以2,那么临时数据库空间是500M。另外,再考虑到估算的不准确性和后续扩展需要,给用户的建议值需要在此基础上增加20%,即结果再乘以1.2为600M。
第3步,将需要查询的归档文件用BCP方式逐个装载到临时数据库,而在装载过程中,管理器使用两类临时表构成的两级缓存机制在多个查询过程之间以归档文件为单位共享装载,如
typedef_NS_STD_map<int,DumpLoadInfo>DumpLoadInfoList;
记录中间临时表和归档文件的对应关系,关键字为历史数据类型,历史告警取值为4,DumpLoadInfo结构记录归档文件名、中间临时表名、装载时间等等;采用如下形式
typedef_NS_STD_map<_STD_string,
NS_STD_deque<_STD_string>>DumpLoadInfoList2;
记录公共临时表和归档文件的对应关系。
如图2所示,将多个归档文件装载到临时表中的具体步骤:
3.1,查询公共临时表中已装载的文件链表DumpLoadInfoList2,如果公共临时表HistoryAlarm中的装载文件链表刚好为本次待查询的归档文件,则更新本次查询的归档文件的装载时间,装载过程结束,否则转3.2;
3.2,取得某个待装载文件,查询中间临时表已装载的文件链表DumpLodInfoList,如果该文件已经被装载过,则更新DumpLoadInfoList结构中文件的装载时间为当前时刻,转3.5;
3.3,创建中间临时表HistoryAlarmN,N是从0开始,系统运行过程中全局递增的;
3.4,获取临时数据库的空闲空间,如果空闲空间小于50%,则卸载掉装载时间最老的归档。卸载中需要删除归档文件对应的中间临时表,并将公共临时表HistoryAlarm清空。卸载过程要循环进行,直到空闲空间大于或等于50%。
3.5,将待装载文件中的记录以BCP方式恢复到中间临时表HistoryAlarmN中,一次插入50,0000条记录。将装载文件名、中间临时表名、装载时间等信息填入DunpLoadInfoList结构;
3.6,如果所有文件都已经装载完毕,则转3.7,否则转3.2。
3.7,清空公共临时表HistoryAlarm,将本次查询的归档文件对应的中间临时表的内容逐个导入公共临时表HistoryAlarm中;
在DumpLoadInfoList2中记录公共临时表对应的归档文件。
上述步骤3.5中采用BCP方式将归档文件中的记录恢复到临时表的方法如图3所示,这里不再赘述。
第4步,从公共临时表HistoryAlarm中查询出符合条件的历史告警数据。
上述实施例按照本发明所述的多归档文件查询方法,应用于电信网络管理系统历史告警归档文件查询,归档记录在100万条以下时第一页的查询时间小于3分钟,后边的页查询时间小于30s,能较好地满足工程上的应用需求,相比普通的归档文件查询方式,查询效率有了很大的提高。
综上所述,本发明的应用程序编写方便,调用公共的装载函数装载后直接从固定的表中查询即可,可以很方便的实现全网排序和各种统计功能。同时,本发明没有引入各种大型数据库的差异性,能满足各种大型数据库应用系统中的归档文件查询需求。
应当理解的是,对本领域普通技术人员来说,可以根据本发明的技术方案的说明和具体实施方式做出各种可能的改变或替换,所有这些改变或替换都属于本发明的权利要求的保护范围。
Claims (6)
1.一种基于临时表的多归档文件查询方法,其特征在于,所述方法包括以下步骤:
A、根据查询要求,过滤出待查询归档文件,所述查询要求为用户下发的查询时间段;所述步骤A包括以下步骤:
A1、遍历默认归档目录下的所有归档文件;
A2、读取每个归档文件的备注信息文件,得到每个归档文件记录的时间段;
A3、比较获得的时间段与所述查询时间段,将满足所述查询时间段要求的归档文件过滤出来,作为待查询归档文件;
B、估算出装载所述归档文件需要的临时数据库的空间大小;若临时数据库的空间足够,则执行步骤C,若所述临时数据库的空间不够,则提示用户改变所述查询要求或扩展所述临时数据库的空间,并提供给用户所需要的临时数据库空间的最小值作为扩容参考;
C、采用批量复制方式将待查询归档文件中的记录逐个恢复到所述临时数据库中的临时表中,并使用两级缓存机制来实现多次查询之间以归档文件为单位的数据共享,所述两级缓存机制指在临时数据库中创建两类临时表,一是在系统初始化时,为每种历史数据类型在临时数据库中创建的一个和归档数据表同名同结构的公共临时表,二是在查询过程中动态创建的中间临时表,若步骤B中得出临时数据库的空间足够,则具体执行以下步骤:C1、判断一公共临时表中存放的记录是否对应本次待查询的所有归档文件,如果否,则执行步骤C2,如果是,则更新所有归档文件的装载时间,本次装载过程结束;
C2、判断待查询归档文件是否已装载到临时创建的中间临时表中,如果否,则执行步骤C3,如果是,则更新该归档文件的装载时间;
C3、采用批量复制方式将待查询归档文件中的记录恢复到临时创建的中间临时表中,记录该归档文件和中间临时表的对应关系,并设置归档文件的装载时间;
C4、将所有中间临时表中的归档文件导入所述公共临时表中,并记录归档文件和公共临时表的对应关系;
D、根据查询条件,从所述公共临时表中获取数据。
2.根据权利要求1所述的方法,其特征在于,所述步骤B中,所述估算过程按照以下步骤进行:
B1、计算出待查询归档文件的记录条数总和;
B2、从所述临时数据库中查询出每兆空间可存放的记录条数;
B3、按照下述公式计算装载所述归档文件需要的临时数据库的空间大小,
其中,Q为所要计算的临时数据库的空间大小,M为所述步骤B1获得的记录条数总和,N为所述步骤B2获得的每兆空间可存放的记录条数,K为一至少大于2的比例系数。
3.根据权利要求1所述的方法,其特征在于,所述中间临时表在查询过程中动态创建,并且每种历史数据类型对应至少一个中间临时表。
4.根据权利要求1所述的方法,其特征在于,所述步骤C2还包括以下步骤:
若待查询归档文件没有装载到中间临时表中,则执行步骤C21;
C21、判断临时数据库已使用空间是否达到门限值,如果是,则卸载掉装载时间最早的归档文件,删除该归档文件对应的中间临时表,清空该归档文件对应的公共临时表,并返回步骤C21;如果否,执行步骤C3。
5.根据权利要求1所述的方法,其特征在于,所述步骤C3和C4之间还包括以下步骤:
C31、判断是否所有待查询归档文件都已装载完毕,
如果否,则返回至步骤C2;如果是,则清空公共临时表,并执行步骤C4。
6.根据权利要求1所述的方法,其特征在于,所述步骤C3中,采用批量复制方式将待查询归档文件中的记录恢复到中间临时表的过程,包括以下步骤:
C31、从数据库系统表中获取待查询归档文件中归档数据表的字段信息;
C32、申请一个批量复制访问接口对象,分配批量复制缓存,初始化相关参数,该相关参数中包括一次批量复制操作的记录条数;
C33、读取待查询归档文件中归档数据文件的第一行,获取参与归档的字段名,并申请字段缓存,将字段信息和批量复制访问接口绑定起来;
C34、从待查询归档文件中读取一条记录,解析各个字段,并存放在预先分配好的字段缓存中;
C35、将字段缓存中的各个字段值压入数据库的批量复制缓存中,当记录条数达到设定的一次批量复制操作的记录条数时,将批量复制缓存中的记录提交入临时数据库;
C36、判断待查询归档文件是否读取完毕,如果没有,则返回至C34,否则,将批量复制缓存中最后一批记录提交入临时数据库;
C37、释放申请的字段缓存和批量复制访问接口对象。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2008101422240A CN101639839B (zh) | 2008-07-30 | 2008-07-30 | 一种基于临时表的多归档文件查询方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2008101422240A CN101639839B (zh) | 2008-07-30 | 2008-07-30 | 一种基于临时表的多归档文件查询方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101639839A CN101639839A (zh) | 2010-02-03 |
CN101639839B true CN101639839B (zh) | 2011-10-26 |
Family
ID=41614823
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2008101422240A Expired - Fee Related CN101639839B (zh) | 2008-07-30 | 2008-07-30 | 一种基于临时表的多归档文件查询方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101639839B (zh) |
Families Citing this family (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101924846A (zh) * | 2010-08-31 | 2010-12-22 | 北京云快线软件服务有限公司 | 一种实时计费方法 |
CN102479198B (zh) * | 2010-11-26 | 2014-04-02 | 金蝶软件(中国)有限公司 | 一种数据分页方法、装置及系统 |
CN102479244A (zh) * | 2010-11-30 | 2012-05-30 | 英业达股份有限公司 | 以容器暂存目标数据与未查找数据的查找系统及其方法 |
CN102769532B (zh) * | 2011-05-03 | 2017-03-15 | 中兴通讯股份有限公司 | 网管服务器及其将查询结果导出成Excel文件的方法 |
CN103324623B (zh) * | 2012-03-21 | 2017-04-12 | 宇龙计算机通信科技(深圳)有限公司 | 移动终端和数据批量操作方法 |
CN103514295B (zh) * | 2013-10-10 | 2016-09-28 | 中国电子科技集团公司第十五研究所 | 历史数据归档方法及历史数据归档装置 |
CN104615763B (zh) * | 2015-02-13 | 2018-02-13 | 百度在线网络技术(北京)有限公司 | 中间表更新方法及装置 |
CN105808749B (zh) * | 2016-03-14 | 2019-12-06 | 北京广利核系统工程有限公司 | 一种用于核电站的历史存储方法 |
CN106325933B (zh) * | 2016-08-24 | 2019-07-02 | 明算科技(北京)股份有限公司 | 批量数据同步方法和装置 |
CN106708941B (zh) * | 2016-11-24 | 2019-07-30 | 厦门亿力吉奥信息科技有限公司 | 电网多任务在线协同编辑方法 |
CN106650142B (zh) * | 2016-12-29 | 2021-02-05 | 天津市建筑设计院 | 基于Revit的批量复制视图的方法 |
CN108268538A (zh) * | 2016-12-30 | 2018-07-10 | 北京国双科技有限公司 | 数据库聚合处理方法及装置 |
CN106777345B (zh) * | 2017-01-16 | 2020-07-28 | 浪潮软件科技有限公司 | 一种基于海量数据迁移的数据抽取加载方法 |
CN107451204B (zh) * | 2017-07-10 | 2021-01-05 | 创新先进技术有限公司 | 一种数据查询方法、装置及设备 |
CN107870981B (zh) * | 2017-09-30 | 2021-10-22 | 平安科技(深圳)有限公司 | 电子装置、数据表归档处理的方法及存储介质 |
CN108776628B (zh) * | 2018-05-29 | 2021-10-15 | 郑州云海信息技术有限公司 | 一种避免ctdb数据恢复时崩溃的方法、装置及介质 |
CN109885567B (zh) * | 2018-12-13 | 2024-04-02 | 平安壹钱包电子商务有限公司 | 一种存储空间扩容方法和装置 |
CN111274279B (zh) * | 2020-01-20 | 2024-04-23 | 北京合信力科技有限公司 | 一种数据处理方法及装置 |
CN111488237B (zh) * | 2020-05-15 | 2023-09-22 | 征图新视(江苏)科技股份有限公司 | 一种二维码大数据快速校验方法 |
CN116204534B (zh) * | 2023-05-06 | 2023-07-07 | 深圳市华磊迅拓科技有限公司 | 数据归档方法、装置、设备及存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1783063A (zh) * | 2004-11-29 | 2006-06-07 | 中兴通讯股份有限公司 | 历史数据归档和查询装置及方法 |
CN1904881A (zh) * | 2005-07-26 | 2007-01-31 | 北京九州汇宝软件有限公司 | 数据库归档数据的检索方法 |
-
2008
- 2008-07-30 CN CN2008101422240A patent/CN101639839B/zh not_active Expired - Fee Related
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1783063A (zh) * | 2004-11-29 | 2006-06-07 | 中兴通讯股份有限公司 | 历史数据归档和查询装置及方法 |
CN1904881A (zh) * | 2005-07-26 | 2007-01-31 | 北京九州汇宝软件有限公司 | 数据库归档数据的检索方法 |
Also Published As
Publication number | Publication date |
---|---|
CN101639839A (zh) | 2010-02-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101639839B (zh) | 一种基于临时表的多归档文件查询方法 | |
US11531484B1 (en) | Distributed dataset modification, retention, and replication | |
EP4155966A1 (en) | Blockchain data indexing method, and blockchain data storage method | |
CN108509462B (zh) | 一种同步活动事务表的方法及装置 | |
CN101639848B (zh) | 一种空间数据引擎及应用其管理空间数据的方法 | |
CN106021016A (zh) | 在快照之间的虚拟时间点访问 | |
US20160267105A1 (en) | Virtual Partitions in Virtual Databases | |
CN102831120A (zh) | 一种数据处理方法及系统 | |
KR20110079655A (ko) | 분산형 저장 시스템 내의 데이터의 원자 다중 변경 | |
CN101488153A (zh) | 嵌入式Linux下大容量闪存文件系统的实现方法 | |
CN1936859A (zh) | 一种内存监控方法 | |
KR920018599A (ko) | 온라인 데이터베이스시스템의 동적화일확장방법 및 시스템 | |
CN107256182A (zh) | 一种数据库还原的方法及设备 | |
US10108690B1 (en) | Rolling subpartition management | |
CN107832423A (zh) | 一种用于分布式文件系统的文件读写方法 | |
CN103577513A (zh) | 藉延迟节点实例化以缓存xml信息集的系统和/或方法 | |
CN109885642B (zh) | 面向全文检索的分级存储方法及装置 | |
US20100058023A1 (en) | Efficiently managing modular data storage systems | |
CN109767274B (zh) | 一种对海量发票数据进行关联存储的方法及系统 | |
CN110096509A (zh) | 大数据环境下实现历史数据拉链表存储建模处理的系统及方法 | |
CN105589881A (zh) | 一种数据处理方法和装置 | |
CN110209736A (zh) | 区块链数据处理的装置、方法及存储介质 | |
CN110688065A (zh) | 一种存储空间管理方法、系统、电子设备及存储介质 | |
CN103365740A (zh) | 一种数据冷备方法及装置 | |
US9652766B1 (en) | Managing data stored in memory locations having size limitations |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20111026 Termination date: 20190730 |
|
CF01 | Termination of patent right due to non-payment of annual fee |