我已经将 CLR 用户定义函数用于非常特定的实例,例如复杂的字符串处理,但从维护的角度来看通常不喜欢它们(又是另一个隐藏代码的地方)。人们如何看待这种功能的优缺点,从性能和维护的角度来看,是否有关于何时使用它们的最佳实践指南?
目前,每当我编写一个添加可以包含空值的列的查询时,我都会将每个字段包装在isnullor 中coalesce,例如coalesce(score1,0) + coalesce(score2,0). 有没有更好的方法来处理这个问题,或者这是标准做法?
每天我都有一个会话产生 Avg.Disk Queue Length > 800(5 分钟间隔)。
我发现就在这之前 Sql Server 优化器犯了一个错误:它决定使用一个不合适的计划进行聚集索引扫描,这会产生大约 100Mb-1GB 的 IO 操作。假设我找到了排队的原因,但这不是全部。
恕我直言,巨大的 IO 不一定会冻结其他用户 15 分钟。虽然我不知道谁负责创建过多的异步 IO:Sql Server、Windows 文件系统,或者可能是物理 IO 控制器,但是产生的异步 IO 会导致一个巨大的异常队列,并且没有留下任何机会供其他会话从磁盘读取。
有没有办法控制异步IO?我想如果我能够降低队列长度(顺便说一句,“更真实的”当前队列长度计数器显示队列中有 400 个操作),那些查询计划的问题将不会冻结其他会话。
不过情况比较复杂:
更新:该表一点都不有趣,只是它对于 NAV 来说太大了(1 GB 带索引)。
一些查询的示例:
declare @p1 int set …Run Code Online (Sandbox Code Playgroud) 我在 SQL 服务器中有一个生产数据库,并希望在功能完成后进行最后的润色。在发货之前,我想确保我在 SQL Server 数据库中进行了一些清理并截断和缩小日志文件?
我可以运行夜间作业来截断日志和缩小文件吗?
这就是我到目前为止所拥有的: 我的恢复模型很简单
ALTER proc [dbo].[UTIL_ShrinkDB_TruncateLog] as
-- exec sp_helpfile BACKUP LOG PMIS WITH TRUNCATE_ONLY
DBCC 收缩文件 (PMIS, 1)
DBCC 收缩文件 (PMIS, 1)
从的TechNet给我的感觉,我要么必须明确地设置想要的填充因子或当我不指定它,默认的填充因子0 choosen。
对于我知道添加行的表,填充因子 0 不是一个好的选择。有没有办法重建索引,以便使用最后一个显式索引?
BTW:我认为这应该是默认设置。
应该索引多对多表吗?什么样的索引最好?
这是一个示例表:
CREATE TABLE user_role (
userId INT,
roleId INT
)
--edit: drachenstern - I added the table def based on the original comments, and assumed ints.
Run Code Online (Sandbox Code Playgroud) 我在一家新商店,以下错误开始在 2/22 反复出现,直到 3/7。
Event Type: Error
Event Source: SQLSERVERAGENT
Event Category: Alert Engine
Event ID: 318
Description:
Unable to read local eventlog (reason: The event log file is corrupted).
Event Type: Information
Event Source: SQLSERVERAGENT
Event Category: Alert Engine
Event ID: 311
Date: 2/22/2011
Time: 6:52:44 AM
User: N/A
Computer: XXXXXXX
Description:
Attempting to re-open the local eventlog...
Event Type: Warning
Event Source: SQLSERVERAGENT
Event Category: Alert Engine
Event ID: 312
Description:
Successfully re-opened the local eventlog - NOTE: …Run Code Online (Sandbox Code Playgroud) 看这个问题,似乎其他网站也有随着时间的推移增加列大小的问题。
仅增加表中列的大小是一项相当简单的任务。
但是,当您的商店遵守存储过程参数的长度必须与相应表列的长度相匹配的规则时,通过您的存储过程进行的大量更改就会下降。
锁定在 Oracle 显示,该过程不需要知道 varchar2 参数的长度。
当您将每个 varchar 参数声明为 varchar(max) 或 nvarchar(max) 时,其优缺点是什么?
显然,您可以忘记每次增加色谱柱尺寸时都必须调整程序的维护噩梦。
对 SQLRockStar 的回答: 我想保留一个相当保守的表设计,其中已知长度有限的字段根据当前限制建模,而不为将来可能的扩展保留。
我的许多表都包含一个 id int、一个代码 varchar(30) 和一个描述列 varchar(255)。
代码字段必须反映不同客户的本地命名约定。
一些客户需要将此字段增加到 50。
当我不将长度编码到程序参数中时,我只需要调整这个单一客户的表列。
当我坚持将长度编码到参数中时,那么我要么支持不同客户的不同版本的程序,要么我不得不更改并将更改推出给所有客户。
例子
-- SQL Server
Create Table dbo.SQLServerTable (
id int identity(1,1) primary key not null,
code varchar(30) not null,
description varchar(255) not null
);
go
Create Procedure WrapInsertSQLServer1 (
@code varchar(30),
@description varchar(255)
) as
INSERT INTO SQLServerTable values (@code, @description);
go
Create Procedure WrapInsertSQLServer2 (
@code …Run Code Online (Sandbox Code Playgroud) 我正在寻求帮助来编写此查询。我在下面包含了一些示例数据。我最初的前提是从第 13 行开始的所有值都是动态值,前 12 行是静态值。我知道我想用来计算每一行值的公式。
以下是我认为的 DDL
CREATE VIEW [v_AMP_C] AS
SELECT in.I_Date ,--Date
in.I_O_P ,--Money
in.I_O_H ,--Money
in.I_O_L ,--Money
in.I_C_O ,--Money
c.AMPS12_C --Money
FROM dbo.IC_Raw_In in
INNER JOIN dbo.AMPS12_C c ON in.I_Serial = c.i_serial
Run Code Online (Sandbox Code Playgroud)
并且通过dbo.IC_Raw_In在除 I_Date 之外的所有列上使用数据类型为 Money的大容量插入将数据导入到此表中。
然后当我运行这个查询时,SELECT * FROM v_AMP_C我得到了下面的输出
I_Date I_O_P I_O_H I_O_L I_C_O AMPS12_C
01/10/11 509.75 515 508 512.45 512.45
01/10/11 511.7 511.7 506.1499 506.5499 509.4999
01/10/11 507.1499 510.25 507.1499 510.25 509.7499
01/10/11 510 512.3499 509.2999 512.3499 510.3999
01/10/11 512.5 512.5 …Run Code Online (Sandbox Code Playgroud) 我们计划为 SQL Server 2005/2008 故障转移群集设置静态端口。关于为每个集群的 4 个节点选择/选择什么端口的任何指南?(主动/主动)我还认为一些应用程序需要了解静态端口。了解哪个应用程序设置为使用来自 SQL 实例的默认端口的最佳方法是什么?一般来说,在 sql server 故障转移群集上实现端口号更改的最佳方法是什么?