SQL Server 2008 R2 中的跟踪标志 1605 是什么?到目前为止,我还没有找到关于它的任何文档。
Craig Efrein's questions
SQL Server 2016 企业版,CU15 + GDR。
客户端最近开始在生产中使用OPCON,我注意到当 OPCON 创建作业时,它不会将本地服务器添加为目标。这会阻止作业执行。
无论如何,是否可以确定特定作业是否没有像上述情况那样定义任何目标服务器?
谢谢,
克雷格
使用 Powershell 中的QueryTableXEventData类,我能够非常快速地解析 100 个 XEL 文件并使用SQLBulkCopy将它们的内容导出到 SQL Server 中的表
例子:
$events = new-object Microsoft.SqlServer.XEvent.Linq.QueryableXEventData
("\\some_file_path\XELog_Files*.xel")
我没有看到 $fields 数组中的 File 属性。
$event | Select-Object -ExpandProperty Fields
is_cached System.Boolean True
is_recovered System.Boolean False
is_dac System.Boolean False
database_id System.UInt32 73
packet_size System.UInt32 8000
options System.Byte[] {32, 0, 0, 40...}
options_text System.String
database_name System.String
或者在 $events
Name : login
UUID : 13e22e12-3cb8-49bf-a3e1-131faa95601c
Package : Microsoft.SqlServer.XEvent.Linq.Internal.XEventInteropPackage
Metadata : Microsoft.SqlServer.XEvent.Linq.Internal.XEventInteropEventMetadata
Timestamp : 18/08/2020 03:41:37 +00:00
Fields : {is_cached, is_recovered, is_dac, database_id...}
Actions : {server_instance_name, database_name, database_id, client_hostname...}
Location : Microsoft.SqlServer.XEvent.Linq.EventLocator
我可以在 SQLBulkCopy 或 QueryTableXEventData 中使用当前正在读取或导出文件名的属性吗?
SQL Server 2016 SP1 + CU8 安装在 Windows Server 2016 标准版上。
有一段时间一切都很好,我能够创建数据库,直到由于某种我不知道的原因,我安装的卷上弹出了权限问题。
Msg 5123, Level 16, State 1, Line 1
CREATE FILE encountered operating system error 5(Access is denied.)
while attempting to open or create the physical file
'D:\MSSQL13.MSSQLSERVER\MSSQL\Data\UserDB\test.mdf'.
Msg 1802, Level 16, State 4, Line 1
CREATE DATABASE failed. Some file names listed could not be created.
Check related errors.
文件夹 D:\MSSQL13.MSSQLSERVER\MSSQL\Data\UserDB 实际上是作为文件夹安装在 D:\MSSQL13.MSSQLSERVER\MSSQL\Data 目录中的卷。
我用谷歌搜索了几个小时,每个链接都在喋喋不休地谈论所有权和 icacls 以及控制权,但这不是这里的问题。我想明确一点,在这个实例上运行 SQL Server 的服务帐户可以完全控制这个挂载的卷以及它上面的内容。
我验证了服务帐户的有效访问权限,它已明确授予完全控制权。
我的怀疑是,它与授予作为卷而不是磁盘安装的文件夹的权限有关。这是因为在我的测试中,我可以在 D:\ 的根目录中创建一个包含其文件的数据库,而不会出现任何问题。D:\ 也是使用相同类型存储的卷。
此外,我自己的用户拥有完全控制权,但是当我尝试创建文件时,我收到此警告。
奇怪的是,我可以毫无困难地向 UserDB 文件夹/卷添加一个文件夹。
如何使这个卷作为 MSSQL 帐户可写的 D:\ 驱动器中的文件夹安装?
很长一段时间以来,我一直在使用sp_help_revlogin将服务器主体从一个 SQL 实例转移到另一个 SQL 实例。
是否有sp_help_revlogin等效项可以输出为部分包含的数据库用户创建脚本?我知道如果我备份/恢复包含的用户,但我需要将用户从一个包含的数据库部署到另一个不同的包含的数据库。
有没有人有一个 TSQL 脚本可以使用CREATE DATABASE FOR ATTACH语法自动生成附加所有现有用户数据库所需的代码?
例子:
CREATE DATABASE [mydatabase] ON
(FILENAME=N'E:\MSSQL\Data\mydatabase.mdf'),
(FILENAME=N'D:\MSSQL.1\MSSQL\Data\mydatabase_log.ldf'),
(FILENAME=N'E:\MSSQL\Data\mydatabase_ndf.ndf')
FOR ATTACH
我找到了许多使用 sp_attach_db 的示例,但没有一个使用 CREATE DATABASE FOR ATTACH 语法的示例。
谢谢,
克雷格
我昨天在 SQL Server 2016 SP1 企业版上创建第一个 memory_optimized 表时遇到了问题。
我这样创建了数据库和文件组
CREATE DATABASE imoltp -- Transact-SQL
CONTAINMENT = NONE
ON PRIMARY
(
NAME = N'imoltp',
FILENAME = N'F:\UNREFRESHED_DB\imoltp.mdf' ,
SIZE = 5120KB ,
FILEGROWTH = 1024KB
)
LOG ON
(
NAME = N'imoltp_log',
FILENAME = N'F:\UNREFRESHED_DB\imoltp_log.ldf' ,
SIZE = 2048KB , FILEGROWTH = 10%
)
GO
ALTER DATABASE imoltp ADD FILEGROUP [imoltp_mod]
CONTAINS MEMORY_OPTIMIZED_DATA;
ALTER DATABASE imoltp ADD FILE
(name = [imoltp_dir], filename= 'F:\UNREFRESHED_DB\imoltp_dir')
TO FILEGROUP imoltp_mod;
go
然后我创建了表
USE imoltp
GO
CREATE TABLE imoltp.[dbo].[T1] (
[TempID] INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT=1000000),
[object_ids] NVARCHAR(255) NOT NULL,
[names] NVARCHAR(255) NOT NULL,
[comment] NVARCHAR(50)
) WITH (MEMORY_OPTIMIZED=ON, DURABILITY = SCHEMA_ONLY);
GO
导致此错误:
Msg 41334, Level 16, State 0, Line 8 无法正确创建或设置代码生成目录。
我终于发现 SQL 试图在服务器属性中定义的默认数据库位置创建一个目录 (XTP),在这种情况下不再存在。这个目录是它想要存储内存中需要的 dll 文件的地方。
https://blogs.msdn.microsoft.com/bobsql/2016/08/23/create-table-disk-vs-in-memory-optimized/
所以我的问题是这样的。
有没有办法在 CREATE TABLE 语法或其他地方定义 XTP 目录的创建位置?
谢谢,克雷格
在 Ubuntu 14 上以主-主-从配置运行的 MySQL 5.5
从其中一位主人那里,当以在数据库上具有(所有特权)但在其他地方没有其他特权的用户身份执行下面的查询时,此查询返回 0
SELECT COUNT(1) SlaveThreadCount
FROM information_schema.processlist
WHERE user='system user'
当对所有内容执行与 root 相同的用户 IE(所有权限)时,我得到了真正的奴隶计数。
我返回 0 而不是真正的 SlaveThreadCount(在这种情况下为 2)有什么特别的原因吗?
这是特权问题吗?
如果我在非 root 用户中没有 WHERE 的情况下运行查询,我只会看到我的进程。
SELECT * FROM information_schema.processlist
如果我以 root 用户运行它,那么我会看到所有进程。
所以绝对是权限问题,所以看起来我需要 PROCESS,只是回答了我自己的问题。
我们最近将许多实例升级到 2016。因此,来自sqlpackage.exe的 SELECT 语句在某些实例上超时。
经过一些测试,我发现通过更新执行计划中显示的数据库系统表的统计信息,SELECT 停止了超时。
update statistics sys.[sysclsobjs] with fullscan
update statistics sys.[syscolpars] with fullscan
update statistics sys.[sysidxstats] with fullscan
update statistics sys.[sysiscols] with fullscan
update statistics sys.[sysobjvalues] with fullscan
无论如何,是否有通过标准维护包、Ola Hallengren 的脚本或其他一些过程来仅更新系统表统计信息?
更新 08/01
这是我升级后采取的步骤
关于 4199 跟踪标志KB974006
-- for the instance
/*
Turn on traceflag 4199 (my understanding of this traceflag is that it disables
optimizer hotfixes in 2016
*/
-- disable automatic numa
sp_configure 'automatic soft-NUMA disabled', 1
GO
-- For each database
-- Turn on Query optimizer hotfixes
-- Turn off Legacy cardinality estimation
exec sp_MSforeachDB 'ALTER DATABASE [?] SET COMPATIBILITY_LEVEL = 130;
USE [?];
ALTER DATABASE SCOPED CONFIGURATION SET QUERY_OPTIMIZER_HOTFIXES = ON;
ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION = OFF;
-- update statistics for all tables, system tables are ignored
EXEC sp_MSforeachtable ''UPDATE STATISTICS [?] WITH FULLSCAN''
'
更新 08/02
这是 sqlpackage.exe 中的 SELECT 导致 TFS 超时
SELECT * FROM (
SELECT
SCHEMA_NAME([o].[schema_id]) AS [SchemaName],
[si].[object_id] AS [ColumnSourceId],
[o].[name] AS [ColumnSourceName],
[o].[type] AS [ColumnSourceType],
[ic].[column_id] AS [ColumnId],
[c].[name] AS [ColumnName],
[si].[index_id] AS [IndexId],
[si].[name] AS [IndexName],
[ds].[type] AS [DataspaceType],
[ds].[data_space_id] AS [DataspaceId],
[ds].[name] AS [DataspaceName],
[si].[fill_factor] AS [FillFactor],
[si].[is_padded] AS [IsPadded],
[si].[is_disabled] AS [IsDisabled],
[si].[allow_page_locks] AS [DoAllowPageLocks],
[si].[allow_row_locks] AS [DoAllowRowLocks],
[sit].[cells_per_object] AS [CellsPerObject],
[sit].[bounding_box_xmin] AS [XMin],
[sit].[bounding_box_xmax] AS [XMax],
[sit].[bounding_box_ymin] AS [YMin],
[sit].[bounding_box_ymax] AS [YMax],
[sit].[level_1_grid] AS [Level1Grid],
[sit].[level_2_grid] AS [Level2Grid],
[sit].[level_3_grid] AS [Level3Grid],
[sit].[level_4_grid] AS [Level4Grid],
[sit].[tessellation_scheme] AS [TessellationScheme],
[s].[no_recompute] AS [NoRecomputeStatistics],
[p].[data_compression] AS [DataCompressionId],
CONVERT(bit, CASE WHEN [ti].[data_space_id] = [ds].[data_space_id] THEN 1 ELSE 0 END)
AS [EqualsParentDataSpace]
FROM
[sys].[spatial_indexes] AS [si] WITH (NOLOCK)
INNER JOIN [sys].[objects] AS [o] WITH (NOLOCK) ON [si].[object_id] = [o].[object_id]
INNER JOIN [sys].[spatial_index_tessellations] [sit] WITH (NOLOCK) ON [si].[object_id] = [sit].[object_id] AND [si].[index_id] = [sit].[index_id]
INNER JOIN [sys].[data_spaces] AS [ds] WITH (NOLOCK) ON [ds].[data_space_id] = [si].[data_space_id]
INNER JOIN [sys].[index_columns] AS [ic] WITH (NOLOCK) ON [si].[object_id] = [ic].[object_id] AND [si].[index_id] = [ic].[index_id]
INNER JOIN [sys].[columns] AS [c] WITH (NOLOCK) ON [si].[object_id] = [c].[object_id] AND [ic].[column_id] = [c].[column_id]
INNER JOIN [sys].[objects] AS [o2] WITH (NOLOCK) ON [o2].[parent_object_id] = [si].[object_id]
INNER JOIN [sys].[stats] AS [s] WITH (NOLOCK) ON [o2].[object_id] = [s].[object_id] AND [s].[name] = [si].[name]
INNER JOIN [sys].[partitions] AS [p] WITH (NOLOCK) ON [p].[object_id] = [o2].[object_id] AND [p].[partition_number] = 1
LEFT JOIN [sys].[indexes] AS [ti] WITH (NOLOCK) ON [o].[object_id] = [ti].[object_id]
LEFT JOIN [sys].[tables] AS [t] WITH (NOLOCK) ON [t].[object_id] = [si].[object_id]
WHERE [si].[is_hypothetical] = 0
AND [ti].[index_id] < 2
AND OBJECTPROPERTY([o].[object_id], N'IsSystemTable') = 0
AND ([t].[is_filetable] = 0 OR [t].[is_filetable] IS NULL)
AND ([o].[is_ms_shipped] = 0 AND NOT EXISTS (SELECT *
FROM [sys].[extended_properties]
WHERE [major_id] = [o].[object_id]
AND [minor_id] = 0
AND [class] = 1
AND [name] = N'microsoft_database_tools_support'
))
) AS [_results]
如果我不更新数据库的系统表统计信息,那么在通过 sqlpackage.exe 部署时,此 SELECT 可以并且将会超时
在带有 SQL Server 2014 Enterprise 的群集 Windows 2012 R2 服务器上。
刚刚将实例从 2014 SP1 CU4 升级到 2016 RTM,现在尝试启动 SQL Server 代理时出现此错误。
SQL 服务器代理日志
2016-06-06 11:53:58 - ? [100] Microsoft SQLServerAgent version 13.0.1601.5 (X64 unicode retail build) : Process ID 10884
2016-06-06 11:53:58 - ? [495] The SQL Server Agent startup service account is DOMAIN\USERNAME.
2016-06-06 11:54:28 - ! [150] SQL Server does not accept the connection (error: 65535). Waiting for Sql Server to allow connections. Operation attempted was: Verify Connection On Start.
2016-06-06 11:54:28 - ! [000] Unable to connect to server 'SERVERNAME\INSTANCENAME'; SQLServerAgent cannot start
2016-06-06 11:54:33 - ! [298] SQLServer Error: 65535, SQL Server Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF]. [SQLSTATE 08001]
2016-06-06 11:54:33 - ! [165] ODBC Error: 0, Login timeout expired [SQLSTATE HYT00]
2016-06-06 11:54:33 - ! [298] SQLServer Error: 65535, A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online. [SQLSTATE 08001]
2016-06-06 11:54:33 - ! [382] Logon to server 'SERVERNAME\INSTANCENAME' failed (DisableAgentXPs)
2016-06-06 11:54:33 - ? [098] SQLServerAgent terminated (normally)
Windows 应用程序日志
SQLServerAgent could not be started (reason: Unable to connect to server 'A08SQL-EDI\EDI'; SQLServerAgent cannot start).
代理启动并运行大约 30 秒,然后因上述错误而死。有人遇到这个问题吗?你知道如何解决它吗?
在具有足够 RAM 和快速磁盘的 SQL Server 2014 实例上,有超过 160 个用户可以访问数据库。由于某种我不知道的原因,DROP USER [username]
在这个数据库中运行命令每个用户最多需要 5 秒。
将用户重新映射到登录名并恢复他们的权限非常快。
在从生产中刷新 DEV 数据库的上下文中,我必须删除并重新创建所有数据库用户。所以是的,删除数据库用户并重新创建它们是必要的。
如何加快DROP USER
命令速度?
请记住,对于我正在写的实例,我必须运行它超过 160 次。
这是我正在使用的 SQL:
DECLARE drop_user_cur CURSOR FOR
SELECT name FROM #drop_users
OPEN drop_user_cur
FETCH NEXT FROM drop_user_cur INTO @user
WHILE @@FETCH_STATUS = 0
BEGIN
SET @sql = 'use [' + @db_name + '] DROP USER [' + @user + ']'
BEGIN TRY
print @sql
EXECUTE(@sql)
END TRY
BEGIN CATCH
print 'ERREUR : ' + @sql
END CATCH
FETCH NEXT FROM drop_user_cur INTO @user
END
CLOSE drop_user_cur
DEALLOCATE drop_user_cur
问题不是来自光标;这是实际DROP USER
最多需要 5 秒的时间。
使用sp_whoisactive
,wait_type 是NULL
。
不要注意持续时间,DROP
并且CREATE USER
正在WHILE
循环运行,这就是为什么它说超过一分钟的原因。
Profiler 显示要执行的读取超过 125,000 次DROP USER
。
未启用服务代理。
尝试从 Azure BLOB 还原小型备份
RESTORE DATABASE MY_DATABASE FROM URL = 'https://somelocation.blob.core.windows.net/mydatabase.bak'
WITH FILE=1
,MOVE N'MY_DATABASE'TO N'D:\DATA\MY_DATABASE.mdf'
,MOVE N'MY_DATABASE_log'TO N'D:\LOG\MY_DATABASE_log.ldf'
,NOUNLOAD, REPLACE, STATS = 2, CREDENTIAL = 'somecredential'
在大约 98% 的某个地方,恢复就死了
86 percent processed.
88 percent processed.
90 percent processed.
92 percent processed.
94 percent processed.
96 percent processed.
98 percent processed.
Msg 3013, Level 16, State 1, Line 8
RESTORE DATABASE is terminating abnormally.
这是带有跟踪标志的日志输出
2016-01-08 08:59:52.780 spid63 RestoreDatabase: Database MY_DATABASE
2016-01-08 08:59:52.790 spid63 Opening backup set
2016-01-08 08:59:52.790 spid63 VDI: "C:\Program Files\Microsoft SQL Server\MSSQL12.DATA\MSSQL\Binn\BackupToUrl.exe" "r" "p" "680074007400700073003A002F002F006B0039003900730074006F003000300032002E0062006C006F0062002E0063006F00720065002E00770069006E0064006F00770073002E006E00650074002F006B0030003100730071006C002D0063006C0075002D0032002F004C005F0043004100540041004C004F0047005F00430044004900530043004F0055004E0054005F004D004900440044004C00450043004D0053005F0032003000310036005F00300031005F00300033005F003000310030003300350038002E00620061006B00" "6B0039003900730074006F00300030003200" "01000000D08C9DDF0115D1118C7A00C04FC297EB010000007D2AFDE19FCC3F4FBB113683EF29D7B5000000001200000061007A007500720065006B0065007900000003660000C000000010000000ED978F2ACEBB06BA73899E4D62DCEED10000000004800000A000000010000000FC5DAF946420975518E0336799E9FA2F48000000A5B7746C13945ABD05048D8CE67E8ACCF4A429616B12B1C1FBAA7B6C0AC4F8466F63644135D0C88F6DBA6D76BB18A550B81C15005FB538B4EA3C109B91549E3DE8872F460703247F14000000EE9427440D53CEEF53072D911D1CF92CA7BC1A2B" "NOFORMAT" "4C005F0043004100540041004C004F004700" "D:\DATA\SYSTEM\MSSQL12.DATA\MSSQL\Log" "DB" "54004500530054005F004D004900440044004C00450043004D005300" "NOTRACE"
2016-01-08 08:59:52.790 spid63 BackupToUrl process initiated with PID: 17796, for database name [MY_DATABASE]
2016-01-08 09:00:12.410 spid63 SetTargetRestoreAge: 0
2016-01-08 09:00:12.410 spid63 Restore: Configuration section loaded
2016-01-08 09:00:12.410 spid63 Restore: Backup set is open
2016-01-08 09:00:12.410 spid63 Restore: Planning begins
2016-01-08 09:00:12.440 spid63 Halting FullText crawls on database MY_DATABASE
2016-01-08 09:00:12.440 spid63 Dismounting FullText catalogs
2016-01-08 09:00:12.440 spid63 X-locking database: MY_DATABASE
2016-01-08 09:00:12.440 spid63 Restore: Planning complete
2016-01-08 09:00:12.450 spid63 Restore: BeginRestore (offline) on MY_DATABASE
2016-01-08 09:00:12.760 spid63 Restore: PreparingContainers
2016-01-08 09:00:14.210 spid63 Restore: Containers are ready
2016-01-08 09:00:14.210 spid63 Zeroing D:\DATA\MY_DATABASE_8.ldf from page 1 to 295800 (0x2000 to 0x906f0000)
2016-01-08 09:00:14.260 spid63 Restore: Restoring backup set
2016-01-08 09:00:14.260 spid63 Restore: Transferring data to MY_DATABASE
2016-01-08 09:01:14.370 spid63 Zeroing completed on D:\DATA\MY_DATABASE_8.ldf
2016-01-08 09:01:14.370 spid63 Zeroing D:\DATA\MY_DATABASE_log2.ldf from page 1 to 295800 (0x2000 to 0x906f0000)
2016-01-08 09:01:18.950 spid63 Restore: Waiting for log zero on MY_DATABASE
2016-01-08 09:02:16.370 spid63 Zeroing completed on D:\DATA\MY_DATABASE_log2.ldf
2016-01-08 09:02:16.370 spid63 Zeroing D:\DATA\MY_DATABASE_log3.ldf from page 1 to 295800 (0x2000 to 0x906f0000)
2016-01-08 09:03:15.440 spid63 Zeroing completed on D:\DATA\MY_DATABASE_log3.ldf
2016-01-08 09:03:15.440 spid63 Zeroing D:\DATA\MY_DATABASE_log4.ldf from page 1 to 295800 (0x2000 to 0x906f0000)
2016-01-08 09:04:13.620 spid63 Zeroing completed on D:\DATA\MY_DATABASE_log4.ldf
2016-01-08 09:04:13.620 spid63 Zeroing D:\DATA\MY_DATABASE_log5.ldf from page 1 to 244456 (0x2000 to 0x775d0000)
2016-01-08 09:05:06.270 spid63 Zeroing completed on D:\DATA\MY_DATABASE_log5.ldf
2016-01-08 09:05:06.270 spid63 FileHandleCache: 0 files opened. CacheSize: 14
2016-01-08 09:05:06.480 spid63 Resuming any halted fulltext crawls
如果备份成功完成,我会在全文爬网消息之后看到这一行
2016-01-08 08:53:38.720 spid63 Restore: Writing history records
2016-01-08 08:53:38.720 Backup Database was restored: Database: MY_DATABASE_log5, creation date(time): 2014/12/10(22:04:35), first LSN: 71976:92071:1, last LSN: 71976:100304:1, number of dump devices: 1, device information: (FILE=1, TYPE=URL: {'https://somelocation.blob.core.windows.net/MY_DATABASE_2016_01_08_010437.bak'}). Informational message. No user action required.
至于错误信息,我发现了这个
将数据库备份到磁盘或磁带或从磁盘或磁带还原数据库时出现错误消息:“3266”、“3013”
RESTORE VERIFYONLY 成功完成。
来自同一位置的其他数据库还原已成功完成。在服务器本地还原同一备份工作正常。由于超过 1000 个 VLF,需要永远恢复。
日志中的唯一信息是这个
使用 PID 启动的 BackupToUrl 进程:4632,数据库名称 [MY_DATABASE]
为什么恢复数据库失败而不是只恢复验证?
如果这是由下载时间非常慢引起的问题,是否会在某处出现超时错误?
我现在认为问题是由大量 VLF 引起的,并且会话可能仍然以某种方式依赖于与 Azure 的 blob 存储的连接。
从我们的 DEV 环境中的 SQL Server 2014 RTM,我正在使用 SQL 登录名执行此查询。
select t.noshipid, y.nofolder
from distantserver.distantdatabase.dbo.sometable t (nolock)
inner join somedatabase.dbo.sometable y (nolock)
on cast(t.nobill as bigint) = y.nobill
where t.type_payment = 'CE'
group by t.noshipid, y.nofolder
远程服务器在 2008 R2 中。
我返回一个错误
消息 8522,级别 16,状态 3,第 1 行 Microsoft 分布式事务处理协调器 (MS DTC) 已停止此事务。
如果我在 2008 R2 的生产服务器上执行相同的查询,则没有错误。
1:有问题的 SQL 登录具有必要的访问权限。
2:用于连接2008 R2服务器的provider是SQLNCLI10
问题:
1:是否有可能将DEV服务器升级到2014导致这些问题?
2:从 2014 到 2008 R2 使用四部分标识符是否有任何已知问题?
from distantserver.distantdatabase.dbo.sometable
而不是使用 openquery
FROM OPENQUERY([distantserver],
因为使用 OPENQUERY,查询不会返回错误。
3:是否有任何 sp_configure 选项或链接服务器选项我需要配置,因为 2014?
更新 14:41
如果我添加
BEGIN DISTRIBUTED TRANSACTION
在顶部,分布式部分工作正常。我只想强调一个事实,在升级之前,这不是必需的。
我有一个名为 @test_credentials 的工作,它运行以下查询
select * from openquery(SERVER2,
'select USER_NAME(),* from openquery(SERVER1,''SELECT USER_NAME() '')')
并将这些结果输出到文件中。
作业“@test_credentials”:第 1 步,“test_credentials”:开始执行 2015-08-31 17:53:45
来宾LinkedServerUser
(1 行受影响)
SERVER1
两者的链接服务器定义SERVER2
都使用 linkedserveruser 登录彼此(安全上下文选项)。- 两个链接服务器定义都使用相同的选项定义
- linkedserveruser 用户帐户存在于两台服务器上,并且无论如何都没有被禁用。
SERVER1
运行 AGENT 的服务帐户对于和都是相同的SERVER2
。
所以我的问题是:
为什么 SQL Server Agent 在执行此作业时以访客身份登录到 SERVER2?
执行以下查询后
select value, cast(value as float) float_value
from OPENQUERY([ORACLESERVER],
'select 3/5 as value from table')
我收到以下错误:
Msg 8114, Level 16, State 5, Line 1
Error converting data type nvarchar to float
.
我可以在具有相同 Windows 2012 R2 操作系统、相同 SQL Server 2008 R2 服务器和相同 Oracle 12.1.0 客户端版本的另一台服务器上运行相同的查询并返回正确的结果:
value float_value
.6 0,6
两台服务器上的链接服务器配置相同。
Oracle 服务器版本是
select * from OPENQUERY([ORACLESERVER],'SELECT * FROM V$VERSION')
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for HPUX: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 – Production
我在 SQL Server 和/或 Oracle 客户端中是否有任何其他可能导致这些问题的配置选项被忽略。
通过故障转移集群管理器,我最近向运行在 Windows Server 2012 R2 上的现有 SQL Server 2008 R2 集群添加了一个新磁盘。
尝试在此新存储上创建数据库时,出现以下错误:
Msg 5123, Level 16, State 1, Line 1
CREATE FILE encountered operating system error 5(failed to retrieve text for this error. Reason: 15105) while attempting to open or create the physical file 'J:\DATA\mydatabase.mdf'.
Msg 1802, Level 16, State 4, Line 1
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.
我可以手动添加一个文件到 J:\data
新存储可以在节点之间移动而不会出现任何错误
SQL Server 服务帐户对整个 J:\ 驱动器具有完全控制权
SQL Server 服务帐户完全控制 J:\DATA 这是驱动器的布局,您会注意到 DATA 是安装在 J:\ 中的独立卷
有人可以帮我弄清楚为什么会出现此错误吗?
更新
来自 James,如果我向数据添加一个子目录,则创建数据库命令有效
CREATE DATABASE [MCO_DB] ON PRIMARY
( NAME = N'MYDATABASE_DB', FILENAME = N'J:\DATA\MYDATABASE\MYDATABASE_DB.mdf' , SIZE = 3072KB , FILEGROWTH = 1024KB )
LOG ON
( NAME = N'MYDATABASE_DB_log', FILENAME = N'J:\TRN\MYDATABASE_DB_1.ldf' , SIZE = 1024KB , FILEGROWTH = 10%)
GO
我被要求确定存储过程的权限问题。此存储过程有两种可能的行为方式,具体取决于其参数使用的值。
exec ps_my_stored_procedure @a=1, @b=2, @c=3
处理方式与
exec ps_my_stored_procedure @a=5, @b=7, @c=0
您可以说这ps_my_stored_procedure
在逻辑上分为两个完全独立的过程。
使用dm_exec_procedure_stats
and dm_exec_query_stats
,我可以找到显示使用的存储过程的 SQL 的执行计划。但是,我无法恢复参数的定义方式和值。
是否可以使用dm_exec_procedure_stats
和dm_exec_query_stats
任何其他管理视图来重建显示用于其参数的值的存储过程的执行。
我真正想要的是在缓存中找到存储过程的实际执行,以便我可以按原样执行它EXECUTE AS LOGIN = 'someone'
来解决权限问题
我正在尝试从 SQL Server 2008 R2 故障转移群集中删除活动的唯一节点。
一切都检查完毕,然后我收到此错误
Final result: Failed: see details below
Exit code (Decimal): -568706566
Exit facility code: 1562
Exit error code: 14842
Exit message: Cannot create a file when that file already exists. (Exception from HRESULT: 0x800700B7)
Start time: 2015-05-30 16:09:38
End time: 2015-05-30 16:10:28
Requested action: RemoveNode
2015-05-30 18:47:12 Slp: Sco: Attempting to write hklm registry key SOFTWARE\Wow6432Node\Microsoft\MSSQLServer to file C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\20150530_184438\Registry_SOFTWARE_Wow6432Node_Microsoft_MSSQLServer.reg_
2015-05-30 18:47:13 Slp: Cannot create a file when that file already exists. (Exception from HRESULT: 0x800700B7)
2015-05-30 18:47:13 Slp: Watson bucket for exception based failure has been created
2015-05-30 16:10:24 Slp: Error: Action "Microsoft.SqlServer.Configuration.SetupExtension.ValidateFeatureSettingsAction" threw an exception during execution.
2015-05-30 16:10:24 Slp: Microsoft.SqlServer.Setup.Chainer.Workflow.ActionExecutionException: Cannot create a file when that file already exists. (Exception from HRESULT: 0x800700B7) ---> System.Runtime.InteropServices.COMException (0x800700B7): Cannot create a file when that file already exists. (Exception from HRESULT: 0x800700B7)
2
关于导致此错误的原因有什么想法吗?
我正在从生产数据库卷的快照中附加一个数据库。这些数据库将被匿名化,然后恢复到我们的 DEV 服务器。
这是我的附加声明:
CREATE DATABASE MY_DB ON
( FILENAME = N'H:\MY_DB.mdf' ),
( FILENAME = N'j:\MY_DB.ldf' ),
( FILENAME = N'i:\MY_DB.ndf' ),
( FILENAME = N'H:\MY_DB.mdf' ),
( FILENAME = N'i:\MY_DB.ndf' )
FOR ATTACH
GO
我收到此错误:
恢复数据库“MY_DB”时出错。无法连接到 Microsoft 分布式事务处理协调器 (MS DTC) 以检查事务的完成状态 (2:2141366340)。修复 MS DTC,然后再次运行恢复。
我有:
- 通过组件服务检查 MSDTC 中的安全性
- 重新启动 MSDTC
- 重新启动 MSSQL
- 从同一卷还原另一个数据库
谷歌搜索并没有太大帮助,我最担心的是不得不为这个数据库重新创建卷快照。如果我找不到替代解决方案,同一卷上还有 4 个其他卷也必须重做。
问题:有人知道如何解决上面的错误吗?
我正在研究删除 90% 的表数据的过程,因为测试只需要 10%。
我发现的最佳方法包括将 10% 的表行存储到临时表中。
当前方法
SELECT TOP 10 PERCENT *
INTO #temp_some_table
FROM some_table (nolock)
ORDER BY some_column DESC
TRUNCATE TABLE some_table
INSERT INTO some_table
SELECT *
FROM #temp_some_table
DROP TABLE #temp_some_table
此方法正在填满 tempdb 并导致磁盘也填满。
问题
有没有更有效的方法来删除表中 90% 的数据 ex ( DELETE TOP 90 PERCENT FROM sometable
)
或者
有没有办法使用批处理将 some_table 的 10% 的数据插入到临时表中?像这样的东西:
DECLARE @r INT;
WHILE @r > 0
BEGIN
BEGIN TRANSACTION;
INSERT INTO [dbo].[##temp_cds_Basket]
SELECT TOP 10 PERCENT *
FROM [dbo].[cds_basket] s
SET @r = @@ROWCOUNT;
print @r
COMMIT TRANSACTION
END
可能的解决方案
这个怎么样?
SET NOCOUNT ON;
DECLARE @r INT;
DECLARE @TenPercentDate datetime
with cte (some_column) as (
select top 10 percent some_column from some_table (nolock) order by some_column desc
)
select @TenPercentDate = min(some_column)
from cte
select @TenPercentDate
SET @r = 1;
WHILE @r > 0
BEGIN
BEGIN TRANSACTION;
DELETE TOP (10000) from
some_table
WHERE some_column < @TenPercentDate
SET @r = @@ROWCOUNT;
print @r
COMMIT TRANSACTION;
--CHECKPOINT; -- if simple
END
--rollback