我们需要做一个恢复,不能因为其他用户连接。我们以为我们已经断开了每个进程,但显然没有。
我们如何从 Management Studio 启动其他所有人,以便我们进行备份?
使用 SQL Server 2008 及更高版本,我想向大表添加一个 rowversion 列,但是当我只是
ALTER TABLE [Tablename]
ADD Rowversion [Rowversion] NOT NULL
Run Code Online (Sandbox Code Playgroud)
然后该表无法更新太长时间。
我可以使用哪些策略来减少这种停机时间?我会考虑任何事情。当然越简单越好,但我会考虑任何策略。
我的想法是,作为最后的手段,我可以维护一个由触发器维护的副本临时表,然后将临时表 sp_rename 到原始表中。但我希望有更简单/更容易的东西。
我正在阅读Clustered和Non Clustered Indexes。
Clustered Index- 它包含数据页。这意味着完整的行信息将出现在聚集索引列中。
Non Clustered Index- 它仅包含聚集索引列(如果可用)或文件标识符 + 页码 + 页面中的总行数形式的行定位器信息。这意味着查询引擎必须采取额外的步骤来定位实际数据。
查询- 我如何借助实际示例来检查性能差异,因为我们知道该表只能有一个Clustered Index并且提供sortingatClustered Index Column和Non Clustered Index不提供sorting并且可以支持 999 Non Clustered IndexesinSQL Server 2008和 249 in SQL Server 2005。
我继承了一个包含数百个列的大型 (SQLServer) 数据库,这些列代表一件事或另一件事的数量。这些值的单位(例如“加仑”、“英寸”等)存储在扩展属性的 MS_Description 字段中。我想知道是否有更好的方法来存储这些信息。我认为用于文档目的很好,但很难根据这些数据进行可靠的单位换算计算。在这一点上,我不准备进行侵入性更改,但如果我有机会这样做,在这方面推荐的最佳实践是什么?在我的脑海中,选项可能包括:
更新:阅读@Todd Everett 的回答后,我想到了一个可能的解决方案,所以我将继续回答我自己的问题。(见下文)
正常的JOIN ... ON ...语法是众所周知的。但也可以将ON子句JOIN与其对应的分开放置。这在实践中很少见,在教程中找不到,我也没有找到任何网络资源甚至提到这是可能的。
这是一个可以玩的脚本:
SELECT *
INTO #widgets1
FROM (VALUES (1), (2), (3)) x(WidgetID)
SELECT *
INTO #widgets2
FROM (VALUES (1, 'SomeValue1'), (2, 'SomeValue2'), (3, 'SomeValue3')) x(WidgetID, SomeValue)
SELECT *
INTO #widgetProperties
FROM (VALUES
(1, 'a'), (1, 'b'),
(2, 'a'), (2, 'b'))
x(WidgetID, PropertyName)
--q1
SELECT w1.WidgetID, w2.SomeValue, wp.PropertyName
FROM #widgets1 w1
LEFT JOIN #widgets2 w2 ON w2.WidgetID = w1.WidgetID
LEFT JOIN #widgetProperties wp ON w2.WidgetID = wp.WidgetID AND wp.PropertyName = …Run Code Online (Sandbox Code Playgroud) 我有这张桌子:
CREATE TABLE [dbo].[Accounts] (
[AccountId] UNIQUEIDENTIFIER UNIQUE NOT NULL DEFAULT NEWID(),
-- WHATEVER other columns
);
GO
CREATE UNIQUE CLUSTERED INDEX [AccountsIndex]
ON [dbo].[Accounts]([AccountId] ASC);
GO
Run Code Online (Sandbox Code Playgroud)
这个查询:
DECLARE @result UNIQUEIDENTIFIER
SELECT @result = AccountId FROM Accounts WHERE AccountId='guid-here'
Run Code Online (Sandbox Code Playgroud)
使用由单个索引查找组成的查询计划执行 - 正如预期的那样:
SELECT <---- Clustered Index Seek
Run Code Online (Sandbox Code Playgroud)
此查询执行相同的操作:
DECLARE @result UNIQUEIDENTIFIER
SET @result = (SELECT AccountId FROM Accounts WHERE AccountId='guid-here')
Run Code Online (Sandbox Code Playgroud)
但它是按照一个计划执行的,其中索引查找的结果与一些常量扫描的结果左外连接,然后输入计算标量:
SELECT <--- Compute Scalar <--- Left Outer Join <--- Constant Scan
^
|------Clustered Index Seek
Run Code Online (Sandbox Code Playgroud)
什么是额外的魔法?常量扫描后跟左外连接有什么作用?
我一直在 AdventureWorks2012 数据库中挖掘并看到在几个表中使用的 Row_GUID。
我的问题有两个部分:
何时应该包含 Row_GUID 列?
Row_GUID 列的用途和好处是什么?
有人正在审查我用于创建表的 DDL 代码并建议,当他们看到我看到使用VARCHAR(256)文本字段时,我希望它非常小,比如名字或其他什么,我应该总是只使用VARCHAR(MAX)和链接为什么使用 varchar(max )。我读过它,但它似乎过时了,因为它专注于 2005 年,并且似乎没有提供任何真正的理由来在所有文本字段上每行分配最多 2 GB。
从性能、存储等角度来看,应该如何决定是使用VARCHAR(MAX)SQL Server 的现代版本还是使用更小更具体的类型?(例如,2008、2012、2014)
我刚刚建立了一个出版物,我正在尝试更快地应用快照。到目前为止,分发代理遵守MaxBCPThreads设置,但快照代理不遵守。我期望它拆分文件,以便分发代理上的线程会去获取数据。但是在我拍摄快照时似乎无法做到这一点。
我在网上看到的一些可能的解决方案在哪里更新代理配置文件(我最初只是用标志编辑了代理步骤,这适用于 dist 代理但不适用于快照)。
我尝试更新代理配置文件,但没有任何区别。我还发现有人说你应该将 sync_method 设置为native所以我检查了我的脚本,我已经创建了指定native模式的发布。
我想知道是否缺少MaxBCPThreads将所有 bcp 文件拆分为不同文件所需的特定设置。
我以为我已经解决了我自己的问题:看起来您必须有一个具有一组不同范围的聚集索引才能让 SQL Server 将文件拆分为多个分区。但是现在我的索引似乎在所有范围内都是 0。
DBCC SHOW_STATISTICS经过额外的测试,我发现这似乎只适用于复制表。如果您要基于(索引)视图进行复制,那么您似乎只能获得 1 bcp 文件,而不是从普通表中获得的分区内容。
问题是:为什么 SQL 复制不能像对普通表那样为索引视图分区 bcp 文件?
我正在复制没有表的索引视图本身(“索引视图作为表”)。原因是我必须加入数据库的识别信息供订阅者用于其他事情。到目前为止,我发现的唯一方法是使用 手动拆分我的视图BETWEEN,这不是特别有效。我希望我可以让 SQL Server 在复制普通表时做我期望的事情。
replication sql-server clustered-index index-tuning transactional-replication
我有一个包含 75 亿行和 5 个索引的大表。当我删除大约 1000 万行时,我注意到非聚集索引似乎增加了它们存储的页数。
我写了一个查询dm_db_partition_stats来报告页面中的差异(之后 - 之前):
索引1是聚集索引,索引2是主键。其他的都是非聚集的和非唯一的。
为什么那些非聚集索引上的页面会增加?
我预计这些数字在最坏的情况下会保持不变。
我确实看到性能计数器报告删除过程中页面拆分的增加。
删除时,ghost 记录是否必须移动到另一页?这与“唯一标识符”有关吗?
我们正在推出 RCSI,但现在,RCSI 已关闭。
它是可用性组中的主节点。我知道快照以某种方式在辅助节点上使用。如果这是相关的,我会感到惊讶。我打算深入研究这个(查看 dbcc 页面输出)以了解更多信息。希望有人看到过类似的东西。
sql-server ×10
alter-table ×1
datatypes ×1
index-tuning ×1
metadata ×1
performance ×1
replication ×1
t-sql ×1
uuid ×1
varchar ×1