小编Cra*_*ein的帖子

在 2014 年使用我的 AD 帐户通过凭据从 SQL Server 代理运行 powershell 脚本。我收到以下错误。

作业步骤在 PowerShell 脚本的第 1 行收到错误。相应的行是“set-executionpolicy RemoteSigned -scope process -Force”。更正脚本并重新安排作业。PowerShell 返回的错误信息是：'Security error.

我在谷歌上搜索，没有发现任何有用的东西。我可以在我的工作站上通过 SSMS 从 Powershell 控制台运行脚本，没有任何问题。

执行策略设置为不受限制

PS C:\WINDOWS\system32> Get-ExecutionPolicy
Unrestricted

错误输出中提到的行必须由 SQL Server 自动添加，因为RemoteSigned -scope process -Force它不在代码中的任何位置。

除了使用 AD 帐户运行作业之外，我还需要在 SQL Server 代理中设置什么吗？

这是来自的powershell行 msdb.dbo.syssubsystems

C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\SQLPS.exe

更新

这是版本

PS SQLSERVER:\SQL\CD000023\CEF_2014_1> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
2      0      -1     -1

更新 01/03/2015

此脚本基于中央管理服务器的注册服务器创建表 serverlist。然后它连接到这些服务器中的每一个并识别其侦听的端口。

# connection parameters
 Param ( 
      [string] …

我被要求确定存储过程的权限问题。根据用于其参数的值，此存储过程以两种可能的方式运行。

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和dm_exec_query_stats，我可以找到显示所使用存储过程的 SQL 的执行计划。但是，我无法恢复参数的定义方式和值。

是否可以使用dm_exec_procedure_stats和dm_exec_query_stats和任何其他管理视图来重建存储过程的执行，以显示用于其参数的值。

我真正想要的是在缓存中找到存储过程的实际执行，以便我可以执行它EXECUTE AS LOGIN = 'someone'来解决权限问题

我们最近将许多实例升级到 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 …

昨天我在尝试在 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 …

最近遇到一个情况，在进行日志备份和收缩文件后，LDF 文件大小保持不变。DBCC LOGINFO 清楚地显示只有一个活动的 VLF 和 SSMS 表示 LDF 中 99% 的空间是空闲的。第一次尝试没有缩小，第二次尝试或第三次尝试也没有缩小。第四次尝试成功后，日志减少到请求的大小。同时，DBCC LOGINFO 说在每个 SHRINKFILE 之后，另一个 VLF 变得活跃。

我决定运行一个新数据库的测试。

CREATE DATABASE logs_test
USE logs_test

-- first look at the VLFs for the logs_test database
DBCC LOGINFO

/*
FileId      FileSize             StartOffset          FSeqNo      Status      Parity CreateLSN
----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
2           253952               8192                 19          2           64     0
2           253952               262144               0           0           0      0

*/

-- put the database into FULL recovery before making a backup
ALTER DATABASE logs_test …

寻求帮助改进查询。此查询用于查看 LDF 文件中的最后 N 个事务，然后添加一些有用的信息，如用户、开始时间、查询文本等。

这是查询：

SET NOCOUNT ON
DECLARE @LSN NVARCHAR(46)
DECLARE @LSN_HEX NVARCHAR(25)
DECLARE @tbl TABLE (id INT identity(1,1), i VARCHAR(10))
DECLARE @stmt VARCHAR(256)
DECLARE @NUMOFTRANSACTIONS AS INT = 3;

-- common table expression to get the last N LSNs from the LDF
with currentlsns as (
SELECT TOP(@NUMOFTRANSACTIONS) [Current LSN] FROM fn_dblog(NULL, NULL) WHERE [Transaction SID] IS NOT NULL order by [Transaction ID] DESC
)
-- set the @LSN to the lowest because we are reading forward …

尝试向附加到经常使用的表的触发器添加一行

ALTER TRIGGER [dbo].[name_of_trigger] ON [dbo].[name_of_table] AFTER UPDATE
BEGIN

   IF ORIGINAL_LOGIN() in ('username')   RETURN

....somecode

END

陷入僵局，唯一的解决方案似乎是每隔几秒钟重试一次，到目前为止还没有奏效。除了按 F5 并希望它有效之外，还有其他方法可以让我的 if 条件处于何种状态吗？

谢谢，

克雷格

将 RESTORE FILELISTONLY 的结果存储在名为 #filepaths 的临时表中。

IF object_id('sp_restore') IS NOT NULL
    drop procedure sp_restore
    go

CREATE PROCEDURE sp_restore AS
BEGIN
    RESTORE FILELISTONLY FROM DISK = 'Z:\BACKUPS\my_database_backup.bak'
END
GO

insert into #filepaths 
exec sp_restore

如何将 'Z:\BACKUPS\my_database_backup.bak' 放入变量中？使脚本看起来与此类似。

DECLARE @BACKUP_PATH as nvarchar(max) = 'Z:\BACKUPS\my_database_backup.bak'

IF object_id('sp_restore') IS NOT NULL
    drop procedure sp_restore
    go

CREATE PROCEDURE sp_restore AS
BEGIN
    RESTORE FILELISTONLY FROM DISK = @BACKUP_PATH
END
GO

insert into #filepaths 
exec sp_restore

谢谢，克雷格

我正在研究一个删除 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)

或者

有没有办法使用批处理将 10% 的 some_table 数据插入到临时表中？像这样的东西：

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 …

我们最近从 SQL Server 2008R2 升级到 SQL Server 2014 SP1 + CU4。

几周后，执行计划出现了无法正确估计行数的问题。问题一度变得如此严重，以至于决定通过再次启用9481跟踪标志和更新统计信息来恢复到旧的基数估计器。当我说“变得如此糟糕”时，我指的是在某些情况下查询的执行时间增加了 10。

使用 traceflag 9481已经解决了问题，但这不是解决方案吗？

搜索谷歌显示，有些人采用旧的基数估计器路线，而其他人则使用2312和4199的组合来使用新的估计器。

那么在从 2008R2 升级到 2014 之后，我们应该采取什么样的跟踪标志（如果有）和其他步骤的组合？

谢谢，克雷格

4 月 26 日上午 9 点更新

4199 跟踪标志不会打开新的基数估算器。我不得不改用 2312 跟踪标志。

使用 4199 跟踪标志时，版本仍为70。Chris Wood 的回答让我想起了Brent Ozar的一篇文章，我在某个时候也读过。仍在等待查看执行时间是否有所改善。