Sybase对多个临时数据库tempdb的支持

发现Sybase有个非常有趣的特性，就是支持多个tempdb。虽然一向对Sybase没什么好感，但对这个特性还是十分欣赏。查看了一点资料，觉得Sybase自身的一个白皮书比较权威，试着做个翻译。

概述

当数据库应用程序需要存储中间结果或者数据时，就需要临时空间。在Sybase的旗舰产品 ASE中，这个临时空间将由一个特殊的系统数据库tempdb来提供。而且，SQL语句对数据进行处理时，也会用到一些临时表。所有这些都将导致 tempdb数据库的沉重负担。过去，大量应用对tempdb数据库中数据和日志的争用导致性能下降。

对多个临时数据库tempdb的支持在Sybase ASE 12.5.0.3中被引入，在12.5.1中得到完善。该特性使用户可以创建多个临时数据库，并且能够给应用程序指定一个或多个临时数据库作为该应用程序 的专用库。有了这个革命性的特性，系统管理员们现在就能对tempdb这项资源有了更强的控制。该特性能够更好地实现资源分配，增加可用性，提升系统性 能。

特性简介

多tempdb支持特性使得用户可以创建多个临时库，这些库又可以在后续的应用中创建临时对 象。借助一个系统存储过程，DBA可以把任何用户及应用程序绑定到指定的临时库或者临时库组中。默认组是由系统创建的，系统tempdb就属于该组。 DBA可以将其它临时库加入该组。

登录/连接建立时，根据存在的绑定，会话就被指定到一个特定的临时库中。如果一个登录账号被 绑定到一个特定的临时库，并且该临时库可用，那么建立的会话就指向该库；如果登录账号没有绑定，或者绑定的是一个临时库组，那么系统会根据Round- Robin算法（轮询算法）从默认组中选定一个临时库，使会话指向它。

指定给会话的临时库在会话终止之前一直有效，并且不会发生改变。该会话所创建的所有临时对象 也存在于该临时库中。该会话中调用存储过程所创建或访问的临时表也存在于该临时库中。当会话结束或者服务器停止服务时，所有这些对象都会自动清除。当然， 临时表也也可以在会话过程中显式清除。

用户创建的临时库跟系统tempdb非常相似，它们都是被用来创建临时对象，而且，它们中的数据或对象在被清除后是不可被恢复的。跟系统tempdb相比，用户创建的临时库是可以被DBA删除的。

临时库是一种系统资源

在Sybase ASE 12.5.0.3推出之前，对于将临时库中的空间分配给各个应用程序这样的问题，DBA毫无办法。系统tempdb是被所有应用程序共用的。在此情形下， 要确定能满足各个应用程序需求的临时库大小很难办到。一个对资源存在大量需求的应用程序可能就会占光tempdb的全部空间，从而导致一些关键应用失败， 应为没有可用的tempdb空间了。在ASE 12.5.0.3中，用户可以使用以下的语句创建新的临时库：

Create temporary database tempdb_1 on tempdb dev = 50

该语句将创建一个名为tempdb_1的临时库。该库可以被加入默认临时库组。ASE 12.5.0.3的用户手册“新特性”一节中对于该项新特性有更多的细节。一般来说，在创建用户数据库时将日志和数据存放在不同的设备上总是有益的。但在 创建用户临时数据库时，这样做却没有必要，因为在写日志时“写”命令被进行了特殊处理，细节将在之后的部分详述。

要将用户创建的临时库加入默认的临时库组，需要使用系统存储过程sp_tempdb：

Sp_tempdb ‘add’, ‘tempdb_1’, ‘default’

Tempdb_1现在就成为了默认组的一个成员。所有属于默认组的临时库可以通过如下的语句查看：

Sp_tempdb ‘show’

当用户建立连接时，ASE数据库引擎就会根据Round-Robin算法从默认组中选出一个 临时库，并指派给该连接。举例来说，如果默认组中只有两个临时库，所有的应用程序都被绑定到了默认组上，假定有10个用户连接，那么5个将被指定到 tempdb，余下的将被指指定到tempdb_1。这样就实现了默认组中用户的负载均衡。

提请注意，应用程序不是必须应用该特性。应用程序创建的所有带“#”前缀的临时表都是创建在应用程序连接时就指定的临时库中的。

临时库也可以随时脱离所加入的默认组。你可以在负载高峰期配置多个临时库来满足需求，并在高峰期后删除它们。所有这些操作都不必让ASE停止服务，也不需要将数据库设为单用户模式。

为不同应用分配资源

ASE 12.5.1对该特性进行了完善，任何应用或登录连接都可以被绑定到指定的临时库中。举例来说，假定有两个应用程序在运行，一个是处理高效OLTP事务 的，另一个是个后台批处理。OLTP应用就可以绑定到一个创建在RAM盘上的临时库上，而那个后台批处理应用就可以绑定到一个创建在常规磁盘上的较大临时 库上，因为它需要较大的临时空间。你可以这样做。

假定OLTP应用程序的名字是“oltp_app”，我们可以用：

Create temporary database oltp_tempdb on ramdev = 50

go

sp_tempdb ‘bind’, ‘AP’, ‘oltp_app’, ‘DB’, ‘oltp_tempdb’

go

假定批处理应用程序的名字是“batch_app”，我们可以用：

Create temporary database batch_tempdb on dbdev = 500

go

sp_tempdb ‘bind’, ‘AP’, ‘batch_app’, ‘DB’, ‘batch_tempdb’

go

这样，需要大量临时空间的批处理应用就不会与需要相对较小临时空间但需要快速响应的OLTP应用产生冲突。

绑定可以被随时解除是该特性的一个重要体现。而且，用户创建的临时库在较少使用时可以删除。举例来说，以上的批处理应用运行结束以后，该临时库就可以删除，从而释放磁盘空间。如下命令实现这一目的：

Sp_tempdb ‘unbind’, ‘AP’, ‘batch_app’

go

drop database batch_tempdb

go

因为临时库可以被随时创建和删除，DBA就可以轻易实现对临时库资源的高效管理。

绑定登录账号到特定临时库是该特性的另一个重要方面。这对于sa账号尤其重要，该特性能够帮助DBA在不跟其它应用程序争临时库资源的前提下高效地执行一些关键的管理任务。需要用到的命令如下：

Create temporary database sa_tempdb on sadbdev = 100

go

sp_tempdb ‘bind’, ‘LG’, ‘sa’, ‘DB’, ‘sa_tempdb’

go

在ASE 12.5.0.3发布以前，如果tempdb空间用完，sa也不能执行一些需要用到tempdb空间的存储过程。有了ASE 12.5.0.3，DBA就可以为sa保留一个专用的临时库。这就保证了sa可以可靠地进入系统，执行管理任务。

类似地，任何用户登录都可以被分别绑定到指定的临时库上，这样管理起来就有更大的灵活性。值得注意的是，绑定任意的用户登录（不仅仅是sa）是ASE 12.5.1及之后的版本才提供。

服务器结合

现今，IT界的一大趋势是把一个企业范围内的各种应用程序放到一起，在一个服务器上运行。当这些应用程序在同一个ASE服务器上运行时，它们很快就会发生冲突，因为它们共用同一个tempdb。有了多临时库支持，DBA就能将每个应用程序绑定到合适的临时库。

增强的可用性

可用性是企业应用的一项关键指标，Sybase在这方面给予了最高程度的重视。有了多临时库 支持，在单个临时库不可用时DBA们可以不用那么紧张了。在ASE 12.5.0.3发布之前，一旦tempdb崩溃，服务器就不得不重启。但是现在，有了多个临时库，DBA们就可以从默认组中删除崩溃的临时库，其它临时 库会分担之后的负载。这项技术显著降低了系统的宕机时间。

性能提升

多临时库支持特性对系统性能的提升表现在两个主要的方面，更大的事务处理能力（吞吐量）和更短的响应时间。

减少资源争用

有了多个临时库，两个重要的资源争用会降低：系统目录争用和日志争用。

在ASE 12.5.0.3之前，每在tempdb中创建或删除一个对象，就要往/从tempdb的系统目录中插入或删除一行纪录。这是资源争用的一个方面。有了多 个临时库，这种争用将显著降低。一项内部测试表明，在只有一个tempdb时，随着客户增加，对系统目录的争用急剧增长；增加临时库能显著降低对系统目录 的争用。

类似，为tempdb事务分配多个日志设备而不是仅分配一个也能极大减少日志纪录的瓶颈。其 结果就是，多个临时库增大了系统的吞吐量。在我们的测试中，使用两个临时库比一个临时库，系统吞吐量增加了至少30%。我们注意到在只有一个tempdb 时，如果系统中的用户数超过某个数，系统的吞吐量就开始下降。在增加一个临时库以后，对系统目录和日志的争用显著降低，直接导致系统吞吐量的增加。

Tempdb的写优化

临时库是不可恢复的。（在启动时，ASE会删除临时库并重建。）ASE利用了这一特征来避免从缓存中写入数据或日志到磁盘，而这正是一般数据库必须做的。

举例来说，如果一个用户做了如下的操作：

Select * into tempdb..temp_table from foo

那么ASE就会在事务结束时清空新建临时表所缓存的数据。这是因为select into是一个不纪录日志的操作，为了保证可恢复性，我们就需要保证数据被写入磁盘。对一般数据库来说，这是对的；但是由于临时库是不可恢复的，ASE 12.5.0.3就会避免在操作结束时把缓存中的数据写入磁盘。

对一些DML操作比如insert/update/delete ASE并不强制在提交操作时写日志。举例来说，如果用户进行了以下操作：

Insert into tempdb..temp_table select * from foo

那么ASE就不会强制在提交操作时写日志。这就意味着更少的上下文变换，日志纪录和数据设备的负担更轻，最终增加系统吞吐量。在我们的内部测试中，我们看到过高达50%的写操作减少。

结论

为了在关键任务环境中给客户提升价值，Sybase提供了很多特性，ASE 12.5.0.3提供的多临时库支持功能强大，保证了更大的吞吐量。ASE 12.5.1所做的完善为配置管理这一特性提供了更好的灵活性。这份白皮书向DBA们展示了怎样在不改变应用的情形下，通过配置系统来更好地利用资源。 Sybase相信跟花钱购买这一特性比较起来，特性本身所带来的企业成本降低是显著的。