标签: sql-server-2014

我是 SQL Server 新手，遇到问题。

我创建了一个数据库来在字段中存储日期nvarchar，但现在我需要将该字段转换为datetime. 我在互联网上搜索，找不到合适的解决方案。

我发现的一件事是创建一个新datetime列，将字符串值复制到该列，然后将新列重命名为原始列。

我的字符串值格式是21/11/2014. 我需要保持相同的格式。如果有人能给我一个可以做到这一点的 SQL Server 查询，我将非常感激。我正在使用 SQL Server Management Studio 2014。

我创建了一个默认数据库并在该数据库中创建了一些模式。为每个架构创建了用户，现在我只想为架构中的每个用户授予完全权限，我该怎么办？

我已经为 AD 组创建了登录名：

CREATE LOGIN [MYDOMAIN\Development Admins] FROM WINDOWS WITH DEFAULT_DATABASE=[master]

该 AD 组的成员之一是名为 DBGuy 的用户。如果执行，我可以看到该 AD 组中的 DBGuy 用户

xp_logininfo 'MYDOMAIN\Development Admins', 'members'

但如果我尝试使用 DBGuy 帐户登录，则会收到错误消息：

错误编号：18456
严重性：14
状态：1
行号：65536

在错误日志中我看到：

用户“MYDOMAIN\DBGuy”登录失败。原因：找不到与所提供的名称匹配的登录名。[客户端：192.168.50.127]

其他一些信息....

• 其他 AD 帐户似乎可以很好地作为 Windows 登录，我只是对这个组有问题。
• 我发现 Aaron Bertrand 的一篇文章描述了有关连接中默认数据库的类似问题 - 我已在连接设置中将默认数据库设置为master 。
• 一篇博客文章建议使用它exec sp_change_users_login Report来寻找孤立用户；这为我返回零行。

在最后一天左右的时间里，我一直在为这个问题摸不着头脑——我只是不明白为什么一个过程在一种环境中有效，但由于转换错误（相同的数据，相同的代码）而在另一种环境中失败。

工作服务器的计划（大幅削减版本）位于： https: //www.brentozar.com/pastetheplan/ ?id=B1jZWTfOf

（这似乎不起作用，所以我已将计划 XML 上传到此处的 Pastebin： https: //pastebin.com/47Q6nniw）

导致问题的相关列的一些背景知识：

propertyInst 表包含一个名为 ValueStr 的列，它是 nvarchar 数据类型。GeneralLedgerCode 表具有数据类型 int 的列 id。我们的开发人员正在尝试连接两个表。ValueStr 列保存文本数据、XML 数据、整数数据、小数数据等。当然，我们决定添加一个函数来确保仅解析整数 (ISNUMERIC(ValueStr) = 1）。我们没有意识到的是，这也会尝试转换任何十进制值 - 这会导致自然生产中的转换错误：

将 nvarchar 值“0.1”转换为数据类型 int 时转换失败。

我的问题是，鉴于 propertyInst 表的表扫描将拾取包括小数在内的所有数值，为什么标量运算符中的隐式转换不会因相同的转换错误而失败？ISNUMERIC 查询的输出返回其中一些小数。我根本看不出所附计划是如何运作的。

隐式转换运算符是否永远不会彻底失败，转换错误是否来自哈希匹配运算符中的探测残差？话又说回来，当隐式转换失败时，该值如何能够到达运算符呢？

作为一个小帮助，计划图像在这里，我要询问的计算标量被圈起来。

此外，我可以看到没有针对标量运算符记录的实际行 - 这是否意味着引擎由于转换错误而决定在运行时不使用该特定运算符？

任何帮助，将不胜感激。

鉴于以下脚本，我可以看到隐式转换和数据类型优先级对查询计划有负面影响

-- create objects
CREATE DATABASE ConvertTest
GO

USE ConvertTest
GO

CREATE TABLE Person
(
    VarcharId   NVARCHAR(4),
    IntId       INT 
)

-- insert data
INSERT INTO Person
SELECT  TOP 1000
        CONVERT(NVARCHAR(4),ROW_NUMBER() OVER (ORDER BY a.object_id)),
        ROW_NUMBER() OVER (ORDER BY a.object_id)
FROM    sys.objects a
        CROSS JOIN sys.objects b

-- create indexes
CREATE INDEX IX_Varchar ON Person
(
    VarcharId,
    IntId   
)

CREATE INDEX IX_Int ON Person
(
    IntId,
    VarcharId
)

DECLARE @id NVARCHAR(4) = 100
-- statement 1
SELECT * FROM …

在 T-Sql 中，用户有一个默认架构。是否有类似于 postgres search_path 的模式搜索路径概念？

问题背后的问题是，如果我使用模式作为对象的命名空间，这是否意味着在所有代码中使用限定名称？

作为 Microsoft SQL Server 2014 上的一三个一般问题，也许我应该已经知道答案，或者甚至可能曾经知道 -

当我的存储过程运行其他存储过程时，如何找出哪个存储过程的代码产生了错误？

是否有一种特殊的方法来处理来自 Transact-SQL 的错误，以标识给定存储过程中的错误位置？

存储过程中的程序代码能否获得它所在过程的名称？

如果这是唯一的方法，我准备将“SET @MyNameIs = N'HastilyWrittenProcedure”放入程序代码中。然后我可以输入“PRINT @MyNameIs + 'break.'。" 在所有的错误处理程序中。

我正在运行 SQL Server 2014

我有一个看起来像这样的表：

 ID   | Name | AddressType | Address       | Features
 ========================================================
 1    | Bob  | Home        | 123 Nope St   | JP 
 2    | John | Work        | 555 Fake St   | MNGF 
 2    | John | Home        | 654 Madeup Ln | IMP JP 
 3    | Kim  | Work        | 92 Nadda Blvd | MP 

我正在尝试编写一个 SQL Server 查询来查找重复的 ID，并始终返回包含“工作”地址的行，但我希望它将两行中的功能连接起来，以便得到如下所示的结果：

 ID   | Name | AddressType | Address       | Features
 ========================================================
 1    | Bob  | Home …

我们正在尝试解决其中一个应用程序的连接问题，该应用程序试图从防火墙后面非常安全的 SQL 服务器提取数据。我不是安全方面的专业知识，但需要有关如何继续打开该应用程序的端口以从安全域后面的 SQL Server 提取数据的帮助。

我们\xe2\x80\x99已经打开了sql server正在侦听的端口，比如说12345，但仍然没有运气。

我如何知道可能需要打开哪些其他端口（例如 udp 1434 默认 1433 或镜像（例如 5022））？我们有什么办法可以找到这些信息吗？

我正在努力寻找将一些“varchar”列迁移到“nvarchar”的最佳方法。我使用的选项之一是添加新的 nvarchar 列，然后更新原始列中的值，删除原始列并将新列重命名为旧名称。

我知道它会生成大量的UNDO和REDO数据。不过，我还有其他限制（主要是 SQL Server 不支持并行 DDL 和多列 ALTER 表操作），因此让我们关注如何更快地运行更新语句。

我的 Oracle 经验告诉我使用内部并行性，但是它在 SQL Server 中可用吗？

尽管我特意将该表创建为堆表（无聚集索引），但我无法并行运行此语句。

update t
set new_col_1 = col_1
   ,new_col_2 = col_2
   ...
   , new_col_N = col_N
;

有 3 个文本列可容纳 400GB 数据。AWS RDS 的 IO 性能有限（10000 IOPS）。我们只有 4 小时的停机时间。

在此特定迁移中，不能选择在线重建，因为必须先将数据迁移（到 nvarchar），然后才能启动应用程序。在启动期间，它会检查实际数据类型是否与定义的数据类型（在应用程序元数据存储库中）相对应。

我知道碎片化，但我们别无选择。不过，如果有一些在线重建命令，它可能会很有用，因为我们稍后将能够进行迁移和碎片整理。实际上，作为准备步骤之一，我们正在删除聚集索引。稍后将再次创建该索引，我相信这将解决碎片问题，因为我们将从堆转移到 b*tree 结构。

令人非常沮丧的是我们无法使用任何其他“并行”技术。我正在考虑尝试手动并行更新，通过针对目标表的不重叠范围运行一些并行更新语句。尽管如此，锁升级可能是下一个问题，因为我将在每个更新中更新数百万条记录，并且很可能 SQL Server 将尝试升级到表锁，这将锁定其他更新，并且死机锁定将是最终结果..