MSSQL网站制作之SQL Server 2005 中的 Multiple Active...

对于insert和delete，event中包含了插入/删除的记录的所有字段的值(太爽了。。)简介　　一切SQLServer数据会见使用程序编程接口(API)都供应了一个笼统来暗示会话和会话中的哀求。SQLServer2000和更早的版本限定编程模子，它请求任什么时候候一个给定的会话中最多只能有一个待定的哀求。有几个替换举措被用来办理这类限定，在这些替换举措中，最多见的大概就是服务器端光标。SQLServer2005完成了MultipleActiveResultSet(MARS)，它排除了这个束缚。本文先容了MARS的计划、布局和语义变动，和为了从这些改善中失掉最年夜收益，使用程序应该注重甚么。
SQLServer2000DataAccessRecap　　今朝撑持用于构建SQLServer使用程序的次要数据会见API是ODBC、OLE-DB、ADO和SqlClient.NetProvider。1它们全体都供应一个笼统来暗示一个指向服务器的已创建毗连，同时供应别的一个笼统来暗示在这个毗连之下实行的哀求。比方，SqlClient利用SqlConnection和SqlCommand工具，而ODBC则利用SQL_HANDLE_DBC范例和SQL_HANDLE_STMT范例的句柄。
　　一切发送给SQLServer的实行哀求都是几近以下两种情势之一：1)一组T-SQL语句，一般也称为批处置，大概2)存储历程或函数的称号，加上参数值（假如符合）。请注重，提交一个SELECT或DML语句给服务器是一个单语句批处置，这是第一类哀求的惯例。
　　在任何一种情形下，SQLServer城市重申批处置或存储过程当中包括的语句，然后实行这些语句。语句大概会天生了局，也大概不天生了局，而且语句大概会向挪用者前往附加信息，也大概不前往。
　　了局次要是由SELECT和FETCH天生的。SQLServer经由过程将了局前往给挪用者来实行SELECT语句。这意味着，在查询实行引擎发生行的同时，这些行会被写进收集。更切实地说，所发生的这些行会被复制到事后保存的收集缓冲区中，然后缓冲区会被前往给挪用者。收集写进操纵会乐成，并在客户端驱动程序从收集中读取时开释已用过的缓冲区。假如客户端没有损耗了局，在不异点上的收集写进操纵将会被制止，服务器中的收集缓冲区将会被填满，实行就会被挂起，守候形态和实行线程，直到客户端驱动程序捕捉读取。这类发生了局和检索了局的形式一般被称为“默许了局集”，改正式的称号则是“流水游标”。
　　附加信息也大概以其他体例（大概没有了局前往体例那末分明）被前往给挪用者。这类情形包含毛病、告诫和信息性动静。它们大概经由过程PRINT和RAISERROR语句显式前往，大概经由过程语句实行时代发生的告诫和毛病隐式前往。一样地，当NOCOUNT设置选项被设置为OFF时，SQLServer会对每一个已实行的语句发送一个“donerowcount”标志。这类附加信息也大概招致收集写进缓冲区被填满和实行被挂起。
　　这类背景使我们能够了解SQLServer2000和更早版本在撑持每毗连多个待定哀求时的一些编程模子限定。
“毗连忙碌”　　关于本文中的示例，我们将假定以下如许一个复杂的情境：一个松懈毗连的清单处置体系利用“Operations”表作为行列来吸收来自其他组件的哀求：
　　OPERATIONS
　　已处置
　　位
　　operation_id
　　int
　　主键
　　operation_code
　　char(1)
　　D–decreaseinventory
　　I–increaseinventory
　　R–reserveinventory
　　product_id
　　uniqueidentifier
　　数目
　　bigint
　　我们假定这个组件办理着分歧产物线和供给商的清单，而product_id则断定要利用哪一个服务器和数据库和怎样实行哀求的操纵。（也就是说，假定不成能写进一些成组操纵来处置行列中的一切哀求）。
　　这个组件在一个拔出到表中的松懈处置哀求中入手下手运转，并在乐成完成指定操纵时将这些哀求标志为已处置。
　　伪代码相似以下所示：
while(1)
{
　　GetallmessagescurrentlyavailableinOperationstable;
　　Foreachmessageretrieved
　　{
　　　　ProcessMessage();
　　　　Markthemessageasprocessed;
　　}
}　　后面一个利用odbc的办法相似以下所示（疏忽了一些细节和毛病处置）：
SQLAllocHandle(SQL_HANDLE_STMT,hdbc1,&hstmt1);
SQLAllocHandle(SQL_HANDLE_STMT,hdbc1,&hstmt2);
while(true)
{
　SQLExecDirect(hstmt1,(SQLTCHAR*)"selectoperation_id,
　　　operation_code,product_id,quantityfromdbo.operations
　　　whereprocessed=0",SQL_NTS);
　while(SQL_ERROR!=SQLFetch(hstmt1))
　{
　　　ProcessOperation(hstmt1);
　　　SQLPrepare(hstmt2,
　　　　(SQLTCHAR*)"updatedbo.operationssetprocessed=1
　　　　whereoperation_id=?",SQL_NTS);
　　　SQLBindParameter(hstmt2,1,SQL_PARAM_INPUT,SQL_C_SLONG,
　　　　SQL_INTEGER,0,0,&opid,0,0);
　　　SQLExecute(hstmt2);
　}
}　　可是，实验实行hstmt2会招致：
[Microsoft][ODBCSQLServerDriver]Connectionisbusywithresultsforanotherhstmt.　　利用SqlClient写进到MicrosoftVisualC#中的不异逻辑相似以下所示：
SqlCommandcmd=conn.CreateCommand();
SqlCommandcmd2=conn.CreateCommand();
cmd.CommandText="selectoperation_id,operation_code,product_id,quantity
　fromdbo.operationswhereprocessed=0";
cmd2.CommandText="updatedbo.operationssetprocessed=1
　whereoperation_id=@operation_id";
SqlParameteropid=cmd2.Parameters.Add("@operation_id",SqlDbType.Int);
reader=cmd.ExecuteReader();
while(reader.Read())
{
　ProcessOperation();
　opid.Value=reader.GetInt32(0);//operation_id
　cmd2.ExecuteNonQuery();
}　　一样地，实验实行此逻辑会招致：
InvalidOperationException,ThereisalreadyanopenDataReaderassociatedwiththisConnectionwhichmustbeclosedfirst.　　这些毛病是短少MARS的最间接证实；在任什么时候候，一个给定的SQLServer毗连之下最多只能有一个待定哀求。
　　我成心疏忽了OLEDB，由于它会发生稍微有点分歧的举动。
“我已有MARS”　　因为之前版本的SQLOLEDB客户端驱动程序实验摹拟MARS，因而在MARS方面应特别看待OLE-DB。但是，这类实验具有良多缺点。上述示例的一个OLEDB片段相似以下所示（仍是那样，没有毛病处置）：
pIDBCreateCommand->CreateCommand(NULL,IID_ICommandText,(IUnknown**)&pICommandText);
pIDBCreateCommand->CreateCommand(NULL,IID_ICommandText,(IUnknown**)&pICommandText2);
pICommandText->SetCommandText(DBGUID_DBSQL,
　OLESTR("selectoperation_id,operation_code,product_id,quantity
　fromdbo.operationswhereprocessed=0"));
pICommandText2->SetCommandText(DBGUID_DBSQL,OLESTR("updatedbo.operations
　setprocessed=1whereoperation_id=?"));
//Executethecommand
pICommandText->Execute(NULL,IID_IRowset,NULL,&cRowsAffected,(IUnknown**)&pIRowset);
...
ProcessOperation();
...
//Executethecommand2
pICommandText2->Execute(NULL,IID_IRowset,NULL,&cRowsAffected,NULL);　　真风趣，这段代码乐成运转了，而且看来仿佛能够实行我想要实行的义务。假如说短少MARS是一个基础引擎限定，它是怎样乐成实行的？在经由一些反省以后，我们看到，SQLOLEDB驱动程序在covers上面发生了一个新毗连，并在其下实行Command2。这意味着我已有了MARS，对吗？不完整正确。
　　数据库引擎中并没有出格实行甚么义务，以便让这两个毗连能够很好地协同事情。它们只是两个毗连，因而它们具有分歧的实行情况，而且更加主要的是，它们之间大概会发生抵触。SQLOLEDB会避免在某个会话处于显式事件中时发生新毗连，这是由于存在一个对ITransactionLocal->StartTransaction的显式挪用，或是由于DTC事件中已挂号了该会话。在这类情形下，实行命令2将会失利。
　　可是，假如个中一个命令经由过程TSQL入手下手一个事件，则SQLOLEDB就不会晓得这类情况，而且会同意创立其他毗连。不幸的是，两个分歧的命令（外表上是不异会话的一部分）会在分歧的事件下停止运转。
　　提拔会话的伶仃级别-好比说REPEATABLEREAD-会使上述使用程序片段停止在一个欠好的形态中。命令1运转查询，检索操纵表中一切未处置的行。因为伶仃级别较高，因而要比及事件停止时才会排除锁定。因为没有显式事件正在利用中，因而语句运转在auto-commit形式下，要比及语句停止时才会排除锁定。假如对某个特定行设置了锁定，而此时命令2修正该行，则会呈现一个包括客户端代码的逝世锁，而使用程序会被挂起。
　　

登录/注册后可看大图

　　为了让了局变得加倍难以展望，命令1中的语句将会在所天生的最初一行被复制到服务器的收集缓冲区中时完成，而不是在客户端使用程序读取最初一行时完成。这么做的寄义是，关于较小的行集来讲，上述代码片段将会乐成实行，但假如数据卷太年夜，以致于服务器没法在实行命令2之前完成实行命令1，则上述代码片段就会失利。一点也不奇异，在开辟情况中使用程序能够照旧运转，但它在临盆情况中部署时则会奇妙地挂起。
　　从底线上说来，它大概不是可依附SQLOLEDB的相似MARS举动的最好使用程序计划。假如您决意利用它，请注重其他隐式毗连和这大概会带来的语义寄义。
那我应该怎样做？　　既然SQLServer2000及更早版本中没有MARS，那我怎样让我的使用程序事情？依据使用程序请求，偶然必要显式利用多个毗连。在良多情形下，利用服务器端光标会很便利。
　　服务器端光标为使用程序供应了一种利用一行或多个行的一个小段代码来损耗查询了局的办法。不再具体懂得分歧范例和选项，一样平常说来，一个光标就代表着查询了局。它保护着内存中的和磁盘上的形态，如许就能够依据必要前往查询了局。
　　在一般的利用形式下，会在声明指定查询之前先声明光标。一个提取操纵会实行，以便从了局会合检索每行或多个行。一旦这些行被损耗，或是不再必要了局集，光标就会被撤除，从而开释出相干的服务器端资本。在本会商中，要申明的最主要一点是，在两个提取操纵之间没有代表光标实行任何代码。服务器上有保存形态，可是没有待定的事情。
　　ODBC和OLE-DB会表露属性，如许查询哀求就会被映照为利用服务器端光标。
　　变动上述ODBC示例可让第一个命令利用服务器端光标，从而使得使用程序情境乐成实行并依照预期体例事情。一行变动：
SQLSetStmtAttr(hstmt1,SQL_ATTR_CURSOR_TYPE,(SQLPOINTER)SQL_CURSOR_DYNAMIC,0);　　相似的变动也能够使用于OLE-DB，以匡助制止隐式发生毗连和相干缺点。
　　到此时为止，我们已看到了服务器端光标是怎样匡助办理短少MARS的成绩的。恰如我们将在前面先容的，并非说供应了MARS就不必要利用光标，也不是说一切利用光标的使用程序都必需改成利用MARS。
　　天然而然，下一个成绩就是“为何不老是利用服务器端光标来替换看来限定更多的默许了局集”？1)并非一切无效的SQL上都撑持一切光标范例，2)光标一次只能操纵一个SELECT语句和3)功能。
　　因为了局在可用时被“推出”的体例，默许了局会议比服务器端光标实行得更好。另外一方面，关于每次提取操纵光标城市请求一个到服务器的往复。
　　总之，我们能够说MARS的一切目标就是为懂得除“毗连忙碌”，这关于编程模子来讲是一个严重的改善。
事件和实行情况从头捕捉　　SQLServer2000及更早版本中的会话能够处于以下任何一种大概的形态下：
•　　没有举动事件处于形态：这一般称为auto-commit形式，它意味着会话中实行的一切语句都运转在独自的事件中。
•　　当地事件处于举动形态：会话中实行的一切语句都运转在经由过程显式TSQLBEGINTRANSACTION命令或IMPLICIT_TRANSACTIONON设置而启动的事件下。
•　　已挂号：会话已在其他会话或其他事件办理器所具有的事件中挂号。前者是经由过程利用绑定会话(sp_getbindtoken/sp_bindsession)来完成，后者是经由过程在DTC事件中挂号来完成的。
　　因为MARS不成用，因而在任何给准时间，在不异事件下不成能有多个语句正在实行。即便是在绑定会话或DTC情形下，基本布局也会确保在事件情况中，一个会话中一次只能产生一项事情。
　　在ODBC和OLE-DB/ADO中，在会话中启动事件以后，一切后续哀求城市在可发生一个会话局限的事件情况如许的事件之下实行。
　　在SqlClient中，这个模子看来不太直不雅。我们供应了一个API以从毗连(SqlConnection)工具入手下手一个事件，这个毗连工具前往一个代表新创立事件的笼统(SqlTransaction)。在一种看来对照随便的体例下，一旦事件被创立，假如未将哀求显式与事件高低文创建联系关系，就不克不及实行任何哀求。SqlClientAPI供应了一种编程模子，在这类编程模子下，事件不用在全局局限内感化于毗连，多个事件能够在一个会话下创立，而哀求能够被自在映照就任何举动事件。只管SQLServer2005不撑持每一个毗连多个举动事件，可是编程模子已能够顺应如许一种将来的加强功效。
　　在MARS下，在一个给定的会话下能够有多个哀求处于待定形态，从而，关于运转在不异事件下的哀求之间产生的抵触请求得当的语义界说。
　　相似于SQLServer2000，哀求对实行情况所做的任何变动城市成为全局会话变动。实行情况切实其实切寄义是甚么？它包括SET选项值（比方ARITHABORT）、以后数据库高低文、实行形态变量（比方@@error）、光标和一时表。
　　在请求变动以后数据库的哀求中实行一个USE语句会招致一切后续哀求都在新高低文中实行。相似地，变动批处置中SET选项的值则意味着一切后续实行城市在新设置值之下运转。
　　MARS排除了一个会话下最多只能有一个待定哀求的限定，在保存后向兼容性的同时，它为实行情况中的变动界说了更加精密的语义。
MultipleActiveResultSet–MARS　　此时您对MARS是甚么大概已有了一个含混的观点。复杂说来，它就是可以让多个待定哀求处于一个SQLServer毗连之下的才能。多半情形下，这能够间接了解为在不异会话外部实行其他操纵的同时存在多个默许了局集（流水游标）的才能。
　　分清MARS不是甚么也很主要：
•　　平行实行：只管MARS能够在一个毗连之下提交多个哀求，但这其实不意味着这些哀求会在服务器内平行实行。MARS会在毗连中的多个存在的哀求之间复合实行线程，在事后界说好的点上交织实行。
•　　光标交换：后面说过，在一些情形下光标能够作为短少MARS的符合办理举措；它关于迁徙这些情境利用MARS大概对照无效。可是，这其实不意味着以后利用的一切光标都应该转为MARS。
　　默许情形下，在对SQLServer2005利用撑持MARS的客户端驱动程序时，后面一节中包括的一切代码片段都“能够事情”。在撑持MARS的毗连下，下面所说的逝世锁情境（使用程序被挂起）如今也能够乐成运转了。
　　撑持MARS的客户端驱动程序以下：
•　　SQLNativeClient中包括的SQLODBC驱动程序
•　　SQLNativeClient中包括的SQLOLEDB驱动程序
•　　.NETFramework版本2.0中包括的SqlClient.NetDataProvider
　　默许情形下，这些驱动程序将会创建撑持MARS的毗连。假如出于某种缘故原由，您想要创建保存上级驱动程序举动的毗连，每一个API都供应了一个哀求非MARS毗连的选项。
　　SqlClient供应了MultipleActiveResultSets毗连字符串选项。假如此项设置为false，则不同意对会话利用MARS。假如此项设置为true或疏忽此项，则可使用MARS。
　　一样地，ODBC供应了一个SQL_COPT_SS_MARS_ENABLED毗连选项，而OLE-DB供应了一个SSPROP_INIT_MARSCONNECTION选项。再夸大一次，仅当必要禁用MARS时（由于默许是启用MARS的）才必要利用这些选项。
　　注重只要SQLNativeClient版的ODBC和OLEDB供应程序才供应MARS。旧版的供应程序还没有加强到撑持MARS。不必说，新版驱动程序在毗连到SQLServer2000或更早版本的服务器时也不撑持MARS。
交织实行　　在更深层寄义上，MARS是关于在一个毗连内启用多个哀求的交织实行。也就是说，同意成批实行，而且在实行中还同意实行其他哀求。请注重，MARS是在交织实行而不是平行实行的意义上界说的。
　　MARS布局同意多个批处置以交织体例实行，只管实行只能在界说优秀的点切换。现实上，年夜多半语句都必需运转在一个批处置中。只要以下语句能够在完成之前交织实行：
•　　SELECT
•　　FETCH
•　　READTEXT
•　　RECEIVE
•　　BULKINSERT（或bcp接口）
•　　异步光标添补
　　它切实其实切寄义是甚么？它的寄义是必需比及作为存储历程或批处置的一部分实行的不在此列表中的任何其他语句运转终了，实行才能够被切换到其他MARS。
　　作为示例，能够假想有一个提交了较长的运转中DML语句的批处置；假定就是一个UPDATE语句（它会影响几十万个纪录）。假如正在实行这个语句时，提交了第二个批处置，那末它的实行就要比及UPDATE语句完成时才会入手下手。
　　另外一方面，假如SELECT语句是第一个提交的语句，那末UPDATE语句就能够在SELECT语句中运转。可是，在DML操纵完成之前，不会为SELECT语句天生任何新行。
　　这再一次申明了MARS交织处置而不是平行处置哀求。交织处置不会遭到哀求语句地位的影响，不管它是位于批处置中、位于EXEC语句中仍是位于存储过程当中。
　　注重只需入手下手天生行，RECEIVE语句就能够交织处置。关于在WAITFOR子句中实行的RECEIVE语句，当该语句处于守候形态时，它是不成交织处置的。
　　注重只要在SETXACT_ABORTON之下实行，而且拔出操纵的表方针中没有界说任何触发器，大概指定了不激发触发器的选项，Bulk操纵才能够交织实行。RECEIVE只要在XACT_ABORT设置为ON是才能够交织实行。
　　注重实行托管代码时，没法交织实行用任何.Net言语编写的存储历程。假如利用了inproc数据供应程序，那末已实行的批处置就要遭到语句的交织实行和原子实行的一般划定规矩束缚。
MARS功能和本钱思索　　下面说过，MARS是SQLServer数据会见API的默许处置形式。它的实行形式–不像服务器端光标–撑持多量量语句，而且还能够挪用存储历程和静态sql操纵。关于在个中天生了局的“流水游标”形式，默许了局集(MARS)的功能会优于服务器端光标。
　　只管个中另有某种很好的打印。默许了局会议“尽量快地”天生了局。只需客户端驱动程序或使用程序正在损耗所天生的了局，就会发生这类情形。假如使用程序没有损耗了局，服务器端缓冲区会被填满，处置就会被挂起，直到了局被损耗。当实行被挂起时，良多资本会被占用：数据和架构被锁定，服务器事情线程被占用（包含仓库和其他相干内存）。请注重，这类情形不但限于MARS；当一个哀求天生了没有被疾速损耗的默许了局集时，它代表SQLServer2000和更早版本所招致的开支是不异的。MARS其实不意味着在流水游标开支方面的改善。
　　关于服务器端光标，其实不存在这类资本占用的情形。在某种水平上有些干系，依据哀求的光标范例，大概可使用默许了局集没法利用的其他语义，即了局的可转动性和可更新性。
　　因为下面已先容了哀求的处置历程，如今我们间接揣度从SQLServer（假定不请求可转动性和可更新性）检索了局的用法指南：假如使用程序可以疾速地损耗了局，那末MARS下的默许了局集就能够供应最好的功能和开支特性。假如使用程序损耗了局的速率对照迟缓，则倡议利用服务器端光标，特别是FAST_FORWARD光标。
　　在年夜多半情形下，合适利用MARS默许了局集。那末有甚么迟缓损耗了局的示例呢？想像一下实行前往了局的批处置或存储历程的使用程序，行的损耗取决于数据库内部操纵（比方用户输出、UI操纵、与其他义务同步，等等）的完成。一样平常说来，哀求长工夫处于待定形态会影呼应用程序和SQLServer的可伸缩性。
事件语义　　MARS的引进改动了数据库引擎外部良多现有的假定，包含事件语义和一个事件内的并发操纵。
　　只管OLE-DB在会话中有一个事件处于举动形态时会克制隐式发生毗连，而且ODBC也常常利用“毗连忙碌”来回绝其他哀求，但在撑持MARS的天下里，这些事变都能够乐成做到。假如会话中有一个举动事件，一切新的哀求城市运转在指定事件之下；假如会话中没有举动事件，那末每一个批处置城市运转在autocommit形式下，这意味着每一个实行的语句都运转在它本人的事件之下。
　　SqlClient托管供应程序的模子更加分明。SpecificSqlCommands必要联系关系给定的SqlTransaction工具，以便指定特定哀求运转在哪一个事件之下。
　　一样平常说来，事件断定了多个用户之间的断绝。可是在MARS下，多个哀求能够运转在不异的事件之下，这使得哀求之间相互兼容，并制止发生“从头捕捉”一节中所述的逝世锁。可是，假如在不异事件下有两个哀求之间存在抵触操纵，又会怎样呢？
　　有几种大概的情形，上面分离申明：
•　　一个哀求正在读取某些了局（好比说SELECT、FETCH或READTEXT）。别的一个哀求修正了正在读取的数据（好比说DML操纵）。在这类情形下，只管变动操纵乐成，但读取操纵自力于变动，因而一切读取的数据看来就是读取操纵入手下手时的形态。请注重，只要读取操纵先于修正操纵入手下手，才有大概发生这类情形。假如DML语句起首入手下手实行，那末读取操纵就要比及前面才实行，如许就能够看到一切变动了。
•　　两个哀求实验修正不异数据。关于语句的原子数划定规矩，必需在DML语句运转终了后才干运转其他语句。因而，实验修正数据的两个批处置永久不会交织实行。哀求会依照按次实行，而了局会反响实行的按次。请注重，假如客户端使用程序是多线程的，这大概会发生非断定性举动。
•　　一个哀求正在读取数据（好比说SELECT、FETCH或READTEXT），但任一基础工具的架构被修正了（好比说DML操纵）。在这类情形下，DDL操纵会失利，由于在不异的事件下存在抵触的待定哀求。请注重，这类举动也合用于在RECEIVE语句发生了局时实验变动服务代办署理行列架构的情形。
•　　堆叠操纵产生在被批量拔出的表上。BULKINSERT（或bcp、IRowsetFastLoad）能够非原子运转，便可以与其他语句交织实行。可是，在BULKINSERT的工具方针上不克不及并发实行任何DDL、DML或读取操纵。这类情形下会发生一个毛病，由于在不异的事件下存在抵触的待定哀求。
　　请记着，上述情形仅合用于哀求运转在不异事件下。关于运转在分歧事件下的哀求，则合用惯例的锁定、制止或断绝语义。
　　特地说一下，事件框架完成的MARS下的事件语义如今也用于绑定会话和DTC。这意味着只管它之前只能在没有哀求处于待定形态时变动事件高低文，如今则可以在撑持非原子运转的一组不异语句时代切换高低文。一样地，在DML、DDL和其他必需原子运转的语句实行时，不克不及切换事件高低文。
　　注重假如在给定事件下存在待定的哀求，则实验提交事件将会失利。
保留点　　事件保留点一般用于同意在一个事件外部部分回滚。一般，使用程序入手下手一个事件，设置保留点，举行某些事情，然后假如事情乐成则持续，不乐成的话则回滚到保留点。以下示例显式了保留点运转在不异事件下两个事件的交织：
工夫批处置1批处置2　　T1
　　入手下手事件；
　　T2
　　删除dbo.operations，个中operation_id=5；
　　T3
　　保留事件sp1；
　　T4
　　拔出dbo.operations默许值；
　　T5
　　删除dbo.operations，个中operation_id=10；
　　T6
　　拔出dbo.operations默许值；
　　T7
　　假如@@error>0
　　回滚事件sp1；
　　...
　　Tn
　　提交事件；
　　在上述示例中，第一个哀求入手下手一个事件，并实行某项事情（删除一行）。然后批处置2入手下手运转（在不异事件下），并实验设置保留点，以确保事件内的一组给定的语句要末乐成实行，要末原子失利。
　　可是，在批处置2实行这两个语句的时分，一个来自批处置1的删除操纵被交织实行。假定批处置2中呈现了一个毛病，哀求将会实验回滚到保留点sp1。可是，这也会“静态”回滚批处置1在T5时实行的删除操纵。
　　为了不这类不成展望和难以调试的情形产生，当一个事件中有多个举动哀求正在运转时，MARS不同意设置保留点、回滚到保留点和提交事件。假如上述这两个哀求依照按次实行，操纵会乐成，但在指定的并发哀求如上述体例交织实行的情形下，在批处置2中设置保留点的实验将会失利，并发生一个毛病。
实行情况　　后面说过，看起来实行情况仿佛是一个遍及全部会话的全局情况。在MARS下，假如多个哀求同时变动情况会产生甚么？请看以下示例：
工夫批处置1批处置2批处置3　　T1
　　利用operations；
　　T2
　　利用msdb;
　　T3
　　从dbo.operations当选择operation_id；
　　从sys.objects当选择称号；
　　...
　　Tn
　　从sys.objects当选择称号；
　　下面的示例显式了三个批处置运转在不异的毗连下。批处置1和批处置2变动数据库高低文，然后运转SELECT语句。批处置3则在稍后的工夫运转SELECT语句，但没有指定命据库高低文。假如实行情况是毗连的真正全局形态，那末上述组合的了局关于使用程序开辟来讲将是使人狐疑和不成展望的。
　　MARS具有哀求级别实行情况和会话级别默许实行情况。当哀求入手下手实行时，会话级别情况就会被克隆成哀求级别情况。在全部批处置完成以后，所发生的情况会被复制回会话级别默许实行情况。
　　在这类语义下，哀求的实行按次（SQLServer2000中独一同意的举动）供应了一个单一会话全局实行情况的假象。可是，在并发MARS哀求下，一个哀求所做的变动其实不会影响其他并发实行的哀求。
　　在上述示例中，会话情况被复制到批处置1和批处置2上，然后这两个批处置的SELECT语句就会运转在所希冀的数据库高低文中。完成以后，这两个批处置就会复制（和掩盖）会话情况。请注重，在在这类情形下，所发生的会话数据库将取决于批处置1和2的完成工夫。假设批处置3在批处置1和批处置2完成以后入手下手实行，那末依据后面两个哀求的工夫，前往的了局将对应于“operations”或“msdb”数据库。
　　请注重在MARS下编写多个批处置程序的高低文复制语义。高低文的复制包含SET选项和其他的实行情况。
　　注重假如某个批处置被作废，实行情况默许会被复制回作废哀求被确认时的会话情况。
MARS逝世锁　　MARS撑持几种新的情境，但因为这一般是一些具有壮大功效的情形，因而它也增添了您射逝世本人脚步的时机。请看以下示例。
　　传统上，同意对DML语句利用触发器。SQLServer2005扩大了这类模子，它同意在DDL语句上界说触发器。如今，我们来看看使用程序决意向挪用方放返来自触发器外部的了局（固然不是您将要依照这个可骇的实习操纵的）。触发器主体界说中包括一个SELECT语句。从使用程序角度看来，伪代码应该相似以下所示：
Request1:updatetableoperations;//thiswillreturnresultsfromthetrigger.
Foreachrowreturnedfromthetrigger
{
　　Request2:Readfromsomeothertablebasedoncurrentrow;
}　　使用上述示例，我们创立了一种新型的使用程序逝世锁。从request1每前往一行，Request2城市实验实行。可是，因为request1是一个DML语句，因而必需等它运转终了，任何其他语句才能够实行。不异情形也合用于DDL语句。在这类情形下，要比及request1完成后request2才会运转。可是，request1的完成又取决于每一个request2的实行。
　　MARS经由过程在逝世锁检测链中增加制止收集操纵，从而办理了这个成绩。关于上述情境，SQLServer的逝世锁监督器将会检测情况，然后停止Request2并显现一条毛病信息，指出会话正忙于呼应其他哀求。
　　作为一样平常性划定规矩，请记着哪些语句必需原子运转，并确保没有任何操纵会制止它们行进。更主要的是，确保它们不会被依附于后面语句完成的操纵所制止。
　　从触发器前往了局是在这类情况中运转的最复杂的体例。因为这个缘故原由和其他一些缘故原由，我们激烈倡议不要从触发器前往了局。这包含没有分派子句的SELECT语句、没有分派子句的FETCH语句、PRINT语句和其他在NOCOUNT设置为OFF时运转的语句。
监督和诊断　　恰如我们看到的，MARS已改动了SQLServer引擎内的一些中心假定。很主要的一点是，在监督和诊断SQLServer实例时请记着一些新假定。
　　在SQLServer中，一个spid代表一个会话。因为之前版本中没有MARS，因而很广泛地就将spid与哀求联系关系在一同。广泛想到要检索某个给定spid的SQL文本。广泛在多个体系过程当中查找spid的实行统计。一切这些关于撑持MARS的情境来讲大概不再充足。
　　只管体系历程持续显现某个会话的信息，我们仍是完成了一些改善以匡助监督MARS。
　　新的“静态办理视图”(DMV)sys.dm_exec_sessions代表了会话信息的新视图，包含会话默许实行情况。在这类视图下，传统上的spid反应在session_id列下。
　　同时，sys.dm_exec_connections也可用于显现一切已创建的指向服务器的物理和逻辑毗连。逻辑毗连是为运转在MARS下的每一个哀求创建的会话中的假造管道。关于逻辑毗连来讲，parent_connection_id列是被添补的。一般session_id列也显现了一个会话中多个逻辑毗连的干系。
　　一个新的DMV（sys.dm_exec_requests）暗示每一个会话下可用哀求的具体列表。
　　还引进了一个新的外部函数current_request_id()，以即可以经由过程编程体例找到以后实行哀求的id。.这相似于现有的@@spid函数。
总结　　SQLServer2005中的MultipleActiveResultSets(MARS)撑持增添了开辟SQLServer使用程序的选项。它带来了光标编程模子与相干引擎的默许处置模子的功能和功效。
　　MARS为利用多个毗连来克制短少MARS成绩的一些使用程序供应了很好的替换举措。可是，偶然也纷歧定利用MARS，由于多个毗连的确在服务器中供应了平行实行的才能（假设它们没有在不异事件中挂号的话）。
　　只管在良多情形下，MARS能够作为服务器端光标的替换举措，并能够供应一些功能改善，但它其实不能替换光标。恰如本白皮书中先容的，在良多情形下MARS是很好的替换举措，但也有良多情形利用光标会更加符合。
　　复杂说来，MARS是一个编程模子加强，它同意多个哀求能够在服务器中交织实行。只管它不代表能够在服务器中平行实行，但假如准确利用的话它的确能够发生一些功能长处。
Memory所有数据置于内存的存储引擎，拥有极高的插入，更新和查询效率。但是会占用和数据量成正比的内存空间。并且其内容会在Mysql重新启动时丢失

多加的系统视图和实时系统信息这些东西对DBA挑优非常有帮助，但是感觉粒度还是不太细。

其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起，不用像Oracle那样还要用子查询进行封装。

对递归类的树遍历很有帮助。个人感觉这个真是太棒了！阅读清晰，非常有时代感。

是要和操作系统进行Socket通讯的场景。否则建议慎重！

相信各位对数据库和怎么样学习数据库都有一些经验和看法，也会有人走了一些弯路总结出自己的经验来，希望大家能把各自的看法和经验拿出来分享，给别人一份帮助，给自己一份快乐

而SQLServer如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。

另一个是把SQL语句写到服务器端,就是所谓的SP(存储过程);