小编Aar*_*and的帖子

我的一位开发人员编写了一个类似于 VB.Net 函数 (LastIndexOf) 的 SQL 函数，并希望发布它。我的问题是将它放在中央数据库中而不是将它放在每个用户数据库中的原因是什么？

开发人员试图将它放在他的主数据库上的 sys 模式中，这样他就不必限定从用户数据库对它的调用......叹气

但我不确定将它（显然不是主数据库）与每个用户数据库集中起来的有效借口是什么？

我在 AlwaysOn 可用性组中设置了 2 个 SQL Server。

我还设置了针对数据库运行的作业。在故障转移期间，我如何确保作业将继续在辅助服务器上运行？我是否需要在两台机器上安装作业和 SSIS 包并在辅助机器上手动禁用它们...然后在故障转移的情况下手动启用它们？或者是否有内置功能来处理这个问题？

我想知道 SQL Server Management Studio Express（主要用于 Microsoft SQL Server）是否安装在独立机器上（没有任何 SQL 服务和东西）以连接到远程数据库？

我运行的是 SQL Server 2012；我的一位经理告诉我，他们希望我为指定用户创建一个 Web UI 来运行查询/更新数据库；这在我的 PHP 能力范围内；但我想为方便起见，我可以提议取消对 Web UI 的需求，因为这将花费我们的服务器管理员大量时间，但是在我们的网络机器上安装 SMSE 以连接/管理我们的数据库？

这可能吗？或者我是否必须经历创建一个显示模式、表格等的 WebUI 的痛苦任务。

我有一个大约 6Gb 的备份。它是原始文件的“轻量级”备份（清除了日志表），大约为 14Gb。

我尝试在我的 SQL Express 本地服务器上恢复备份。它失败并显示类似 : 的消息System.Data.SqlClient.Error: insufficient disk space。它要求 227,891,019,776 字节，这绝对是疯狂的，几乎和我的整个硬盘一样大。

正如在其他网站上发现的那样，我尝试了RESTORE FILELISTONLY FROM DISK = 'backupfile.bak'.

数据文件（列Size）的大小为 6,888,226,816，但日志文件的大小为 221,006,987,264。该列BackupSizeInBytes返回 6,259,736,576 和 0。

因此，如果我理解正确，则在继续之前，恢复检查我是否有足够的空间来恢复日志文件的“理论”大小，而忽略实际的日志文件大小？

我怎样才能绕过它？获得备份有点困难，所以如果我能在不返回生产服务器的情况下解决我的问题，那就太好了。

谢谢 ！

哦顺便说一句，我在 SQL Server 2008 R2 Express 上。

我有一张大表，表的行数超过30亿，这张表的数据空间大约是120GB。

和 Intel Xeon CPU E5645 @2.4GHz（2 个处理器），24 个 CPU，64G 内存，64 位 Windows Server 2008 R2 企业版。

我跑

create unique clustered index MyTable_IXC on tblFactFoo(barKey) on [PRIMARY]

但是用了6个多小时（实际上是6小时后报了duplicate key的错误）。

运行的时候cpu不到10%，磁盘IO不到20M/s，一般在15M/s左右，不知道这么强大的硬件如何提高创建聚簇索引的性能。

我已经将我的代码分类为“连贯块”，我可以一遍又一遍地将其插入到更长的“配置脚本”中，我正在使用的模式之一是：

CREATE TABLE #WidgetSetting 
(
    WidgetID bigint not null,
    Name nvarchar(100) not null,
    Value nvarchar(max) not null,
    CreateDate datetime not null
)

INSERT VALUES

MERGE TABLES

DROP TABLE #WidgetSetting

但是现在 SSMS 抱怨该对象在下次CREATE TABLE火灾时已经存在。是什么赋予了？

我认为很明显我将不得不在脚本的开头声明一次表，截断而不是删除，但很自然地，无法删除表并再次使用相同的名称。

我可以想到在计划缓存中存储估计计划而不是实际计划的决定背后的许多原因。但我找不到“正确”的答案。

当向表中插入少于大约 1,350,000 行时，大约需要 2 分钟，但是当插入的行数更大时，插入数据所需的时间会增加到大约 5 小时。

问题与查询或索引无关，因为长期以来一切正常，查询、表或索引的结构没有任何变化。

问题第一次出现在大约 2 周前，当插入的行数大于 +-1,350,000 时，它会在几天内重复出现。例如，一天插入的行数为 1,200,000，该过程需要 2 分钟，另一天的行数为 1,450,000，插入数据需要 5-6 小时。

我试图重建索引，但没有帮助。

我有一个问题，因为我一直在使用这个查询没有问题......直到现在：

UPDATE T1
SET ORDINAL = DATEDIFF(DAY, T2.Opening_Date, T1.Date)
FROM FactTransactions T1
INNER JOIN DimStore T2 ON T1.cod_store = T2.cod_storeKey

但现在它给了我一个错误：

从字符串转换日期和/或时间时转换失败

我不知道是怎么回事。以下是列：

Ordinal(numeric,null)
Opening_date(varchar, not null)
Date(varchar, not null)
cod_store(int,not null)
cod_storekey(PK,int, not null)

微软是否发布了下一个版本的路线图，确定了计划的发布日期？

如果没有，您认为在下一个版本准备好生产之前需要多长时间？