今天在用SQL Server 2008执行一个SQL脚本文件时，老是出现引发类型为“System.OutOfMemoryException”的异常错误，脚本明明是从SQL Server 2008导出的，应该不会出错，研究了好久问题才得以解决。
出现这个错误的主要原因是由于SQL脚本文件太大，估计超过了100M了，解决方法就是把脚本文件分成几个脚本文件，分别去执行即可。
来自微软官方的解决方案：
原因：
因为计算机没有足够的内存来完成请求的操作，则会出现此问题。
在 SQL Server 2000 Reporting Services 的限制会导致内存绑定的处理报告的某些部分。例如，查询结果处理和对象模型呈现受限于内存。
计算机没有足够的内存来完成请求的操作在一个或多个下列条件都为真：
1.一个报告是太大或太复杂。
2.其他正在运行的进程的费用是非常高的。
3.计算机的物理内存是太小。
处理报表，则分两个阶段。两个阶段是执行和呈现。在执行阶段期间或在呈现阶段，会出现此问题。
如果在执行阶段中，会出现此问题，此问题很可能是因为太多的内存消耗在查询结果中返回的数据。此外，下列因素会影响内存消耗，在执行阶段：
1.分组
2.筛选
3.聚合
4.排序
5.自定义代码
如果在呈现阶段中会发生此问题，原因被与该报表显示何种信息以及报表显示信息的方式。
1.数量和类型的控件
2.这些控件之间的关系
3.格式设置
4.显示的数据量
解决方案：
若要解决此问题，请使用下列方法之一。
方法 1
向计算机中添加足够的物理内存。
注意如果您超过 2 千兆字节 (GB) 的内存可以启用该 / 3gb 切换在 Boot.ini 文件中为更好的性能。 有关如何在 SQL Server 中使用了 / 3gb 开关的详细信息单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
274750如何配置 SQL Server 使用 2 GB 以上物理内存
方法 2
将报告计划安排为在内存限制时较低的非高峰时段运行。
方法 3
调整所在进行相应设置。
注意:呈现时通过报告服务 Web 服务的报告，该报告服务 Web 服务从 Machine.config 文件中获得所在。但是，计划的报告呈现由报表服务器的 Windows 服务。报表服务器的 Windows 服务获取从 RSReportServer.config 文件的所在。
有关所在的详细信息，请参阅”更多信息”一节。
方法 4
升级到 64 位版本的 Microsoft SQL Server 2005年报告服务。
方法 5
重新设计该报表。若要执行此操作，请使用下列方法之一。
方法 A
重新设计报表查询。通过重新设计报表查询，通过以下方法，可以减少内存消耗：
1.报告查询中返回更少的数据。
2.在报告查询的 WHERE 子句中使用的一个更好的限制。
3.移动到数据源的复杂的聚合。
方法 B
将报表导出为其他格式。通过使用不同的格式来显示报表，您可以减少内存占用。下表列出了几个按顺序从大多数内存消耗到最低的内存消耗的导出格式。
复制代码 代码如下: 格式 说明
Microsoft Excel 呈现在 Excel 中的报表
(TIFF) 图像 将报表呈现为静态图像的面向页的格式
PDF 呈现报表采用可移植文档格式 (PDF)
HTML 呈现到浏览器在 HTML 报表
CSV 呈现报表以逗号分隔的格式 ；在与 CSV 文件格式关联的查看工具中打开报表
XML 呈现报表的 XML ；在浏览器中打开报表
注意:如果没有应用 XSLT 转换，这种格式将消耗比 CSV 格式所消耗的内存更少。
方法 C
简化报表设计。可以通过以下方式简化报表设计减少内存消耗：
1.在报告中包含更少的数据区域或控件。
2.钻取报表用于显示详细信息。
此外，如果报告的目的是只是数据的集合，可用于其他 Microsoft 产品更好的性能。例如，您可以使用数据转换服务 (DTS) 或 Microsoft SQL Server 2005年集成服务。
示例
下面的示例演示了如何解决此问题。请考虑下面的示例：
1.以 PDF 格式，并以 Excel 格式，无法呈现在报表管理器返回 160 页的报告。当使用 8.5 × 11 英寸页面尺寸时，报表可能远远超过 250 页。
2.报表的数据源返回报表服务器 500 兆字节 (MB) 的数据。通常情况下，SQL Server 2000年报表服务要求数据集所使用的内存量的两到三倍。因此，SQL Server 2000年报告服务需要几乎 1.5 GB 的内存来呈现该报表。
若要解决此问题，在此示例中，重新设计报表，以显示该报表仅为有限的一组筛选器值的汇总数据。此外，请确保聚合发生在报告数据中提取数据库查询和聚合中的报告本身不是。这些方法有助于大大减少到报表服务器返回的数据量。因此，成功地并更快地呈现报表。
