利用多个存储设备减少数据库录入的写延迟的方法和系统的制作方法【专利摘要】本发明提供了用于在多个存储设备上启动数据存储并且在数据已经存储到一个但不必是全部设备上之后确认数据存储的方法、计算机可读介质与计算机系统。存储服务器从客户端接收存储数据的请求。响应该请求，存储服务器并行地启动数据在多个存储系统上的存储。存储服务器检测到数据已经存储在存储系统中的任何一个上，例如辅助系统上，并且，作为响应，向客户端指示数据已经存储。当检测到数据已经成功地存储在目标存储系统上时，存储服务器可以清洗或丢弃辅助存储系统上的数据，其中数据在该目标存储系统上持久化。【专利说明】利用多个存储设备减少数据库录入的写延迟的方法和系统【
技术领域：
】[0001]本公开内容涉及向存储设备写数据。在各种示例中，本公开内容更具体地涉及向存储设备写日志数据。【
背景技术：
】[0002]日志[0003]如果计算机崩溃，所有计算机系统都有可能丢失数据。有些系统，像数据库系统，特别容易由于系统失败或崩溃而可能丢失数据，因为那些系统在盘与存储器之间来回传输大量的数据。数据丢失的常见原因是从易失性存储系统(例如，存储器)到持久性存储系统(例如，盘)未完成的数据传输。未完成的传输常常是由于在当崩溃发生的时候事务正在进行而发生的。事务通常包括两个存储系统之间一系列记录(或变化)的传输。[0004]当存在事务的所有影响在持久性储存器中都稳定的某种保证时，事务“成功提交”(commit)。如果在事务成功提交之前发生崩溃，则恢复所需的步骤与在事务成功提交之后发生崩溃时恢复所需的那些步骤不同。恢复是把一个或多个数据库过程还原到一个特定点的过程。[0005]当然，恢复的类型依赖于数据丢失的原因。如果计算机系统崩溃，则恢复使得计算机系统的持久性储存器，例如盘，还原到与上一次成功提交的事务所产生状态一致的状态。如果持久性储存器崩溃(称为介质故障)，恢复就重新创建存储到盘上的数据。[0006]用于恢复数据库系统的许多方法都涉及日志的使用。日志仅仅是动作的列表，常常是按时间排序的，至少在数据库系统的情况下，日志指出对数据库所进行的更改及那些更改所进行的次序。因此，日志允许计算机系统把数据库或数据库过程放到已知且特定的状态，然后这种状态可以用于重做(redo)或撤销更改。[0007]日志还可以在系统配置中使用，其中多个被称为“节点”的计算机系统访问共享盘的集合。这种类型的配置被称为“集群”或“共享盘”系统。允许这种系统中的任何节点访问任何数据的系统被称为“数据共享”系统。[0008]例如，数据处理系统可以包括多个节点和划分成区的存储介质。节点通过事务对这些区进行更改。每个事务包括由至少一个节点对至少一个区进行的一系列更改。如果被一个事务实现的更改的记录及那个事务完成的指示可靠地存储在存储介质上，则该事务成功提交。否则，事务未成功提交。重做日志描述了事务的本质并且提供用于重做该事务的足够信息。即，事务可以重复。撤销日志描述了事务的本质并且提供用于撤销该事务的足够信息。即，除去事务的结果。在基于日志的数据系统中，通过获得先前保存的数据记录的旧拷贝并且随后对旧的数据记录应用录入的动作以便把该记录重新创建到记录的新的当前状态，可以重新创建数据记录。[0009]利用基于日志的处理，工作是基于存储在日志中一组记录中对该工作的描述执行的。基于日志的处理的一个例子是系统恢复处理。在基于日志的恢复中，日志记录代表作为对一组对象的有序操作的工作项序列。具体而言，日志记录可以是代表系统故障之前对数据库中数据项所进行的更改的重做记录。总的来说，基于日志恢复系统使得对对象重复录入的工作项的处理成为必需。[0010]其中可以执行基于日志的处理的一种背景是在系统故障或意外终止之后数据库系统的恢复。在数据库恢复的背景下，日志是记录在事务期间对一组对象所进行的更改的重做日志。在故障的时候，重做日志中所记录的有些更改已经成功提交但是还没有刷新到盘。这组对象是数据库对象，例如表、行、视图、索引等。因此，基于重做日志恢复数据库系统使得对数据库对象重新应用工作项中所反映的更改成为必需。用于基于日志的处理的另一个背景是在介质损失或持久性(盘)数据损坏之后的恢复。这种类型的恢复一般涉及还原数据的备份并且随后应用日志，重放从取得该备份的时刻开始的所有更改。[0011]基于日志的处理不是总在系统恢复的背景下。而是，代替为了数据库还原而执行基于日志的处理或者附加地，还可以为了审计、为了异步事件交付、为了异步更改数据捕捉或者为了排除错误而执行基于日志的处理来在另一个系统上重复录入的工作(例如，以构建并维护备用的数据库系统)。[0012]基于日志的处理的典型方法分成两大主要类。第一类涉及串行方案。对于串行方案，单个恢复过程通读日志中的工作项序列并且对对象执行工作，一次一个工作项。在具有丰富资源的大规模系统中，这种方案没有充分利用可用的资源并且导致系统资源的利用率不足。例如，当系统中有多个CPU时，恢复过程可能在一个CPU中运行，而不利用其它的CPU。此外，串行方案不能够有效地重叠恢复处理的CPU和I/O部件。第二类基于日志的处理涉及并行方案。[0013]对于并行方案，多个过程并行地一起工作，来执行基于日志的恢复。在并行方案中，多个工作者过程以协调的方式一起工作，来执行日志中所记录的工作量。有些工作者过程可以被分配执行用于特定数据库对象的特定任务，而有些工作者过程可能能够执行用于许多数据库对象的各种不同任务。[0014]在预写日志录入(WAL)例子中，创建日志记录，来跟踪对被管理的数据进行的更改。日志记录包括被管理的数据的旧拷贝及新拷贝。它们还记录客户端动作的开始与结束。WAL保证，在持久化真正被管理的数据之前，日志记录被持久化到非易失性存储介质，例如盘。因而，在任何故障的情况下，服务器都使用已经持久化的日志记录来确定给定的客户端动作是部分完成还是全部完成。部分完成的客户端动作的结果是通过使用保存在日志记录中的被管理数据的旧拷贝把被管理数据的状态回滚到开始该客户端动作之前的状态来撤销的。类似地，日志记录中所保存的被管理数据的新拷贝用于把被管理数据的状态向前滚，反映由全部完成的客户端动作所进行的更改。以这种方式，服务器保证客户端动作对被管理的数据的原子性，甚至在存在故障的情况下也一样。回滚和向前滚一起帮助实现系统中的原子性。[0015]在在线事务处理(“0LTP”)环境中，非常频繁地写数据库日志。在OLTP环境的背景下，数据库系统的许多工作量涉及输入和输出(“I/o”)。具体而言，数据库系统的工作量主要是从存储在存储设备上的表检索信息、高速缓存频繁使用的信息并且经网络把那种信息提供给数据库应用工作站。总的来说，对数据库系统的实际计算需求是最小化的，例如计算银行账户的余额。在许多商业可用的操作系统中，处理盘I/o的服务被称为异步I/O、直接I/O、原始设备访问及条带化。[0016]在许多情况下，在知道某些信息已经写到数据库日志之前，不允许客户端与应用继续进行。因此，用于数据库日志的磁盘写入时间影响应用的响应时间和数据库系统的性能。但是，数据库日志写入延迟(latency)通常受盘系统负载的影响；如果其它的盘很忙，那么数据库日志写入常常会慢，因而负面影响性能。当数据库日志文件被多路复用或镜像时，数据库日志写入可能会更慢，情况常常就是这样。最慢的盘的速度可能是数据库日志写入的限制因素，因为，在处理可以继续之前，数据要写到所有的拷贝。[0017]可以通过优化1/0，给这些写入赋予高于所有其它类型写入的优先权，来实现改进的数据库日志写入时间。这可以在数据库级而不是在盘级进行。但是，当在盘系统已经忙于各种其它写入的时候日志写入到达时，在数据库级优先化I/O的效率并不高。[0018]在另一种实施例中，数据库日志被放到快速设备中，例如闪存储存器。但是，数据库日志往往相当大，尤其是在OLTP系统上。宝贵的闪存储存器可能不可用于给数据库日志分配。此外，由于例如磨损均衡算法，甚至闪存储存器有时候也会慢。[0019]这部分中所描述的方法是可以推行的方法，但不一定是已经被构想或推行的方法。因此，除非另外指出，否则不应当仅仅因为它们包括在这部分中就假设这部分中所描述的任何一种方法是现有技术。【专利附图】【附图说明】[0020]图1说明了用于实现本文所述各种示例技术的例子计算机系统。[0021]图2说明了用于一旦数据存储在目标存储设备或辅助存储设备上就确认数据存储的示例客户端-服务器系统。[0022]图3说明了用于在目标存储设备与辅助存储设备上都启动数据存储并且一旦数据已经存储在辅助存储设备上就确认数据存储的示例过程。[0023]图4说明了用于一旦数据存储在辅助存储设备上就确认数据存储并且在未能把数据存储到目标存储设备上时从辅助储存器恢复数据的示例过程。[0024]图5说明了用于在目标存储设备与辅助存储设备上都启动数据存储并且一旦数据已经存储在目标存储设备上就从辅助存储设备清洗数据的示例过程。具体实施例[0025]在以下描述中，为了解释的目的，阐述各种具体细节，以便提供对本发明的透彻理解。但是，很显然，本发明没有这些具体细节也可以实践。在其它情况下，众所周知的结构与设备以框图形式示出，以避免不必要地模糊本发明。[0026]一般概述[0027]提供写入操作的早期确认[0028]提供了用于在两个或更多个存储设备上启动数据存储并且在数据已经存储在一个设备上但不必是已经在两个设备上都存储之后确认数据存储的方法、计算机可读介质与计算机系统。在一种实施例中，存储服务器从客户端接收存储数据的请求。例如，存储服务器可以在客户端软件与服务器软件之间的专用存储接口上接收要存储在存储系统中的数据。响应该请求，存储服务器并行地启动在多个存储系统上的数据存储。例如，在数据存储在目标存储系统与辅助存储系统中任何一个存储系统上之前，存储服务器可以在目标存储系统与辅助存储系统上都启动数据的存储。存储服务器检测到数据已经存储在存储系统中的任何一个上而且，作为响应，向客户端指示数据已经存储。以对客户端透明的方式，启动数据的两个或更多个拷贝在两个或更多个设备上的存储可以由存储服务器响应存储数据的单个拷贝的请求而执行。[0029]在向客户端指示数据已经存储之前，存储服务器不需要等待数据存储到全部存储系统上。例如，即使数据临时存储在辅助存储系统上而且还没有持久化到目标存储系统上，存储服务器也可以向客户端指示数据已经存储。在所存储的数据从辅助存储系统清洗之前，所存储的数据可以临时在两个存储系统上都存在。但是，一旦数据已经存储在目标存储系统中，数据就可以或者可以不保留在辅助存储系统中。一旦检测到数据已经成功地存储在目标存储系统上，存储服务器就可以清洗或丢弃辅助存储系统上的数据。[0030]在一种实施例中，如果辅助存储系统在目标存储系统之前确认了数据的存储，那么，即使目标存储系统还没有存储该数据，存储服务器也可以向客户端确认数据的存储。以这种方式，存储服务器可以向客户端提供数据存储的早期确认。如果存储服务器已经在等待来自目标存储系统的确认，那么可以在存储服务器将以别的方式能够提供确认之前提供早期确认。一旦从一个存储系统提供了最快响应，早期确认就可以提供，而且存储服务器不需要等待在任何特定系统上的存储。当数据存储在目标存储系统上时，一个或多个辅助存储系统可以用于有可能提供早期响应。[0031]提供数据已经存储的早期确认与冗余地存储数据不同。在不提供早期确认的冗余系统中，数据镜像到多个存储设备，而且存储服务器等待数据写到全部这多个存储设备。在数据已经写到所有这多个存储设备之后，存储服务器可以确认数据已经冗余地写入了。不提供早期确认的冗余系统迫使存储服务器等待写入最慢的存储设备。[0032]客户端可以或者可以不选择在也提供早期确认的系统中冗余地存储数据。在一种实施例中，存储服务器可以关于多个被管理的存储设备强制执行冗余性。例如，响应在至少两个设备上冗余地存储数据的请求，存储服务器可以启动数据在三个、四个或更多存储设备上的存储。响应确定数据的两个拷贝已经冗余地存储在至少两个存储设备上，即使这至少两个存储设备不是数据的拷贝要冗余持久化的两个目标存储设备，而且即使写入在这三个、四个或更多存储设备中的其它存储设备上还没有完成，存储服务器也可以确认数据已经冗余地存储。[0033]在另一种实施例中，多个存储服务器可以一起操作，实现关于多个被管理的存储设备的冗余性。两个或更多个存储服务器中的每一个可以在两个或更多个被管理的存储设备上启动数据的存储，而且，当每个存储服务器检测到被管理的存储设备中有任何一个已经存储了数据时，该存储服务器就可以确认数据已经存储。在多个存储服务器之上运行的父存储服务器可以向客户端确认每个存储服务器都已经确认了数据的至少一个拷贝在至少一个被管理的存储设备上的存储。如果不同的存储服务器管理不同的存储设备，那么这种确认将意味着数据已经冗余存储。[0034]在一种实施例中，不管是否实现冗余性，存储服务器都接收存储数据的请求并且响应确定数据已经存储在少于多个单独存储系统中的全部上而确认数据的存储。例如，存储服务器可以确定数据已经存储在独立存储系统的第一存储系统上。存储服务器可能检测到在单独存储系统的第二存储系统中存储数据的失败。响应检测到第二存储系统存储数据的失败，存储服务器可以把数据从第一存储系统拷贝到与第一存储系统不同的存储系统。例如，存储服务器可以把数据从第一存储系统拷贝到第二存储系统或者拷贝到与第一和第二存储系统不同和/或独立的第三存储系统。在一种实施例中，如果存储服务器确定目标存储系统未能存储数据，那么存储服务器就启动数据在第三存储系统上的存储，其中第三存储系统是作为第二存储系统的备用。一旦存储服务器检测到数据已经拷贝到与第一存储系统不同的存储系统，数据就可以从第一存储系统丢弃或清洗。[0035]在一种实施例中，存储服务器接收存储数据的请求并且响应于确定数据已经存储在少于多个独立存储系统中的全部上而确认数据的存储。尽管存储的确认可以在存储已经在单个存储系统或存储系统的一个子集上完成之后提供，但是可以允许数据的存储在多个独立存储系统上的任何一个或全部上完成。换句话说，数据的存储可以在存储服务器确认数据已经存储之前在存储系统的一个子集上完成，并且在存储服务器确认数据已经存储之后在存储系统的另一个子集上完成。一旦数据已经存储在存储系统上，数据就可以从辅助存储系统清洗或丢弃并且保留在目标存储系统上。[0036]在数据存储到目标存储系统上之前，辅助存储系统可以临时存储数据。换句话说，辅助存储系统存储等待存储到目标存储系统上的一组数据，而且目标存储系统持久性地存储数据。如果在数据的存储在目标存储系统上完成之前数据的存储在辅助存储系统上完成，那么，即使数据还没有存储到所请求的位置，存储服务器也可以确认数据的存储。一旦数据存储到目标存储系统，数据就可以从辅助存储系统丢弃或清洗。在一个示例中，在确认数据已经存储到目标存储系统上之前，辅助存储系统上存储数据的位置被标记为锁定的、使用的或者不可写的。然后，在确认数据已经存储到目标存储系统上之后，所述存储数据的位置被解锁、释放或者标记为可写的。[0037]图2说明了包括客户端202、存储服务器204和存储设备206-208的示例系统。客户端202可以向存储服务器204发送数据。响应接收到要存储的数据，存储服务器204发布两个写操作:一个针对目标存储设备206，一个针对辅助存储设备208。当目标存储设备206和辅助存储设备208中任一个已经成功地写入数据时，储存器204可以向客户端202确认数据已经写入。[0038]图3-4说明了用于向客户端提供数据已经写入的早期确认的示例过程。如所示出的，在步骤302，该过程包括从客户端接收存储数据的请求。在步骤304，该过程启动数据的存储，包括:用于启动数据在目标存储设备上的存储的子过程304A和用于启动数据在辅助存储设备上的存储的子过程304B。在步骤306，该过程包括确定数据存储在辅助存储设备上并且，在响应步骤308，向客户端指示数据已经存储在目标存储设备上。[0039]在一种实施例中，辅助存储系统包括多个备用子系统，当数据在辅助存储系统中临时存储时，这些子系统被循环通过。对于给定的数据项，存储服务器可以在(I)辅助存储系统中的选定子系统和(2)目标存储系统上都启动该项的存储。存储服务器可以使用辅助存储系统的多个备用子系统中的不同子系统用于不同的数据集。如果存储服务器确定一个备用子系统未能存储数据，存储服务器就可以停用该故障子系统作为循环中的多个备用子系统中的一个。存储服务器还可以向存储系统管理员发送通知。[0040]目标存储系统和辅助存储系统可以是相同类型或者不同类型的存储系统。在一个示例中，目标存储系统是硬盘，而辅助存储系统是闪存存储系统。作为另一个示例，目标存储系统是5400rpm的硬盘,而辅助存储系统是7200rpm的硬盘。作为还有另一个示例，目标存储系统是ITB的盘,而辅助存储系统是64MB的盘。替代地,存储系统可以具有相同的尺寸和/或速度。这个示例的各种形式在本文以不同层次的细节提供。在不背离本文所述各种技术的情况下，现在已知的或者以后开发的其它存储系统可以用作目标存储系统和/或辅助存储系统。[0041]存储服务器可以确认任何数据项的存储。在一个示例中，数据是数据库日志项。存储服务器可以从客户端接收存储多个数据库日志项的请求。对于每个数据库日志项，即使存储服务器不冗余地存储数据库日志项，存储服务器也并行地在两个或更多个存储系统上启动数据库日志项的存储。即使存储系统中的一个或多个还没有确认数据库日志项的存储，存储服务器也可以确认数据库日志项的存储。[0042]本文所述的技术可以实现为由一个或多个计算设备，例如一个或多个专门编程的计算设备，执行的一个或多个过程。所述技术还可以在硬件、软件或者其集成的组合中实现为具有用于执行一个或多个过程的逻辑的一个或多个计算设备。如本文所使用的，术语“软件”指存储在一个或多个非临时性计算机可读介质上并且在一个或多个软件过程的执行过程中可以从计算机可读介质读取的计算机可读指令。所述技术还可以实现为一个或多个存储指令的非临时性计算机可读介质，当所述指令被一个或多个计算设备执行时，使得执行一个或多个过程。[0043]使用闪存储存器作为用于数据库日志写入操作的伪镜像[0044]在一种实施例中，通过利用第一种类型的存储系统作为用于第二种类型存储系统的“伪镜像”，本文所述的技术解决了提供低延迟数据库日志写入的挑战。例如，平均来看，快速存储系统，例如一个或多个闪存存储设备，可以用作一个或多个磁盘或光盘的伪镜像。当用于写到数据库日志的请求到达时，数据异步地写到要维持该日志的第一存储系统及第二存储系统。例如，数据可以异步写到盘储存器与闪存储存器。无论何时当这些写入中任意一个首先完成时，数据库日志写入请求就被确认为已经完成。尽管盘写入常常很快(由于盘控制器中电池支持的高速缓存)，但是盘写入有时候会由于I/O负载而变慢。当盘写入执行得慢的时候(例如，由于高速缓存失中)，在数据库日志利用备用或伪镜像写入而被写到更快的储存器之后，数据库系统可以就像数据库日志已经写入了一样继续前进，在这种情况下，更快的储存器是例如闪存。即使在数据库日志写到盘上之前都允许数据库系统像数据库日志已经被写入一样继续前进可以比系统必须等待数据库日志写到盘上提供更低延迟的数据库日志写入。[0045]不像写到高速缓存，日志数据是写到两个存储系统。即使写到闪存首先完成并被确认，对应的写到磁盘或更慢的储存器也完成；闪存上的日志数据可以响应确定对应的写入在盘上完成而丢弃。类似地，即使写到盘上首先完成并被确认，对应的写到闪存也可以完成。[0046]存储在存储系统中的一个，例如闪存存储系统，上的日志数据可以响应接收到对应写到另一个存储系统，例如盘存储系统，完成的已经通知而被丢弃。在一种实施例中，保持闪存储存器没有已经写到盘的日志使数据库系统能够使用比如果闪存储存器要存储整个数据库日志的话更少的闪存存储。在一种实施例中，闪存储存器用作存储可能还没有写到盘上的新日志写入并且排出或丢弃已经写到盘上的旧日志写入的循环缓冲区。[0047]尽管关于盘储存器与闪存储存器描述了各个示例，但是本文所述的技术可以利用任何两种储存器系统或存储技术来应用。例如，所述技术可以利用两种不同的存储系统来实现，这两种不同的存储系统使用不同的物理存储部件或者使用不同的存储过程来存储数据。平均来说，存储系统中的一个可以比另一个存储系统在写入方面更快、更昂贵或者更新。更快、更昂贵或更新的系统可以用作更慢、更便宜或更旧系统的伪镜像。[0048]在一种实施例中，盘写入错误在成功确认的闪存写入之后被处理。当盘写入错误在成功确认的闪存写入之后发生时，闪存储存器上的日志数据被保存并且不丢弃。在一种实施例中，日志写入数据持续地保存在闪存储存器中，直到当盘被修复或者还原时它可以成功地写到盘上。如果目标盘永久性丧失，那么，在一种实施例中，数据库通过维护镜像的日志拷贝来处理数据丢失。如果日志没有被镜像，那么在盘故障之后数据可能丢失。如果日志被镜像了，那么，除非盘故障对原始拷贝和镜像的一个或多个拷贝都发生，否则日志数据就不会丢失。[0049]在一种实施例中，即使在接收到日志写入请求的时候盘系统上的I/O负载很重，也可以通过写到伪镜像并且确认该写入来接收并处理日志写入请求。即使在写入确认之后，日志写入请求也可以在盘系统上完成。本文所述的技术可以减少对远远超出对盘的平均写延迟的盘日志写入“离群”的日志写入处理时间。本文所述的技术还可以导致更少的离群。在一种实施例中，当日志写入被伪镜像到闪存储存器时，离群更不可能。如果(a)盘系统比完成写入的平均值慢及(b)闪存系统比完成同一个写入的平均值慢，那么，即使当日志写入被伪镜像到闪存储存器时，离群仍然可能出现。[0050]在一种实施例中，本文所述的技术分配比如果闪存储存器存储整个数据库日志的话将使用的储存器量更少的闪存储存器用于数据库日志，并且使用较少的闪存储存器来存储数据库日志。闪存储存器可以用来提供低延迟写入，而盘储存器可以用作数据库日志数据的永久储存器。在一种实施例中，闪存储存器存储日志数据的一个窗口，但不存储在该窗口之前日志记录的日志数据。只存储日志数据的一个子集，但是为大部分或全部日志数据提供闪存存储写入时间，这允许闪存储存器更有效地被使用。[0051]等待日志文件数据被写入会是关于数据库系统的一个最大瓶颈，例如实时应用集群(“RAC”)系统，其中数据经常写到日志，以便让其它数据从一个节点运送到另一个节点。当这种类型的日志写入慢时，会影响整个RAC集群的性能。通过提供一致且快速的日志写入，在一种实施例中，数据库系统利用伪镜像技术除去了作为瓶颈的日志写入。在一种实施例中，数据库系统显著地提高了数据库的性能。在一种实施例中，数据库系统消除了由于慢日志写入造成的“打嗝”。在一种实施例中，数据库系统允许用户以较小的平均恢复时间(“MTTR”)值运行，减少了可能的恢复时间。[0052]在一种实施例中，即使数据库不是基于日志的，某些类的写入也可以是高优先级而且依赖快速响应时间。本文所描述的伪镜像技术可以用于把那些确定类的写入伪镜像到两个存储系统，一个主系统和一个伪镜像系统。响应确定任何一个存储系统已经完成了写入，该写入可以被确认为完成。而且，响应接收到主系统已经完成了写入的确认，该写入可以从伪镜像系统清理掉。[0053]在一种实施例中，使用伪镜像技术的数据库系统减少了用于日志文件同步事件的等待时间，使得，关于总的等待时间量，日志文件同步事件不再是顶级等待事件。在一种实施例中，伪镜像技术导致少得多的日志写入离群。在一种实施例中，甚至当MRRT有实质性减小时，Oracle?数据库也可以维持稳定的吞吐量，而没有降级或者没有显著的降级。[0054]在一种实施例中，伪镜像技术增加了使用闪存储存器来提供低延迟日志写入的特征。在一种实施例中，伪镜像技术提高了现有功能性的性能。在一种实施例中，提供了用于日志写入功能性的内部接口。在一种实施例中，伪镜像技术的使用导致相比于存储系统用于存储日志数据的预期日志写入时间而言从统计上来看显著改善的日志写入时间。在一种实施例中，伪镜像技术的使用导致相比于存储系统用于存储日志数据的预期离群个数而言从统计上来看具有明显减少的离群的日志写入时间。[0055]在各种实施例中，一旦持久化了，那么，如果数据库崩溃的话，数据日志就可以被读出，以便恢复数据。当日志被归档到有可能更便宜而且更慢的存储系统时，数据库日志可以被读出。数据库日志还可以被查询日志的应用或者被复制日志的应用读取。[0056]存储设备[0057]存储设备是例如电子电路系统的硬件、例如所存储指令的软件或者其组合的形式的存储数据的逻辑。存储设备可以包括一个或多个物理或非临时性的机器可读存储介质，数据在其上面持久化。替代地，机器可读介质可以位于其它设备上，例如云存储系统中的设备，该设备由存储设备以对存储设备的客户端来说透明的方式进行管理。存储设备还可以包括例如电子电路系统的硬件、例如所存储指令的软件或者其子和的形式的用于检索所存储的数据的逻辑。例如，数据可以从数据在其上面持久化的机器可读介质检索。替代地，存储设备可以在机器可读介质上存储数据，而另一个设备可以从该机器可读介质检索数据。存储设备可以存储数据，而且在所存储数据不再相关的时候可以替换所存储的数据，不管所存储的数据是否已经被访问或检索。[0058]在一种实施例中，存储设备是包括一个或多个CPU和易失性存储器的计算机系统。依据软件的执行，CPU管理存储设备的操作。[0059]在一种实施例中，存储设备以称为数据块的单位存储数据并提供对数据的访问。数据块是存储设备客户端可以请求从存储设备读取和写到存储设备的原子数据单元。数据块与唯一识别该数据块并且可以唯一识别存储设备中该数据块存储位置的数据块地址关联。存储设备客户端可以通过数据块地址或通过数据块地址范围请求数据块。[0060]当存储设备客户端请求存储设备写数据块时，响应该请求，客户端接收成功提交确认，该成功提交确认确认数据已经成功提交，即，数据已经以可恢复的方式存储在例如非易失性机器可读介质上。当数据块被客户端请求时，所返回的数据块具有最近为其发送了成功提交确认的版本。[0061]在回写模式中，存储设备把客户端请求的数据块写到中间存储设备或存储位置，例如持久性高速缓存设备，并且在数据块写到映射到数据块地址的目标位置之前确认数据的成功提交。存储设备还可以存储指示，该指示为:中间储存器具有数据的最近拷贝，其中该拷贝不同于存储在目标位置的数据，和/或，块地址映射到的目标位置可能没有数据的最近拷贝。例如，该指示可以作为标志存储在元数据中，该元数据把高速缓存拷贝映射到目标存储设备中的数据块并且还跟踪高速缓存拷贝是否已经从目标存储设备中所存储的版本被更新。稍后，高速缓存的拷贝可以写到目标存储设备上的目标位置，而且所存储的指示可以被更新，发信号通知目标位置已经具有数据的最近拷贝。[0062]当出现存储设备的意外断电或故障时，中间储存器中的高速缓存拷贝可能是或者可能不是数据的最近版本。元数据在故障时仍能持久化，而且，当被访问时，提供关于高速缓存拷贝是否是最近的信息。如果高速缓存拷贝是数据的最近版本，数据就从该中间存储位置而不是从目标存储位置恢复。否则，高速缓存拷贝就可以从目标存储位置恢复。[0063]存储服务器[0064]存储服务器是例如电子电路系统的硬件、例如所存储指令的软件或者其子和的形式的管理在一个或多个存储设备上存储信息的客户端请求的逻辑。例如，存储服务器可以接收要存储在一个或多个被管理的设备上的数据。响应接收到数据，存储服务器可以启动数据在多个被管理的设备上的存储。被管理的每个设备都与存储服务器通信，以便指示存储数据的成功或失败。响应接收到被管理的设备中任何一个已经成功存储了数据的确认，存储服务器向客户端确认数据已经成功存储。如果确认是响应检测到辅助设备已经存储了数据而发送的，那么向客户端的确认被称为“早期确认”。如果确认是响应检测到目标设备已经存储了数据而发送的，那么向客户端的确认被称为“正常确认”。[0065]在早期确认之后，存储服务器验证数据最终存储在目标设备上。如果数据写到目标设备遇到错误，存储设备可以重试写入或者可以把数据写到备用设备，该备用设备就变成目标设备。一旦数据已经存储在目标设备上，数据就可以从辅助设备清除。从辅助设备清除数据释放了辅助设备上的空间，以方便其它的早期确认。[0066]存储服务器可以是管理在一个或多个存储设备上存储信息的客户端请求的任何逻辑。在一种实施例中，存储服务器是Exadata服务器。Exadata服务器是为了与数据库服务器一起使用而进行了优化的存储系统。Exadata是用于存储和访问Exadata感知数据库的软件与硬件的组合。Exadata服务器提供数据库感知的存储服务，例如从数据库服务器到储存器卸载数据库处理的能力，并且在对SQL处理与数据库应用透明的同时提供这种能力。[0067]传统的存储设备不知道数据库文件驻留在被管理的储存器中而且因此不能提供任何数据库感知的I/O或SQL处理。当数据库请求行与列时，从存储系统返回的是就像持久性存储那样的数据块的图像而不是数据库查询的结果集。传统的储存器不具有区分真正请求的特定行与列的数据库智力。当代表数据库处理I/O时，传统的储存器消耗带宽，返回与所发布的数据库查询不相关的太多数据。通过只返回满足SQL请求所需的数据，更少的数据在数据库服务器与存储服务器之间发送。这意味着从Exadata服务器发送到数据库服务器的数据可以由持久地存储在不同数据块中或者甚至不同压缩单元中的行组成，而不需要表示任何数据块的盘图像。[0068]除了向数据库提供传统的块供应服务之外，Exadata还启用从数据库实例向底层储存器运送的功能。Exadata储存器能够只返回满足数据库查询标准的行与列。例如，Exadata服务器可以能够评估比较列值与一个常量的简单谓词，或者执行具有多于一个常量或需要多于一个存储器比较来进行评估的更复杂的谓词，例如，LIKE谓词与IN列表。Exadata可以包含数据库管理服务器的全部能力的一个子集。这个子集可以包括不要求以下任何一个的几乎全部功能与谓词:高度复杂的元数据支持(例如XML)，或者高级处理(例如LOBS和CL0BS)，或者使用要求对操作系统内核进行访问的系统功能(例如检索关于用户环境的信息)。[0069]消除数据传输与数据库服务器工作量会使数据仓库查询大大受益，这种查询传统上变成带宽与CPU受限的。消除数据传输还会对常常包括大批量和报告处理操作的在线事务处理(OLTP)系统具有显著的好处。[0070]Exadata软件在数据库服务器与Exadata单元之间进行最优划分。数据库服务器与Exadata存储服务器软件利用透明地把数据库操作映射到Exadata增强的操作的协议进行通信。除了由数据库提供的传统数据块运送之外，还支持功能运送体系结构。SQL操作可以向下发送到Exadata单元来执行，而且查询结果集返回到数据库系统。代替返回数据库块，Exadata单元可以只返回满足SQL查询的行与列。当卸载处理不可能时，Exadata服务器就像用于数据库服务器的传统存储设备一样操作。但是，在可行的时候，数据库系统中的智力使得例如表扫描向下传递，在Exadata存储服务器上执行，因此只有被请求的数据返回到数据库服务器。[0071]利用Exadata储存器，数据库操作可以被更有效地处理。执行表扫描的查询可以在Exadata内部处理，只有所需的数据子集返回到数据库服务器。(在其它功能之中，)行过滤、列过滤和一些连接处理可以在Exadata存储单元中执行。[0072]Exadata为表扫描提供了列过滤，也称为列投影。只有所请求的列返回到数据库服务器，而不是表中的所有列。例如，当发布以下SQL时,只有employee_name和employee_number列从Exadata返回到数据库系统。[0073]SELECTemployee_name,employee_numberFROMemployee_table；[0074]对于具有多列或者包含LOB的列的表，所节省的I/O带宽会很大。当一起使用的，谓词和列过滤可以显著提高性能并降低I/o带宽消耗。此外，列过滤还应用到索引，允许甚至更快的查询性能。[0075]在一种实施例中，Exadata服务器从客户端接收要在储存器中持久化的数据。作为响应，Exadata服务器在两个或更多个存储设备上启动数据的存储。Exadata服务器从存储设备之一接收数据已经写入的指示，并且，作为响应，向客户端确认数据已经在储存器中持久化。在一个示例中，当数据已经写到与数据最终要在其上被持久化的目标存储设备不同的辅助存储设备时，Exadata服务器提供早期确认。在Exadata服务器提供早期确认之后，Exadata服务器管理存储设备(a)验证数据在目标存储设备上持久化，及(b)从辅助存储设备清除数据。[0076]写到目标磁盘与辅助磁盘[0077]在一种实施例中，响应存储数据的请求，存储服务器同时或近乎同时地启动数据在多个存储设备上的存储。例如，存储服务器可以启动数据在第一存储设备上的存储，然后，在从该第一存储设备接收写确认之前，启动在第二存储设备上的存储。因为写入同时在两个存储设备上都是或者有可能未完成，所以说存储服务器“并行地”在两个存储设备上启动存储。换句话说，在启动到第二存储设备的第二写入之前，存储服务器不等待到第一存储设备的第一写入完成。存储服务器可以在第二存储设备之前从第一存储设备或者在第一存储设备之前从第二存储设备接收写入确认。在有些实现中，存储服务器可以启动多于两个设备的数据存储。[0078]在一种实施例中，这两个设备包括一个目标存储设备和一个辅助存储设备。请求可以或者可以不规定目标存储设备。目标存储设备是存储或持久化被单个数据项修改过的数据集的设备。例如，利用插入操作，一个条目可以添加到存储在目标存储设备上的数据集，利用更新操作，现有的条目可以在存储在目标存储设备上的数据集中被修改，或者，利用删除操作，现有的条目可以被删除。目标存储设备存储正被写入的完整数据项集合，而辅助存储设备只存储还没有因为已经被写到目标存储设备而被清除或丢弃的那些数据项。在一个示例中，目标存储设备存储数据库日志或者数据库日志的一部分。辅助存储设备存储还没有因为已经被写到目标存储设备而被清除或丢弃的最近更新的数据库日志条目。在目标存储设备已经更新成包括与在接收一个查询之前提交的已存储数据有关的所有条目之后，对所存储数据的查询可以针对目标存储设备来执行。[0079]在一种实施例中，当确定一个写入已经在目标存储设备上完成时，存储服务器可以取消其它未完成的写入。在另一种实施例中，即使一个写入还没有报告为在目标存储设备上完成，存储服务器也可以允许未完成的写入完成。在辅助存储设备上写入的数据可以因为该数据已经写到目标存储设备而被标记为“丢弃”。[0080]到目标盘的写入的早期确认[0081]在一种实施例中，在接收到存储数据的请求之后，存储服务器向客户端提供数据已经存储的早期确认。响应该请求，存储服务器启动对多个独立存储设备的多个写入，包括一个目标存储设备和一个或多个辅助存储设备。响应接收到一个存储设备已经成功写入数据的确认，存储服务器向客户端确认数据已经存储。正常的确认是由于目标存储设备上的成功存储，而早期确认是由于辅助存储设备上的成功存储。在一个示例中，存储服务器在客户端与存储服务器之间的定制连接上向客户端发送对存储数据的客户端请求的消息或响应。即使数据还没有存储在目标存储设备上，该响应也可以指示数据已经成功存储。[0082]图5说明了用于向客户端提供正常确认的示例过程。在目标存储设备(在步骤304A中)和辅助存储设备(在步骤304B中)上都启动了数据的存储之后，该过程包括在步骤310中确定数据存储在目标存储设备上。响应确定数据存储在目标存储设备上，该处理包括在步骤308中向客户端指示数据已经存储在目标存储设备上。而且，响应确定数据已经存储在目标存储设备上，该过程包括在步骤312中从辅助存储设备清洗数据。[0083]图3-4说明了用于向客户端提供早期确认的示例过程。在目标存储设备(在步骤304A中)和辅助存储设备(在步骤304B中)上都启动了数据的存储之后，该过程包括在步骤306中确定数据存储在辅助存储设备上。响应确定数据存储在辅助存储设备上，该过程包括在步骤308中向客户端指示数据已经存储在目标存储设备上。如图3中所示，该过程可以进一步包括在步骤310中确定数据存储在目标存储设备中，并且，作为响应，在步骤312中从辅助存储设备清洗数据。[0084]清洗辅助盘[0085]在一种实施例中，在存储服务器向客户端确认存储之前或之后，存储服务器接收目标存储设备已经成功存储了数据的指示。在一种实施例中，响应目标存储设备已经成功存储了数据的指示，存储服务器触发该数据从辅助存储设备的清洗、清除或丢弃。存储服务器可以与目标存储设备已存储了数据的指示的接收同步地或异步地从辅助存储设备清洗、清除或丢弃数据。例如，存储服务器可以在确定多个数据项已经写到目标存储设备之后周期性地从辅助存储设备清洗那些数据项。作为另一个示例，存储服务器可以响应确定数据项已经写到目标存储设备而立即从辅助存储设备清洗那些数据项。[0086]在一种实施例中，依赖于存储在存储位置的数据项是否是到目标存储设备的未完成的写入，辅助存储设备上的该存储位置被标记为“丢弃”或“不丢弃”。如果数据项还没有被确认写入目标存储设备，则存储那些数据项的存储位置或者数据项本身就可以标记为“不丢弃”。如果数据项已经被确认写入目标存储设备，存储那些数据项的存储位置或者数据项本身就可以标记为“丢弃”。丢弃的数据可以被其它数据重写。例如，辅助存储设备可以在当早先的数据项被丢弃时变得可用的位置存储后来的数据。两个数据项中没有一个、任何一个或者两个的存储可能导致对客户端的早期确认。[0087]在一种实施例中，每个辅助存储设备都具有有限的存储量，例如32MB。一旦辅助存储设备满，存储设备就开始在辅助存储设备的开始，在已经标记为“丢弃”的所存储数据的位置，存储数据。在一种实施例中，为每个辅助存储设备维护头指针和尾指针。头指针指向用于存储数据的下一个存储位置，而尾指针指向还没有标记为“丢弃”的最早存储位置。当辅助存储设备接收到新的存储请求时，头指针被更新。当辅助存储设备完成了存储请求时，尾指针被更新。除非头指针赶上尾指针，否则，以类似于循环缓冲区的方式，数据可以继续存储到辅助存储设备上。[0088]如图3的示例过程中所示，在向客户端提供早期确认之后，该示例过程可以包括在步骤310中确定数据存储在目标存储设备上。在步骤312中，数据可以从辅助存储设备清洗。一旦数据已经清洗，被该数据占用的空间就可以用于在辅助存储设备上存储其它的数据项。[0089]从辅助盘恢复[0090]在一种实施例中，存储服务器首先尝试把数据既写到辅助存储设备又写到目标存储设备。无论何时当辅助存储设备报告数据已经写入时，写入的早期确认可以提供给客户端。如果数据没有成功地写到目标存储设备，数据就从辅助存储设备恢复。存储服务器可以重新尝试在目标存储设备上存储数据。例如，存储服务器可以在在备用存储设备上存储数据之前进行阈值次数的重新尝试。如果重新尝试成功，就可以在数据存储在目标存储设备上之后从辅助存储设备清除该数据。如果重新尝试不成功，存储服务器就可以在备用的目标存储设备上存储数据。在一种实施例中，存储服务器在备用的目标存储设备上存储数据，而不进行在初始目标存储设备上存储数据的任何重新尝试。在数据已经存储在备用的目标存储设备上之后，数据可以从辅助存储设备清除。[0091]图4说明了用于从辅助存储设备恢复数据的示例过程。在步骤410，该过程包括在目标存储设备上存储数据的同时检测错误。在步骤412，数据从辅助存储设备拷贝到目标存储设备或者另一个存储设备，例如备用目标存储设备。在步骤414，该过程包括确定数据存储在目标存储设备或者其它存储设备上。响应确定数据存储在目标存储设备或者其它存储设备上，在步骤312，从辅助存储设备清洗数据。[0092]示例实施例[0093]OLTP工作量很大程度上可以得益于数据库日志写入的快速响应时间。如果对于数据库锁和资源没有应用相关的瓶颈或争用，数据库系统性能中的一个限制因素可能就是花在等待重做日志写入上的时间量。重做日志组或镜像的日志文件的配置会对重做日志写入等待时间具有负面影响。数据库系统等待确认写入，直到写入在最慢的盘或设备上完成。此外，存储设备本身可能经历性能的偶然“打嗝”。这些尖峰在RAC环境中可能具有很大的影响，其中，在有些情况下，块会在一次日志清洗之后从一个实例运送到另一个实例。在一种实施例中，伪镜像技术消除了作为潜在瓶颈的慢重做日志写入，并且提供快速和可预测的日志写入响应时间。[0094]在一种实施例中,伪镜像技术包括由Exadata?存储服务器软件使用基于闪存的储存器进行的智能录入。因为录入涉及不仅仅把重做日志放到闪存上，所以该录入被称为是“智能的”；出于几个原因，存在双倍和镜像的日志文件。在一种实施例中，如果用户没有足够的可用闪存储存器的话，基于闪存的日志就不添加到重做日志组。即使用户有足够的闪存储存器可用于存储整个日志，基于闪存的日志可能也是昂贵的，而且，使用基于闪存的日志可能仍然会导致用户等待写入在最慢的设备上完成。[0095]在一种实施例中，智能录入包括以下过程:例如Exadata?存储服务器的存储系统接收重做日志写入请求，而且，作为响应，存储系统对盘上重做日志及闪存储存器发布异步写入。当这些写入中有任何一个完成时，该存储系统就通知数据库系统。如果硬盘临时经历慢响应时间，则闪存盘将提供更快的响应时间；相反，如果闪存盘临时经历慢响应时间(由于磨损平衡算法，例如)，硬盘将提供更快的响应时间。除非硬盘和闪存盘都同时慢，否则Exadata?存储服务器可以提供低重做日志写入延迟，硬盘和闪存盘同时慢发生的频率相当低。应当指出，闪存储存器或者其它伪镜像或次级储存器不用做重做数据的永久存储。闪存储存器仅仅是用于提供快速重做写入响应时间目的的临时储存器；闪存储存器临时存储重做数据，直到这种数据安全地写入盘中。响应确定日志数据项已经安全地写入盘中，Exadata?存储服务器可以从闪存储存器清除该日志数据项。[0096]在一种实施例中，Exadata?存储服务器伴随着相当数量的闪存储存器，而且这种储存器经智能闪存高速缓存特征结合到Exadata?存储服务器软件中。少量的闪存储存器可以用于伪镜像数据库日志；剩余的闪存储存器可以用于闪存高速缓存或者用于数据存储，按照管理员看着合适的来对待。例如，管理员可以规定一定量的空间分配用于数据库录入目的，而且这一定量的空间可以显著少于将用于存储整个数据库日志的空间量。[0097]在一种实施例中，数据库系统处理所有的崩溃与恢复场景，而不需要任何附加的管理员干预，除此之外就是通常为盘上重做日志的恢复所给出的。[0098]离群[0099]离群指超出大部分的边界的那些情况。重做写入离群可以指其延迟过大的重做写入。在一种实施例中，如果其延迟多于一毫秒，重做写入就被认为是离群。在一种实施例中，智能闪存录入显著减少了重做写入离群的个数。[0100]保存的重做[0101]在一种实施例中，当(I)有些重做日志数据首先写到闪存，而且因此对关系数据库管理系统(“RDBMS”)确认时；及(2)随后到盘的相同重做日志数据的写入遇到错误时，“保存的重做”出现。在一种实施例中，存储系统以对客户端和对数据库服务器透明的方式解决保存的重做。存储系统可以使用写到闪存的重做日志数据来写另一个盘，使得，根据客户端并根据数据库服务器，重做数据已经写到持久性储存器。可以在除写入日志数据的请求之外没有来自数据库服务器的或者来自客户端的进一步输入的情况下完成对另一个磁盘的写入。[0102]在一种实施例中，重做日志数据不保存。换句话说，如果RDBMS请求从盘进行后续的重做日志数据读取，存储系统就返回陈旧的数据并且让RDBMS通过使用其它镜像重试读取来处理该陈旧的数据。在主日志和镜像日志中存在多个故障的情况下，不理会保存的重做可能导致数据库损坏。而且，，不同的数据库服务器在它们检测到陈旧的重做数据(具有旧的日志序列号)的情况下可能不去试镜像，而且这些不同的数据库服务器可能不正确地推测日志结束的位置并且变得被卡住。在一种实施例中，代替陈旧的重做数据，如果RDBMS请求从盘进行后续的重做数据读取，就返回读错误。在这种实施例中，存储系统可以对与所保存的重做关联的盘位置保持跟踪。[0103]在另一种实施例中，保存重做日志数据。换句话说，如果RDBMS请求从盘进行后续的重做数据读取，存储系统就从保存的重做返回正确的数据。这种实施例可以提供防止多个日志故障的保护。由于所保存的重做的存储与维护，这种实施例还可能在存储系统涉及多个复杂的逻辑。[0104]在一种实施例中，重做日志数据不保存，但是，作为代替，存储系统发布足够数量的日志开关。这种实施例可以减少容易遭受日志文件镜像故障的窗口。在一种实施例中，Exadata?存储服务器能够具有到Rdbms的“反向”通道，以便请求日志开关。如果在脆弱的窗口中有多个日志故障，这种实施例可能不提供保护。[0105]在一种实施例中，存储系统保存重做日志数据，而且发布足够数量的日志开关。在一种实施例中，保留所保存的重做的时间量被最小化了。[0106]在一种实施例中，保存的重做存储在系统盘上。在另一种实施例中，保存的重做存储在闪存储存器中。[0107]在一种实施例中，当盘被拔出或死机时，出现保存的重做。对于前者，智能闪存录入逻辑可以在盘被还原时写保存的重做，在这个时候，我们可以删除保存的重做。对于后者，当得到通知盘已经失败时，智能闪存录入逻辑可以删除保存的重做。在一种实施例中，在任何一种情况下都不需要用户干预。[0108]示例智能闪存录入逻辑[0109]在一种实施例中，智能闪存录入逻辑满足以下目的:[0110]1.把重做日志数据既写到硬盘又写到闪存，并且一旦有任意一个写入完成就向RDBMS确认。[0111]2.不管最近的拷贝是存在于闪存上还是硬盘上，都返回正确的重做日志数据。[0112]3.允许管理员对规定的单元、实例或数据库或者静态地或者动态地禁用智能闪存录入逻辑。[0113]4.允许管理员查看相关度量并且经CellCL1、EM等报警。[0114]5.使用可忽略的-但可调整的-闪存存储量用于录入目的。[0115]6.如果发现一个闪存盘慢，就禁用该闪存盘上的闪存日志，并且，如果替换了闪存卡，就重新启用闪存日志。[0116]7.由管理员适度处理单元闪存盘和网格闪存盘的删掉。[0117]8.以有效而适度的方式处理保存的重做，而不需要用户干预。[0118]9.在Exadata存储服务器软件升级期间创建合适尺寸的闪存日志，并且在Exadata存储服务器软件降级期间破坏闪存日志。[0119]10.成功并透明地处理所有恢复情形，并且不引起单点故障:[0120].在数据写到闪存并且对RDBMS确认之后，包含重做日志的硬盘的故障。[0121]?在重做日志数据写到闪存但没有写到盘上并且对RDBMS确认之后，Exadata?存储服务器软件死机。[0122].在运行过程中，闪存卡的除去。[0123]在一种实施例中，智能闪存录入逻辑在涉及大量重做数据的持续生成的一个或多个基准中满足以下性能标准:(I)尽管智能闪存录入逻辑的一个目的可能是解决延迟而不是吞吐量，但是智能闪存录入逻辑可能显示出在吞吐量基准结果中可测量的改进。(2)智能闪存录入逻辑可能造成重做日志写入离群数量的大大减少。此外，智能闪存录入逻辑可能对其它并发类型的I/O(数据库读、写等)的性能没有任何可测量的影响。[0124]在一种实施例中，除了在服务器死机后重新启动的情况下之外，智能闪存录入逻辑对Exadata?服务器的可用性没有影响。在这种情况下，服务器可以基于闪存日志的内容执行一些恢复动作；但是，这些恢复动作可能花费最少量的时间。在这个恢复期间，Exadata?服务器可能不能为任何请求提供服务。[0125]此外，在保存的重做的情况下，如果智能闪存录入逻辑把保存的重做数据存储在闪存上，那么可以使用的闪存日志的量会变得足够小，使得智能闪存录入把空间都用完。当没有足够的闪存储存器可用时，智能闪存录入可以回到最慢盘写入技术。[0126]在一种实施例中，.不管有多少实例或数据库并发地请求重做日志写入或读取，智能闪存录入逻辑都按比例缩放。[0127]在一种实施例中，智能闪存录入逻辑和/或Exadata?服务器逻辑是以一个或多个计算设备的形式实现的，这些计算设备利用例如c++的编程语言的专用代码来配置或者编程。在一种实施例中，该专用代码是依赖操作系统的，而且可以例如依赖Linux操作系统。在一种实施例中，存储服务器根据Liunx环境操作，而且智能闪存录入逻辑运行在Liunx环境中。[0128]在一种实施例中，智能闪存录入逻辑提供简单和逻辑的机制，用于对给定的实例、数据库或单元启用和禁用智能闪存录入逻辑。此外，智能闪存录入逻辑还可以经CellCLI或者企业管理器(“EM”)提供访问相关的统计数据、度量和报警。CellCLI是用于监视、配置或维护存储单元效用的接口。[0129]在一种实施例中，智能闪存录入逻辑的可靠性依赖于盘-闪存盘和硬盘两者-的行为。智能闪存录入逻辑设计成在一种类型的盘暂时慢的情况下提供低延迟重做日志写入；但是，在两种类型的盘都同时慢的情况下，智能闪存录入逻辑可能不产生显著的加速。[0130]在一种实施例中，需要特定的角色或特权在RDBMS和/或存储单元上配置智能闪存录入逻辑。例如，配置可以限于系统的管理员。[0131]在一种实施例中，智能闪存录入逻辑可以完全在存储系统中实现，而不需要对RDBMS的任何更改。[0132]在一种实施例中，智能闪存录入逻辑提供诊断，来支持有效的问题分析。[0133]在一种实施例中，智能闪存录入逻辑是利用Exadata?存储服务器所使用的存储器量可忽略的增加来实现的。[0134]智能重做日志写入[0135]在一种实施例中，智能闪存录入逻辑使用“双写”策略。在一种实施例中，当Exadata?服务器接收到重做日志写请求时，Exadata?,服务器发布两个异步的写入-一个到包含重做日志的硬盘，另一个到闪存盘。响应任何一个写入的完成，Exadata?服务器向RDBMS确认写入完成。如果硬盘写入首先完成,那么从恢复的角度来看，Exadata?服务器不需要做任何事情。如果RDBMS随后请求从盘读取相同的重做块集合，则Exadata?服务器可以通过简单地从盘读那些块来满足该请求，因为它们包含正确的数据。另一方面，如果闪存盘写入首先完成，在一种实施例中，Exadata?服务器保存存储在闪存盘上的重做数据，直到相同的重做数据成功地写到硬盘。此外，如果在成功写入闪存之后对应的盘写入遇到错误，那么存储系统就可以保留闪存盘上相关的重做数据块，直到错误之后那些相同的块重新写到同一个或者另一个硬盘。在相关的重做数据已经还原到硬盘之后，相关的重做数据可以从闪存盘清理、丢弃或者清除。最后，如果在数据写入盘之前(但是在写入闪存之后)RDBMS请求从盘读取对应的重做块集合，则Exadata?服务器可以返回最近的重做数据，而不是实际存储在盘上的陈旧数据。[0136]在一种实施例中，从终端用户的角度，系统以完全透明的方式关于重做日志写入和读取运转，即，用户不知道-而且不需要知道-闪存盘是用作临时存储。类似地，用户不需要提供关于临时存储在闪存盘上的日志数据的输入，或者管理日志数据在闪存盘与硬盘之间的过渡。用户可以就好像日志数据已经存储在硬盘上一样对待闪存盘上的日志数据。在一种实施例中，唯一可以观察到的系统行为区别是系统对重做日志写入提供一贯低的延迟。[0137]RDBMS内的管理[0138]在一种实施例中，提供了一个称为“_enable_flash_logging”的新init.0ra隐藏布尔参数，来启用或禁用智能闪存录入的使用。在一种实施例中，根据缺省设置，智能闪存录入被启用，而且该设置可以在运行时经ALTERSYSTEMSET〈参数〉改变。在一种实施例中，该参数是隐藏的，以防对智能闪存录入的无意或不必要禁用。[0139]EXADATA服务器内的管理[0140]在一种实施例中，闪存日志作为第一类对象暴露，而且存储系统通过例如CellCLI的接口提供功能全集。在一种实施例中，作为第一类对象暴露闪存日志提供了对用户一致的、独立但逻辑的管理特征集合。在一种实施例中，作为第一类对象暴露闪存日志允许闪存日志独立于闪存高速缓存。闪存日志的独立本质可以允许用户单独地配置闪存日志与闪存高速缓存中的每一个，并且互不影响地禁用任何一个。在一种实施例中，作为第一类对象暴露闪存日志允许精心设计的配置选项，例如规定什么盘应当包含闪存日志的机制。[0141]在一种实施例中，用于启用/禁用闪存日志的新ALTER10RMPLAN语法允许储存器管理员启用/禁用闪存日志对某些数据库/实例的使用。在这种实施例中，用户不设置任何cellinit.0ra参数。[0142]创建闪存日志[0143]在一种实施例中，CREATEFLASHL0G命令在一个单元上为重做日志IO请求创建Exadata?智能闪存日志。下面提供一个示例语法。[0144]CREATEFLASHLOG[ALL[FLASHDISK]][0145][attribute_name=attribute_value[,attribute_name=attribute_value]...][0146]在该示例中，CREATEFLASHLOG命令接受用逗号隔开的闪存单元盘的列表。如果在命令中规定了尺寸，则那个尺寸跨单元盘均分；对于生产系统，每个单元盘16MB的最小尺寸将是强制的。如果没有规定尺寸，就使用512MB的缺省值。[0147]在该示例中，ALLFLASHDISK变元将在所有闪存单元盘上创建Exadata?智能闪存日志。如果没有规定ALL变元，就规定单元盘属性。FLASHDISK变元是不要求的。[0148]在一种实施例中，CREATEFLASHLOG命令缺省地消耗每个闪存盘上的全部可用空间。在一种实施例中，存储系统允许用户在创建FLASHCACHE之前首先创建FLASHLOG。在该示例中，两个对象都消耗由用户规定的闪存空间量。[0149]在一种实施例中，如果用户希望改变闪存日志的尺寸，用户可以破坏闪存日志(例如，经DROPFLASHLOG)，然后重新创建具有新规定的尺寸的闪存日志。下面提供示例命令。[0150]CellCLDCREATEFLASHLOGALL[0151]CellCLDCREATEFLASHLOGALLSIZE=Ig[0152]CellCLDCREATEFLASHLOGALLFLASHDISK[0153]CellCLDCREATEFLASHLOG[0154]CELLDISK='fdl,fd2,fd3,fd4’[0155]在一种实施例中，CREATECELL命令包括具有数字值的新FLASHLOG属性，使得:规定flashlog=o抑制缺省尺寸的闪存日志的创建；而规定flashlog=ii导致具有给定尺寸的闪存日志的创建，这个尺寸在所有闪存盘之间等分。[0156]闪存日志尺寸[0157]在一种实施例中,有最大闪存日志尺寸。在另一种实施例中，整个闪存盘可以专用于闪存日志。[0158]描述FLASHLOG[0159]在一种实施例中，DESCRIBEFLASHLOG命令造成FLASHLOG对象类型的属性列表的显示。下表列出了用于示例DESCRIBEFLASHLOG命令的示例属性。[0160]【权利要求】1.一种方法，包括:存储服务器从客户端接收存储数据的请求；响应于该请求，存储服务器并行地在至少两个独立存储系统中的每一个上启动所述数据的存储；响应于确定所述数据已经被存储在少于全部所述至少两个独立存储系统上，存储服务器向客户端指示所述数据已经被存储。2.如权利要求1所述的方法，其中确定所述数据已经被存储在少于全部所述至少两个独立存储系统上包括确定所述数据已经被存储在所述至少两个独立存储系统中的第一存储系统上，所述方法还包括:检测到在所述至少两个独立存储系统中的第二存储系统上存储所述数据的失败；响应于检测到所述失败，存储服务器把所述数据从第一存储系统拷贝到与第一存储系统不同的存储系统。3.如权利要求2所述的方法，还包括:响应于确定所述数据已经被拷贝到与第一存储系统不同的所述存储系统，使所述数据从第一存储系统被丢弃。4.如权利要求1所述的方法，还包括允许所述数据的存储在全部所述至少两个独立存储系统上完成，其中，在确认所述数据已经被存储之后，所述数据的存储在所述至少两个独立存储系统中的至少一个存储系统上完成。5.如权利要求1所述的方法，其中所述至少两个存储系统包括:存储正在等待存储在第二存储系统上但是还没有被确认为存储在了第二存储系统上的第一数据集的第一存储系统，及持久性地存储第二数据集的第二存储系统。6.如权利要求1所述的方法，其中存储服务器确定所述数据已经被存储在少于全部所述至少两个独立存储系统上包括确定所述数据已经被存储在第一存储系统上，还包括:存储服务器确定第二存储系统未能存储所述数据；响应于确定第二存储系统未能存储所述数据，启动所述数据在第三存储系统上的存储，其中第三存储系统是第二存储系统的备用。7.如权利要求1所述的方法，其中存储服务器并行地启动所述数据在至少两个独立存储系统中的每一个上的存储包括存储服务器并行地启动所述数据在第一存储系统和第二存储系统的选定子系统上的存储，其中所述选定子系统是第二存储系统的多个备用子系统中的一个，其中存储服务器使用所述多个备用子系统中的不同子系统来启动不同数据集的存储，其中存储服务器确定所述数据已经被存储在少于全部所述至少两个独立存储系统上包括确定所述数据已经被存储在第一存储系统上，还包括:存储服务器确定第二存储系统的子系统未能存储所述数据；响应于确定所述子系统未能存储所述数据，停用所述子系统作为由存储服务器用于启动不同数据集的存储的所述多个备用子系统中的一个。8.如权利要求1所述的方法，其中所述至少两个独立存储系统包括硬盘存储系统和闪存存储系统。9.如权利要求1所述的方法，其中所述数据是数据库日志项。10.如权利要求1所述的方法，其中存储服务器并行地启动所述数据在所述至少两个独立存储系统中的每一个上的存储是以对客户端透明的方式执行的。11.一种存储指令的计算机程序产品，当所述指令被执行时，使一个或多个处理器执行权利要求1-10中任何一项所述的方法。12.—种计算机系统，包括:一个或多个处理器；耦合到所述一个或多个处理器的用于使存储服务器从客户端接收存储数据的请求的装置；耦合到所述一个或多个处理器的用于并行地并且响应所述请求而启动所述数据在至少两个独立存储系统中的每一个上的存储的装置；用于响应于确定所述数据已经被存储在少于全部所述至少两个独立存储系统上而向客户端指示所述数据已经被存储的装置。13.—种存储服务器,包括:一个或多个处理器；第一接口，用于从客户端接收存储数据的请求；用于响应于所述请求并且在第二接口上并行地启动所述数据在至少两个独立存储系统中的每一个上的存储的逻辑；用于利用第一接口并且响应于确定所述数据已经被存储在少于全部所述至少两个独立存储系统上而向客户端指示所述数据已经被存储的逻辑。14.如权利要求13所述的存储服务器，其中用于启动存储的逻辑允许所述数据的存储在全部所述至少两个独立存储系统上完成，其中在确认所述数据已经被存储之后，所述数据的存储在所述至少两个独立存储系统中的至少一个存储系统上完成。15.如权利要求13所述的存储服务器，其中所述至少两个存储系统包括存储正在等待存储在第二存储系统上但是还没有被确认为存储在了第二存储系统上的第一数据集的第一存储系统，及持久性地存储第二数据集的第二存储系统。【文档编号】G06F11/20GK103443773SQ201280013123【公开日】2013年12月11日申请日期:2012年8月10日优先权日:2011年8月12日【发明者】K·P·斯里尼瓦桑,B·厄利克曼,J·R·洛埃扎,是佳,A·楚科曼,K·尤玛玛格斯瓦兰申请人:甲骨文国际公司