标签: sql-server

多年来，我们一直在使用事实上的标准 Ola Hallengrin 维护解决方案，即使在我们迁移到 Azure 并开始使用 blob 作为备份目标之后也是如此。但是，出于性能原因，我一直在研究通过块 blob 而不是页 blob 进行备份，利用具有共享访问签名而不是凭据的存储容器，并一次使用 4-8 个 URL 路径进行备份和恢复。结果非常清晰 - 未压缩备份的恢复性能为 30MB/s，压缩备份的恢复性能为 70MB/s，每个都有 1x URL。使用 4x URL，MAXTRANSFERSIZE = 4194304，& BLOCKSIZE = 65536，.. 131MB/s。使用 8x URL，245MB/s。备份也有类似的故事。

我写信是想看看是否有人知道继续利用 Ola 软件包的方法。似乎包中的 URL 支持结构适用于基于凭据的页面 blob，但没有任何用于 SAS 和条带化 URL 的逻辑。我从没想过这会有什么不同，但这是白天和黑夜。

我从这个文档开始并努力取得成功：https : //blogs.msdn.microsoft.com/sqlcat/2017/03/10/backing-up-a-vldb-to-azure-blob-storage/

下面的测试数据库在磁盘上大约为 85GB，始终压缩到 44GB。

BACKUP DATABASE [yeahokyeahok] TO  
 URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161.bak'  
,URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161_2.bak' 
,URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161_3.bak' 
,URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161_4.bak' 
--,URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161_5.bak' 
-- URL = N'https://az1yeahok01.blob.core.windows.net/adamtest01/yeahokyeahok_backup_2018_03_08_194161_6.bak'
WITH NOFORMAT, NOINIT,  NAME = N'yeahokyeahok-Full Database Backup', …

我有这个查询来迭代我的 SQL Server 上的所有数据库

DECLARE @DB_Name varchar(100) 
DECLARE @Command nvarchar(200)
DECLARE database_cursor CURSOR FOR 

SELECT name 
FROM MASTER.sys.sysdatabases

where name not in ('master','tempdb','model','msdb')

OPEN database_cursor

FETCH NEXT FROM database_cursor INTO @DB_Name

WHILE @@FETCH_STATUS = 0 
BEGIN 
     SELECT @Command = 'SELECT ' + '''' + @DB_Name + '''' + 'as DB_name, SF.filename, SF.size FROM sys.sysfiles SF'
     EXEC sp_executesql @Command

     FETCH NEXT FROM database_cursor INTO @DB_Name 
END

CLOSE database_cursor 
DEALLOCATE database_cursor

但是如何将结果全部存储在一张临时表中？

我们在我们的 SQL Server 环境中使用Ola Hallengren的SQL Server 备份解决方案。今天，有 2 个数据库处于SUSPECT模式，无法对它们进行备份。一项作业计划备份这些数据库（其中两个处于可疑模式）和另一个数据库。在线数据库的备份已完成，因为它是按字母顺序排列的第一个，对于其他两个，它失败了。但是，作业并没有失败，并且显示作业成功！如果该作业无法备份任何数据库，则该作业应该失败。

https://i.stack.imgur.com/n8Ww1.png

来自日志的消息：

Date and time: 2018-03-18 03:12:55
Database: [ABC]
Status: SUSPECT
Standby: No
Updateability: READ_WRITE
User access: MULTI_USER
Recovery model: FULL
Differential base LSN: 5334862000009909000054
Last log backup LSN: N/A

Date and time: 2018-03-18 03:12:55
Database: [CDE]
Status: SUSPECT
Standby: No
Updateability: READ_WRITE
User access: MULTI_USER
Recovery model: FULL
Differential base LSN: 4543119000022597000098
Last log backup LSN: N/A

Date and time: 2018-03-18 …

我正在使用 SQL Server 2016，我需要让用户MyDatabase执行xp_cmdshell. 我执行以下操作：

USE [MyDatabase]
GO

GRANT EXECUTE ON xp_cmdshell TO myUser
GO

myUser是一个用户MyDatabase，当我运行上面的代码时，登录为sa，我收到以下错误：

只有当当前数据库是 master 时，才能授予对服务器范围目录视图或系统存储过程或扩展存储过程的权限。

我需要将用户添加到master数据库吗？我不认为这是安全的。

我需要这个，因为我想从存储过程中编写一个文本文件。我找到了以下文章http://www.nigelrivett.net/WriteTextFile.html，说我可以使用以下方法编写文本文件：

You will need to create the data to be output as in dynamic sql statements
The first command here creates or overwrites the file - the rest append to the file.
exec master..xp_cmdshell 'echo hello > c:\file.txt'
exec master..xp_cmdshell 'echo appended data >> c:\file.txt'
exec master..xp_cmdshell …

SQL Server 2016 标准版

我们的数据库是 1TB 的 MDF，但该 MDF 中有 500GB 的可用空间。

当我们在辅助（日志传送目标）上进行还原时，MDF 会有 1TB 或 ~500GB 吗？

我可以直接从 SQL Server SP1 移动到 SP3 还是需要安装 SP2 然后转到 SP3。我被指派升级我的服务器 2014 只是为了确保我不会遇到问题

我有下表：

create table Order_Details
(
 ID int not null primary key
,Order_ID int
,Order_Description nvarchar(40)
)

我们在上表中插入了 27,500,000 行，当我在查询下面运行时，它需要 6-7 秒。

select ID,Order_ID, Order_Description 
from Order_Details
where Order_Description  like '%Football Size%'

我在Order_Description包含ID和应用了非聚集索引Order_ID。

还有其他方法可以优化查询并以更快的方式获得结果吗？

升级还是新建？有什么建议？有没有人有任何关于这个过程的陷阱或战争故事要分享？

我们在 Prod 中有一个 2012 实例，它同时具有 OLTP 和 OLAP 数据库。我们正在创建两个实例，一个专用于这些任务中的每一个。OLAP 实例是一个新版本，但是为了最大限度地减少最终用户停机时间，我们正在考虑升级将容纳 OLAP 数据库的实例。

我正在寻找超出我在 Microsoft 文档中阅读的内容的一般建议。

我有一个在 SQL Server 2017 Express 上运行的测试环境，它只使用最近的数据（一个作业每月一次删除超过三个月的数据）。

该作业执行以下操作：

1. 使用 while 循环，它删除了超过三个月的数据
2. 缩小数据库，如果其大小高于某个阈值
3. 重新索引所有表

这篇文章描述了由于索引碎片而缩小数据库是多么糟糕，以及为什么重新索引也需要额外的空间。

上次运行从 9GB 数据库开始。删除需要 3-4 分钟，重新索引大约需要 30 秒。数据库减少到大约 5GB。

由于这是一个测试环境，我可以承受这种停机时间而不会出现任何问题。

问题：在删除了很大一部分数据后收缩 + 重新索引是不是很糟糕？

我正在尝试创建一个 SQL 语句来在 SQL Server 中创建一个登录名和用户，这将允许 Web 应用程序对单个数据库执行 crud 操作，并允许完全访问所有表和存储过程、视图等。

我知道如何创建一个登录名和一个用户......但我作为继续的最佳方式离开了我的深度。

CREATE LOGIN [myUser] WITH PASSWORD=N'xxx', DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO

CREATE USER [myUser] FOR LOGIN [myUser] 
    WITH DEFAULT_SCHEMA = dbo;
GO