标签: sql-server

我正在实施一项新功能，该功能需要来自多台服务器上的数据库的数据。我只需要合并来自所有这些服务器的数据并对其进行排序。想到的两个选项是：

1. 使用链接服务器并编写一个简单的查询来合并和排序将从一台服务器运行并从其他服务器收集数据的数据。

2. 使用应用程序从所有服务器收集数据，并将其发送回 SQL Server 进行排序（不想在应用程序中实现排序）。

我们在 SQL Server 2008 r2 的主动/主动集群中运行我们的服务器。所有数据库都具有相同的权限，如果您有权访问一个数据库/服务器，则您对它们都有权限。这是一个面向公众的应用程序（需要用户登录）。

使用链接服务器有哪些风险？是否有任何我应该关注的安全漏洞？在主动/主动集群中运行链接服务器是否有任何问题？与替代方案相比，是否存在任何重大的性能问题？

关于链接服务器似乎有普遍的负面“嗡嗡声”，但我找不到任何具体的东西让我相信那里有任何真正的担忧。

我继承了一个中等规模的业务关键型 SQL Server 2008 数据库，并且正在尝试围绕备份计划进行思考。（我是开发人员，不是 DBA。）

我们的系统现在设置的方式有两个备份系统：

1. 每周完整备份 ( .bak) 和每小时事务日志 ( .trn) 备份。我们保留了多组这些备份，并定期将它们运往异地。
2. SQL Server 日志 ( .ldf)，恢复模式设置为Full. 此文件与主.mdf文件位于不同的驱动器上，但不会备份。

如果发生紧急恢复（或将备份恢复到开发机器），我的程序是使用这些.bak文件，然后应用 .trn 文件。我们有一个脚本可以使这个过程相对简单。

我的问题：

1. 是否可以从.ldf文件中恢复数据库？它到底是为了什么？
2. 拥有这两个事务日志是不必要的冗余吗？
3. 备份.ldf文件很重要吗？

我在这里和那里阅读了许多关于如何配置 tempdb 数据文件的博客，但我没有找到有关tempdb 日志文件的任何信息。

这是我目前在 tempdb 中使用的策略：

• 我已经使用了Paul Randal关于如何拆分我的 tempdb 数据文件的建议
• 我已将 tempdb 数据文件的大小设置为最大值并禁用自动增长。例如，我有 100gb 的可用磁盘空间并将我的 8 个 tempdb 数据文件的大小设置为每个 10gb。这可以防止Brent Ozar 推荐的磁盘碎片，而且我的日志文件还有 20gb 可用空间。

但就像我说的，没有人在谈论tempdb 日志文件。我该怎么办？在我的设置中，此文件与 tempdb 数据文件位于同一位置。我应该与 tempdb 日志文件一起使用的大小和自动增长值是多少？

我在单个专用服务器上运行 SQL Server 2008 和基于 Web 的应用程序，只有 2Gb 可用内存。

正如其他地方所指出的，SQL Server 经常占用多达 98% 的物理内存，这似乎会减慢服务器上运行的 Web 应用程序的速度。

在 SSMS 的服务器属性中，在内存下，最大服务器内存（以 Mb 为单位）设置为：2147483647

我的问题是，考虑到我可用的内存量，并且同一台服务器也在运行 Web 应用程序，建议放入最大服务器内存框的数量是多少？

此外，在 SQL Server 运行时更改此数字是否安全？

感谢您的意见。

我目前正在更新一个包含数百万条记录的表，已经 4 天了，查询仍在执行。

我检查了活动监视器，它显示查询正在运行。

在事件日志中根本没有错误。

性能明智：

• 磁盘 A 中的 Tempdb（850 GB 可用空间）
• 磁盘 B 中的数据库文件（750 GB 可用空间）
• 16 GB 内存

请建议我该怎么办？

查询

UPDATE
    dbo.table1
SET 
    costPercentage = ISNULL(t2.PaymentIndex, 1.0),
    t2.TopUp_Amt = (ISNULL(t2.PaymentIndex, 1.0) - 1.0)
    * ISNULL(dbo.table1.Initial_Tariff_Amt, 0.00),
    Total_Tariff_Inc_t2 = ISNULL(t2.PaymentIndex, 1.0)
    * ISNULL(dbo.table1.Initial_Tariff_Amt, 0.00)
FROM
    dbo.table2 t2
WHERE
    LEFT(dbo.test1.procodet, 3) = LEFT(t2.ProviderCode, 3) COLLATE database_default 

带有两个 1 Gbps NIC 的 Dell PowerEdge 2950 连接到交换机上的两个 1 Gbps 端口，然后连接到带有四个 1 Gbps NIC 的 NetApp，这些 1 Gbps NIC 作为一个虚拟接口出现。24 个驱动器、7200k SATA、NetApp RAID-DP。我已经使用 Microsoft iSCSI 启动器中的 MPIO 将每个主机 NIC 映射到 NetApp。使用 SQLIO 进行测试时，我的写入吞吐量在 200 MB 左右似乎合理，但我的读取接近 100 MB。

我的读取不应该像写入一样接近 200 MB 吗？这是配置问题还是我不​​明白的基本存储问题？

更新：这是随机工作负载的 IOPS。读取是有道理的，不过，我不确定写入的 20000 是什么。SAN 缓存为 3.2 GB。SQLIO 测试针对 25 GB 的文件。

我们有 SQL Server 2008 R2 合并复制设置。

最近我开始遇到一些表的冲突，当我检查冲突查看器时，我可以看到获胜者和失败者列的值是相同的！

我确信只有一位订阅者输入了这些数据。

我曾经sp_showrowreplicainfo获得有关冲突行的更多详细信息，我得到了 2 行：一个用于发布者，另一行用于订阅者，两行的“版本”均为 1。

我还实现了 Brandon 的方法：Auditing changes in Merge Replication，但它只显示正常插入！

你能告诉我如何开始解决这种冲突吗？

考虑以下查询：

MERGE [Parameter] with (rowlock) AS target
    USING (SELECT @AreaId, @ParameterTypeId, @Value)
            AS source (AreaId, ParameterTypeId, Value)
    ON (target.AreaId = source.AreaId AND 
        target.ParameterTypeId = source.ParameterTypeId)
    WHEN MATCHED THEN 
        UPDATE SET target.Value = source.Value, @UpdatedId = target.Id
    WHEN NOT MATCHED THEN
        INSERT ([AreaId], [ParameterTypeId], [Value])
        VALUES (source.AreaId, source.ParameterTypeId, source.Value);

统计 I/O 提供以下输出：

表“参数类型”。扫描计数 0，逻辑读取 2，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。
表 'Area'。扫描计数 0，逻辑读取 2，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。
表“参数”。扫描计数 1，逻辑读取 4，物理读取 0，预读读取 0，lob 逻辑读取 …

如果 VARBINARY 数据长度达到 2000，sys.fn_varbintohexstr 工作正常。如果大于 2000，函数 sys.fn_varbintohexstr 返回 NULL 作为结果。我缺少什么？

DECLARE @testvarbinary VARBINARY(MAX)
SELECT  @testvarbinary = 0xFFD8FFE000104A46494600010100000100010000FFDB004300090607080706090807080A0A090B0D160F0D0C0C0D1B14151016201D2222201D1F1F2428342C242631271F1F2D3D2D3135373A3A3A232B3F443F384334393A37FFDB0043010A0A0A0D0C0D1A0F0F1A37251F253737373737373737373737373737373737373737373737373737373737373737373737373737373737373737373737373737FFC0001108007E005C03012200021101031101FFC4001B00000301010101010000000000000000000405060302010007FFC4003A100002010302030407080103050000000001020300041105211231411322516106718191A1B1D11423324252C1E1F03315247243A2D2E2F1FFC4001801000301010000000000000000000000000102030004FFC4001F1100020202020301000000000000000000000102112131034104122251FFDA000C03010002110311003F0096D26DAD2EB4BBBC1646E364000186380727C39FC2A05B218827383E35AC17B728922C7348A24FC60311C5EBACD237918051B9341D195A307C96C64D36D27499EE5FF0777AB31D97D746E97A4A16E39003C232CCC365AABD3AC85C42643C50D9A1FC58EF48454E53E91451B02B2D3ECED8810C4D7328DCB636ACF51BD78BBA63B751FA55B71EEA677921951A2B45FB3DA2F7709F89CF866A7353B66B6004B1852DBAC406E079D4AECA7AD0BEF6E44B8DB881DB0798F6D130D8D9DC420714EAF8DF707E9418B476513721C54C6C1256DE37E3239A9FA1D8D35D681562CBCD1A54FF0019627A6DBE3D54B5A09A26C12411E35FA1C68AD082008F6EF2F41E04797974A5BA9E991CE1C6386451B8E7ED1E345727E81C3B44A6188C926B48D805DCD75240CAC4374D8D0ECC1588C8F7D6AB1927583388851DEF7535D1ED8C8C5C292C7650694440C9270AEFBE6ACF4B8858E9C6E1C0E23B463CFC69E6E9118AB633D3AC3ED320B356C229E295C7C7E9EDA6F74DDB4B1D9DB2948D06000390AE74E84E9FA2F6B201DBCC3888EBBF214D74DB0105AB4B311DAB6ECC7E35CECE840B1DB2C518729961DD894F8D21BBD225BEBB62F9E007BCDD5CFD2AB228CDC66729C2A470C6BE0BFCD3286C91635D86E36DB993D6A6DB2918D91EBE8D3ADAA86C14639DFA5663D1E303A48991C2D8C8E87A57E866D87095C023C3C4560F64ACAF19C77971F434136525049123358B346268D543755C6C1BA8F51FDE95DCDB2B2F0AF351C51127703A827C460FBAAD161CA14FD6A41F261492F20026E3E1C296E21EDC1FEFAEA8883FC3F3DD52139ED00DCECC078D4DC9FE47C83CFC6AFB5CB2E195C22F5181ECC8F854BC964B2396006FCF90ABC1A233BD03E8B6FDADD2AE3CD8F80AB4B5B7FB76A76F6ABFE187BCD8F01CFE9483D1C80C61A4DB8B9EFF0001EFAAFD11560866BACE4B37086F21FD149C92B6371AA563591BB7BD8D3AF1777D7E34F6FA2ED3B2B31B2FE7C780E7F1DA907A384DDEA6D70C3B918E5E7FFC154AF8E29253D7BA0F90E7F1A9B781D2C9922069046ABDDD89F2F01FDF1A38292CB9F1A5F1DC3DAAF69716B2AAB9CF1819029B5ACB14F1C6F1B060C720D4D659D4B11356D872359B3F7D49D803BD17819C30A1E60983D3D7B51780ED500CF188AE4961D5587CA94EA30A8561D158EDE40E7E54E2ECF1C711CE79C648E9E1F3A5D749DBBA2EF97183EBE1A7E8E56B24BEA9171C6CC17246304788FEFC6A52EED1A3B9902120139D9B156F703B4B7CE7018FCC72A437363DBC9C5B02060ED4F1744E684DA70ECEC95B18E3CB7B05502B18748894ECDC238BD6DBFC89A5420FB94893C900A6BA903C10460EEC4B7B3181F0A57B19690EBD17FB8D34CA7F14CE5BD9FD1F1A375BBD92C6D2111A34B2960AA396FD727D64579A7C417B0B755FF181CBCBF9A6325A25DC87B400AA8C2F5A4BAD958C6DE09DB9D6B5A8EE96DD96D431E1EE8E271B8EA718F0F953CB2BB3C28C53B321B0E80EC0E456ADA45A63F0AE7C45613F6513A45100006DF029A4E2F48A45495DBB1D5EDE2A22F06E481B679D25D46FB4F8A45935092490A8FC11F1103D82B4BC950CF0E3903C8D793E97DB44F1A4AE9139058039CEF9FAD2C527B0BBAC1B417F61A8E9F33E9EEA5232090A4F74AF4DFD62BE231340413857CE7CBFA687D1B4DFB0B4D0AE7B29179F0E370303E1F2AD94F02A679E7869A5558219BC89EE515219106E63908DCF81A4174F2097EEC1E1C550DEA94B9BB5D8F112DFBD20C01CCD61582411333478EB9738E9B81464FF0079A84791DD5C03EFFE2B98814310DB90F6EDFCFC2BCE2FF7AF93B81CEB3322A74C7096F2DCB6C48DA8FB07E241BD4E25D715AA42A4E589DBCB63FC53BD31F85064E71492C1D3C237108E1E291B6E805235B888EA0BC6705F2513C05357B81FAB7C50C91DBBB481CA90472CF5A08A340DAB5C5BFDB638EDD959970C573838EB4E218CAC48C84B46C32A7C296358C0854C78CE3761CCFB69ADADC048C28C70A8C628E0D4CE269993209DFA1A5CEE385C83B238F767F9AD354982AB303D29569F722EDAE946E1635EBD467FF5A2B289F2A4A99C5F3715E7AD37F76FF2A9B983472B29C839A757127FBD018EE57F73F5A597E02DC927F300DCBDFF001CD325673CB07CD91328076046287656ED1F6C96C8DBD75B4985556272437BB72298DA409D8971F9188FDEB4B6088B349B9692FE78A418ECC285F31CC9F88AABB1DDCA13B11B5405F3CB6DE91433440FDE479651F98787C2ABF4EBF8EE22574700FCAB4E25B8A411AB5BDD9938ADA72D1E30571B8A1218AE480639FB391464E485F9D39B56ED46

select datalength(@testvarbinary)

SELECT  sys.fn_varbintohexstr(@testvarbinary)

在考虑数据库性能时，VLF 有多重要？什么会描述 VLF 的最佳情况？