第一步, 在收缩前先查看日志的大小:
SELECT *
from sysfiles
WHERE name LIKE ' % LOG %'
GO
第二步, 把数据库的恢复模式设成”简单”:
ALTER DATABASE 库名 SET RECOVERY SIMPLE
GO
第三步, 运行checkpoint指令, 把dirty page写进数据库:
CHECKPOINT
GO
第四步, 截断日志:
BACKUP LOG 库名 WITH NO_LOG
GO
第五步, 记录一下日志名为下一步做准备:
SELECT Name
from sysfiles
WHERE name LIKE ' % LOG'
GO
第六步, 收缩日志文件, 把不用的空间释放给操作系统:
DBCC SHRINKFILE (文件名, 所需大小)
GO
第七步, 验证一下日志大小是否达到所需大小了:
SELECT *
from sysfiles
WHERE name LIKE ' % LOG % '
GO
后续步骤:
1)查看你的主要数据库, 看看日志增长是否失控;
2)查看上面的代码, 并进行必要修改和测试以适应你的数据库要求;
3)定期收缩数据库 ----(注: 慎用!! 不建议用在production环境里.)
4)继续监控数据库大小和服务器上的可用空间大小. ......
本文演示了 SQL Server 2008 分区表实例;
1. 创建测试数据库 ；
2. 创建分区函数;
3. 创建分区架构;
4. 创建分区表;
5. 创建分区索引 ;
6. 分区切换 ;
7. 查询哪些表使用了分区表；
-- 作成者 leno
-- 日期: 2009-06-06 23:50:01.700
-- 创建测试数据库
USE master
GO
IF OBJECT_ID(N'PartitionDataDB') IS NOT NULL
DROP DATABASE PartitionDataDB
GO
CREATE DATABASE PartitionDataDB
ON PRIMARY
(
NAME = N'File_A_H',
FILENAME ='D:\Microsoft\Microsoft SQL Server 2008\MSSQL10.MSSQLSERVER\MSSQL\DATA\PartitionDataDB_AH.mdf'
),
FILEGROUP FileGroup_I_N
(
NAME = N'File_I_N',
FILENAME ='D:\Microsoft\Microsoft SQL Server 2008\MSSQL10.MSSQLSERVER\MSSQL\DATA\PartitionDataDB_IN.mdf'
),
FILEGROUP FileGroup_M_Z
(
NAME = N'File_M_Z',
FILENAME ='D:\Microsoft\Microsoft SQL Server 2008\MSSQL10.MSSQLSERVER\MSSQL\DATA\PartitionDataDB_MZ.mdf'
)
GO
-- 创建分区函数
USE PartitionDataBase;
GO
CREATE PARTITION FUNCTION Staff ......
-- 示例一, 使用证书加密数据.
-- 建立测试数据表
CREATE TABLE tb(ID int IDENTITY (1,1),data varbinary (8000));
GO
-- 建立证书一, 该证书使用数据库主密钥来加密
CREATE CERTIFICATE Cert_Demo1
WITH
SUBJECT = N'cert1 encryption by database master key' ,
START_DATE = '2008-01-01' ,
EXPIRY_DATE = '2008-12-31'
GO
-- 建立证书二, 该证书使用密码来加密
CREATE CERTIFICATE Cert_Demo2
ENCRYPTION BY PASSWORD = 'liangCK.123'
WITH
SUBJECT = N'cert1 encrption by password' ,
START_DATE = '2008-01-01' ,
EXPIRY_DATE = '2008-12-31'
GO
-- 此时, 两个证书已经建立完, 现在可以用这两个证书来对数据加密
-- 在对表tb 做INSERT 时, 使用ENCRYPTBYCERT 加密
INSERT tb(data)
SELECT ENCRYPTBYCERT ( CERT_ID ( N'Cert_Demo1' ), N' 这是证书1 加密的内容-liangCK' ); -- 使用证书1 加密
INSERT tb(data)
SELECT ENCRYPTBYCERT ( CERT_ID ( N'Cert_Demo2' ), N' 这是证书2 加密的内容- ......
作中数据库经常出错死锁，并且还要要求解决当前的死锁，问题多多；
参照CSDN，中国风(Roy)一篇死锁文章并改进了下；
/***********************************************************************************************************************
整理人：黑木崖上的蜗牛(lenolotus) 日期:2009.04.28
************************************************************************************************************************/
/***********************************************************************************************************************
阻塞：其中一个事务阻塞，其它事务等待对方释放它们的锁,同时会导致死锁问题。 整理人：中国风(Roy) 参照Roy_88的博客
http://blog.csdn.net/roy_88/archive/2008/07/21/2682044.aspx
日期:2008.07.20
************************************************************************************************************************/
--生成测试表Ta
if not object_id('Ta') is null
drop table Ta
go
create table Ta(ID int Primary key,Col1 int,Col2 nvarchar(10))
insert Ta
......
下面提出了10条和DB2 SQL性能相关的10条因素：
1、提供适当的统计信息
对DB2优化管理器（otimizer）而言，如何更加有效的执行SQL语句是由存在于DB2 catalog中的统计信息决定的，优化器利用这些信息决定最优化的路径。
因此，为了保持系统能够做出最佳选择，需要经常的运行Runstats命令，来保持系统统计信息的及时有效。在工作负荷很大的生产环境中，经常运行Runstats是很必要的，为了减少进行统计对系统带来的影响，可以使用Sampling技术。
2、在SQL语句中尽量使用Stage 1的谓词
属于Stage 1的SQL谓词由Data Manager处理，而属于Stage 2的SQL由Relational Data Server执行。在处理效率上，Data Manager更有优势，因此，如果可能的话尽量把SQL语句写成能够在Stage 1执行的。如果能够结合Index来确定SQL语句中的谓词，那么将会更加提高SQL执行的效率。因此，在写SQL查询语句的时候，要结合Index的定义以及谓词描写的选择，尽可能的让SQL在Stage 1运行。
3、在SQL中仅选择需要的列
在SQL语句中，仅指定程序需要的列会有利于提高SQL运行的性能。如果采用Select *这种模式，将会给客户端的应用程序带来额外的处理工作，并需要更多的内存等资源。对服务器端而言，多余的列在� ......
今天做SQL 优化，查找执行计划时，执行计划，发现此执行计划与以往的计划有所区别；找录互联网，终于找一篇有关研究比较深入的文章；
原执行计划使用的是索引扫描，突然一下会使用索引覆盖技术，效率大增；
SELECT * 的真相：索引覆盖(index coverage)
SELECT *的效率很糟糕吗？当然，所有人都知道这一点，但是为什么呢？
是因为返回了太多的数据？
这是一个普遍的回答，但我不这样认为。如果你的数据库设计规范合理，那么带宽占用实际上非常的小。
让我们看看下面的例子。下面的查询将会从AdventureWorks.dbo.TransactionHistoryArchive（总共大约有近9万行数据）中选择出326行数据。第一个使用了SELECT * 查询，后一个查询则有明确的字段。
SELECT * from Production.TransactionHistoryArchive
WHERE ReferenceOrderID < 100
SELECT ReferenceOrderLineID from Production.TransactionHistoryArchive
WHERE ReferenceOrderID < 100
在这种情况下，两者在网络带宽的区别只有15K（180K-165K），大约10%的带宽差异。的确值得去优化，但不会有很大的效果。
SELECT * 将造成表/索引扫描
SELECT ......
最新文章 :