SqlServer删除重置日志文件大小

SET NOCOUNT ON
DECLARE @LogicalFileName sysname,
@MaxMinutes INT,
@NewSize INT

USE DCP_Test   — 要操作的数据库名
SELECT @LogicalFileName = ‘InforTransact20070308_log’, — 日志文件名
@MaxMinutes = 10, — Limit on time allowed to wrap log.
@NewSize = 20 — 你想设定的日志文件的大小(M)

— Setup / initialize
DECLARE @OriginalSize int
SELECT @OriginalSize = size
FROM sysfiles
WHERE name = @LogicalFileName
SELECT ‘Original Size of ‘ + db_name() + ‘ LOG is ‘ +
CONVERT(VARCHAR(30),@OriginalSize) + ‘ 8K pages or ‘ +
CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + ‘MB’
FROM sysfiles
WHERE name = @LogicalFileName
CREATE TABLE DummyTrans
(DummyColumn char (8000) not null)
DECLARE @Counter INT,
@StartTime DATETIME,
@TruncLog VARCHAR(255)
SELECT @StartTime = GETDATE(),
@TruncLog = ‘BACKUP LOG ‘ + db_name() + ‘ WITH TRUNCATE_ONLY’

DBCC SHRINKFILE (@LogicalFileName, @NewSize)
EXEC (@TruncLog)
— Wrap the log if necessary.
WHILE @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) — time has not expired
AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)
AND (@OriginalSize * 8 /1024) > @NewSize
BEGIN — Outer loop.
SELECT @Counter = 0
WHILE ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))
BEGIN — update
INSERT DummyTrans valueS (‘Fill Log’)
DELETE DummyTrans
SELECT @Counter = @Counter + 1
END
EXEC (@TruncLog)
END
SELECT ‘Final Size of ‘ + db_name() + ‘ LOG is ‘ +
CONVERT(VARCHAR(30),size) + ‘ 8K pages or ‘ +
CONVERT(VARCHAR(30),(size*8/1024)) + ‘MB’
FROM sysfiles
WHERE name = @LogicalFileName
DROP TABLE DummyTrans
SET NOCOUNT OFF

Sql字符串转成表

1.字符串形式:
Create FUNCTION [dbo].[StringToTableV2]
(@ids NVARCHAR (MAX), @separator CHAR (1))
RETURNS
@IdsTable TABLE (
[Id] NVARCHAR (MAX) NULL)
AS
BEGIN
IF (RIGHT(@ids,1)=@separator)
BEGIN
SET @ids=SUBSTRING(@ids,0,LEN(@ids));
END

Set @ids= ‘<root><items><item><![CDATA[‘ + REPLACE(@ids COLLATE CHINESE_PRC_BIN,@separator,’]]></item></items><items><item><![CDATA[‘)+’]]></item></items></root>’

DECLARE @xmlmode xml;
SET @xmlmode=CAST(@ids as xml);

INSERT INTO @IdsTable
SELECT T1.ids.value(‘item[1]’,'[nvarchar](max)’) as [Id]
FROM @xmlmode.nodes(‘/root/items’) T1(ids)

RETURN ;
END

2.int 2 table
ALTER FUNCTION [dbo].[Int32ToTable]
(@ids NVARCHAR (MAX), @separator CHAR (1))
RETURNS
@IdsTable TABLE (
[Id] INT NULL)
AS
BEGIN
IF (RIGHT(@ids,1)=@separator)
BEGIN
SET @ids=SUBSTRING(@ids,0,LEN(@ids));
END

Set @ids= ‘<ids><im id=”‘ + REPLACE(@ids,@separator,'” /><im id=”‘)+'”/></ids>’

DECLARE @xmlmode xml;
SET @xmlmode=CAST(@ids as xml);

INSERT INTO @IdsTable
SELECT T1.ids.value(‘@id’,’int’) as [Id]
FROM @xmlmode.nodes(‘/ids/im’) T1(ids)

RETURN ;
END

以上方法适合在Sql2005以上版本,
还有种方法:
create function func_splitstring
(@str nvarchar(max),@split varchar(10))
returns @t Table (c1 varchar(100))
as
begin
declare @i int
declare @s int
set @i=1
set @s=1
while(@i>0)
begin
set @i=charindex(@split,@str,@s)
if(@i>0)
begin
insert @t(c1) values(substring(@str,@s,@i-@s))
end
else begin
insert @t(c1) values(substring(@str,@s,len(@str)-@s+1))
end
set @s = @i + 1
end
return
end

将IIS日志导出到数据库

1:首先要下载Microsoft公司的LogParser工具

2:打开LogParser,输入logparser.exe “SELECT cs-Uri-Query  FROM ‘日志路径’ to iislog2(要插入的表,可以不新建) where index_of(cs-Uri-Query,’t=5′)=0 ” -i:IISW3C -o:SQL -oConnString:”Driver={SQL Server};Server=localhost;Database=库名;Trusted_Connection=yes;connection reset=false;connection lifetime=10;min pool size=100;max pool size=1000;Integrated Security=SSPI” -createtable:ON(自动创建表)

或者:Where [sc-status]=500 查询所有500错误的日志。

3:关于日期,IIS默认是UTC时间 ,导出时的转换可以这样:

SELECT TO_LOCALTIME(TO_TIMESTAMP(ADD(TO_STRING(date, 'yyyy-MM-dd '), TO_STRING(time, 'hh:mm:ss')),
'yyyy-MM-dd hh:mm:ss')) AS RequestTime, *  FROM table...

4. IIS日志中有一列:sc-win32-status ,它记录了在处理请求过程中,发生的系统级别错误,例如网络传输错误。
正常情况下,0 表示正常

比较常见的与网络相关的错误及解释:

scWin32Status含义

64客户端连接已关闭(或者断开)

121传输超时

1236本地网络中断
所有状态码都可以通过下面的命令来获取对应的解释:

D:\Temp>net helpmsg 64

指定的网络名不再可用。

如果你的网站的IIS日志中出现了大量的scStatus=200,scwin32status=64, 而且请求是由用户的浏览器发起的。
这是什么原因造成的呢?
我的【猜想】是:用户在访问这个网站时已经不愿意再等待了,他们把浏览器窗口关掉了。
换句话说:可以从scwin32status=64的统计结果看出网站的响应速度是否能让用户满意。

寻找性能问题的方法就是:在查询选择timeTaken字段,并且用它做降序排序。

注意:scbytes,csbytes 这二个字段也是值得我们关注的:
1. csbytes如果过大,我们就要分析一下到底是不是因为表单包含了过多的无用数据,可否将表单拆分。
csbytes变大还有一种可能:Cookie太大,但它会表现为很多请求的csbytes都偏大,因此容易区分。
2. scbytes如果过大,我们就要检查页面是否没有分页,或者可以考虑用按需加载的方式来实现。
典型的情况是:当大量使用ViewState时,这二个值都会变大。因此我们能通过IIS日志发现ViewState的滥用问题。
还有一种特殊情况是:上传下载文件也会导致这二个数值变大,原因我就不解释了。

scbytes,csbytes,不管是哪个数值很大,都会占用网络传输时间,对于用户来说,就需要更长的等待时间。

一下子说了三个字段,在寻找性能问题时,到底该参考哪个呢?
我认为:应该优先关注timeTaken,因为它的数值直接反映了用户的等待时间(不包括前端渲染时间)。
如果timeTaken过大时,有必要检查scbytes,csbytes是否也过大

当你在程序中大量使用frameset或者iframe时, 你将难以统计某个页面(包含iframe的页面)加载到底花了多长时间。 因为整个页面被分成了多个请求,它们在IIS日志中并不是连续的,你无法准确地按用户请求来统计。