小服务内存与最大服务内存。在实际工作中，我们往往有两种配置方法。

　　一是配置一个最大最小内存。即给SQL Server数据库应用服务设置一个最大的使用内存。如此的话，在这个最大的范围之后，数据库系统会根据实际情况，在最大内存范围之内对内存的分配进行调整。一般情况下，最小内存我们可以不设置，只对最大内存进行限制即可。这就给数据库一种自主选择的权利。可以提高内存的使用效率。

    二是固定内存分配。即把“最小服务内存”与“最大服务内存”两个参数设置为相同。如此的话，不管数据库服务需要多大的内存，在服务器启动的时候，操作系统都会给其预留这么大的内存。其他的应用程序及时内存再怎么不足，也不会跨越数据库的内存领地。很明显，这种方式虽然保证了数据库服务的内存需求，但是，内存的使用率并不是很高。

　　针对上面两种方法，笔者比较倾向与使用第一种配置，即只对数据库应用服务的最大内存使用率进行限制。只要不超过这个范围，则服务器可以自主的进行调解。那么这个最大的使用率设置成多少合适呢?这主要要看企业所部属的服务了。由于这家企业，在同一台服务器上运行了邮箱服务器与数据库服务器，可能对硬件的压力比较大。因为这两个应用服务，都涉及到比较多的并发访问。所以，即使把硬件升级成了2G，估计也不能够给数据库服务分配比较多的内存。一般来说，并发性访问越多，则最好能够给其配置比较多的内存。

　　配置完成之后，不用重新启动，这个规则就会起效。不过笔者还是建议把SQL Server服务重新启动一下。在可以的情况下，把服务器重新启动一下最好。如此的话，操作系统就会根据这个规则，对内存进行重新的调整分配。也可以让SQL Server服务器更好的队内存进行合理的安排。如可以把SQL Serve可用内存固定在一个连续的区域内，以提高数据库的性能。
　　　三、总结。
　　针对这个内存升级后所产生的烦恼，笔者有几句话说。

　　一是硬件升级只是数据库服务器性能提升的一个充分条件，而不是必要条件。也就是说，硬件的升级并不一定会导致服务器性能的提升。在硬件升级的同时，往往也需要调整相关的配置。让硬件升级的优势得到极大的发挥。笔者认为，有时候服务配置比纯粹的硬件升级更加重要。一些经验不足的网络管理人员只知道升级硬件，而忽视了服务的调整配置。他们这是走进了一个死胡同，效果往往不能够达到他们的预期。
在实际开发中，经常会需要对数据库进行访问，最常见的开发方法就类似：

string sql = "select * from table1 where name = '" + name + "'";

这种方式有被注入攻击的危险（什么是注入，搜索一下吧，太多了）

所以解决方案有2种：

1、改成：string sql = "select * from table1 where name = '" + name.Replace("'","''") + "'"; // 替换一个单引号为两个单引号

2、使用参数化形式，如在Oracle中，用如下方式执行：

string sql = "select * from table1 where name = :vName";

OracleParameter para = new OracleParameter("vName", OracleType.VarChar);

para.Value = name;

OracleConnection con = new OracleConnection (constr);

con.Open();

OracleCommand com = con.CreateCommand();

com.CommandText = sql;

com.Parameters.Add(para);

com.ExecuteReader();

如此看来，使用参数化的形式复杂的许多，用替换的方式简单的多

所以我一直以来都是用替换的方式来处理，昨天发现了用参数的另一个好处（源自：http://bbs.bc-cn.net/redirect.php?tid=242233&goto=lastpost）

才知道，使用参数化形式还可以提高Oracle的性能（不知道SqlServer有没有类似的好处）

通过分析SQL语句的执行计划优化SQL
共享sql语句
为了不重复解析相同的SQL语句(因为解析操作比较费资源，会导致性能下降)，在第一次解析之后，ORACLE将SQL语句及解析后得到的执行计划存放在内存中。这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存可以被所有的数据库用户共享。因此，当你执行一个SQL语句(有时被称为一个游标)时，如果该语句和之前的执行过的某一语句完全相同，并且之前执行的该语句与其执行计划仍然在内存中存在，则ORACLE就不需要再进行分析，直接得到该语句的执行路径。ORACLE的这个功能大大地提高了SQL的执行性能并大大节省了内存的使用。使用这个功能的关键是将执行过的语句尽可能放到内存中，所以这要求有大的共享池(通过设置shared buffer pool参数值)和尽可能的使用绑定变量的方法执行SQL语句。
当你向ORACLE 提交一个SQL语句，ORACLE会首先在共享内存中查找是否有相同的语句。这里需要注明的是，ORACLE对两者采取的是一种严格匹配，要达成共享，SQL语句必须完全相同(包括空格,换行等)。

下面是判断SQL语句是否与共享内存中某一SQL相同的步骤：
1. 对所发出语句的文本串进行hashed。如果hash值与已在共享池中SQL语句的hash值相同，则进行第2步：
2.将所发出语句的文本串（包括大小写、空白和注释）与在第１步中识别的所有
已存在的SQL语句相比较。

例如：
SELECT * FROM emp WHERE empno = 1000;
和下列每一个都不同
SELECT * from emp WHERE empno = 1000;
SELECT * FROM EMP WHERE empno = 1000;
SELECT * FROM emp WHERE empno = 2000;
在上面的语句中列值都是直接SQL语句中的，今后我们将这类sql成为硬编码SQL
或字面值SQL
使用绑定变量的SQL语句中必须使用相同的名字的绑定变量(bind variables) ，

例如：
a. 该2个sql语句被认为相同
select pin , name from people where pin = :blk1.pin;
select pin , name from people where pin = :blk1.pin;
b. 该2个sql语句被认为不相同
select pin , name from people where pin = :blk1.ot_ind;
select pin , name from people where pin = :blk1.ov_ind;
今后我们将上面的这类语句称为绑定变量SQL。

3. 将所发出语句中涉及的对象与第２步中识别的已存在语句所涉及对象相比较。
例如:
如用户user1与用户user2下都有EMP表，则
用户user1发出的语句：SELECT * FROM EMP; 与
用户user2发出的语句：SELECT * FROM EMP;
被认为是不相同的语句，
因为两个语句中引用的EMP不是指同一个表。

4. 在SQL语句中使用的捆绑变量的捆绑类型必须一致。
如果语句与当前在共享池中的另一个语句是等同的话，Oracle并不对它进行语法分析。而直接执行该语句，提高了执行效率，因为语法分析比较耗费资源。
注意的是，从oracle 8i开始，新引入了一个CURSOR_SHARING参数，该参数的主要目的就是为了解决在编程过程中已大量使用的硬编码SQL问题。因为在实际开发中，很多程序人员为了提高开发速度，而采用类似下面的开发方法：
str_sql string;
int_empno int;
int_empno = 2000;
str_sql = ‘SELECT * FROM emp WHERE empno = ‘ + int_empno;
…………
int_empno = 1000;
str_sql = ‘SELECT * FROM emp WHERE empno = ‘ + int_empno;
上面的代码实际上使用了硬编码SQL，使我们不能使用共享SQL的功能，结果是数据库效率不高。但是从上面的2个语句来看，产生的硬编码SQL只是列值不同，其它部分都是相同的，如果仅仅因为列值不同而导致这2个语句不能共享是很可惜的，为了解决这个问题，引入了CURSOR_SHARING参数，使这类问题也可以使用共享SQL，从而使这样的开发也可以利用共享SQL功能。听起来不错，ORACLE真为用户着想，使用户在不改变代码的情况下还可以利用共享SQL的功能。真的如此吗？天上不会无缘无故的掉一个馅饼的，ORACLE对该参数的使用做了说明，建议在经过实际测试后再改该参数的值(缺省情况下，该参数的值为EXACT，语句完全一致才使用共享SQL)。因为有可能该变该值后，你的硬编码SQL是可以使用共享SQL了，但数据库的性能反而会下降。 我在实际应用中已经遇到这种情况。所以建议编写需要稳定运行程序的开发人员最好还是一开始就使用绑定变量的SQL。

　　二是一些并发性比较大的应用服务器，最好不要放在同一个服务器上。现在企业基于服务器、客户端模式的管理软件应用越来越多。这种模式一个显著的特点，就是并发性访问比较频繁，给应用服务器带来了很大的压力。在一些性能要求比较高的企业，它们把数据库与前台的应用程序服务器都分开放置，以求优化服务器的性能。而且，现在服务器价格已经逐渐能够被企业所接受。笔者认为，企业没有必要在这方面省钱。若多个应用服务并发性访问比较多的情况下，则最好考虑把他们部署在不同的服务器上。以提高各个应用服务的性能。

　　三是在同一个服务器上部署多个应用服务的话，要考虑应用服务的稳定性。因为像这家企业在同一个服务器上部署数据库与邮箱服务器，笔者并不是很赞同。因为邮箱服务器是一个比较容易遭受到攻击的服务器。垃圾邮件、病毒邮件等等都可能导致服务期运行不正常。把邮箱服务放在SQL Server数据库服务旁边，会降低数据库服务的稳定性。最好还是能够分开部署。