三、更改后的生效时间

　　全局变量或者局部变量更改后，什么时候生效呢?这又是数据库管理员需要关注的内容。在讲解这个知识点时，笔者还是需要强调一下，各位要关注全局变量与会话变量的差异。只有掌握这个差异之后，对于变量更改的生效时间才会有更加深刻的认识。

　　对于全局变量来说，通常情况下，任何访问全局变量的客户端都可以看见对全局变量的更改。当全局变量进行更改时，它只影响在更改后连接的从该全局变量初始化相应会话变量的客户端，而不会影响已经连接上的客户端的会话变量，即使是执行了Set语句来更改也是如此。这主要说明了两点。一是全局变量的更改，并不像其他系统一样，需要重启系统后才会生效。不重新启动数据库系统也会生效。二是对于当前已经连接的客户不会生效，而只会对更改后的新会话有效。为此如果要测试某个全局变量的更改是否生效，数据库管理员不需要重新启动服务器，只需要新建一个会话就可以进行测试。测试完成后，如果确定需要使用这个更改，也不需要重新启动服务器。只需要先关闭当前的所有会话，让用户重新建立会话即可。

　　与此类似，会话变量更改之后，也不需要重新启动服务器即可生效。不过会话变量又与全局变量不同，其只对自己的会话有效。这也就是说，会话变量更改之后，在当前会话中就会有效。

　　如果数据库管理员要同步全部的应用环境，如整个信息化应用采用相同的时间格式，在这种情况下，笔者建议采用全局变量，而不是会话变量。比较会话变量的作用域比较有限。

　　四、更改后的测试与备份

　　无论是全局变量还是会话变量，更改后都会有一个测试的过程。对于全局变量更改的测试，笔者建议先采用小范围内的测试。如更改了日期显示格式之后，为了测试其有效性，笔者建议数据库管理员先建立一个新的会话，然后查看更改是否生效。而不要先急着重置所有的会话。如此的话，万一更改失败或者不理想，因为不会影响到已连接的会话(只会对更改后的新会话起效)，就可以将不利影响控制在最小的范围之内。不过这么做还需要控制整个时间。如这个时间间隔拖了很长，如一天24个小时，此时就会出现问题。如财务部门是在更改之前就连结了，而采购部门有一个用户是在更改之后再连接的。此时两个不同的用户导出来的表格上，时间显示的格式就可能不同。这会造成一定的误导。可见，这个策略有利也有弊。数据库管理员，应该将这个测试的时间尽量缩短。如果测试的时间比较长的话，那么最好再搭建一台服务器进行测试，而不要在生产服务器上直接进行测试。

　　另外，对于更改后的配置，最好进行独立的备份。这里的备份并不是对数据库的整体备份，而是说对配置文件的备份。而且还需要做好详细的说明。如为什么要进行这个调整、调整的时间点是什么。

　　为了保持应用前后的一致性，这个调整的时间其实也有讲究的。一般情况下，不要在一个工作日的中间进行调整。如中午12点进行调整等等。如此的话，就会导致上午与下午的单据出现混乱。在某些特殊的应用中，可能对这个调整的时间会有更加严格的要求。如对于财务软件的后台数据库，则相关全局变量的调整，可能需要考虑到会计期间的问题。其只能够在月末或者年末进行调整。所以对某个全局变量进行调整时，因为会对全部用户产生影响，为此在更改之前，需要征求所有用户的意见。然后根据企业的实际情况与用户的要求，选择一个合适的调整时间。通常情况下，一个比较有经验的数据库管理员，会了解更改哪些全局变量会对最终用户产生影响，而哪些全局变量只是对系统维护有影响。然后就会根据需要更改变量的影响范围，去判断是否需要经过最终用户的确认。如果能够做出这样的判断，那是最好。可将将对用户的影响降低到最低程度。