Kenneth Fisher's questions

Tenho o seguinte código em uma instância gerenciada do SQL Server Azure e o desempenho é bem ruim.

INSERT INTO #CU WITH (TABLOCKX) (LA_ID, CU_ID)
SELECT la.LA_ID,
       c2.CU_ID
FROM #la la
    INNER JOIN dbo.T1 c ON c.CU_ID = la.CU_ID
    INNER JOIN dbo.T1 c2 ON c2.Parent_CU_ID = c.Parent_CU_ID
WHERE c.Parent_CU_ID > 0
      AND c.CU_ID <> c2.CU_ID
      AND la.Flag1 = 1
      AND EXISTS (SELECT 1 FROM #cid WHERE c2.CU_ID = ID)

Tenho um índice filtrado em T1.Flag, e se eu remover a desigualdade o desempenho é mais do que aceitável (5 minutos para 10 segundos), então estou confiante de que meu problema é com a desigualdade, mas não consigo pensar em nenhum padrão que me dará os mesmos resultados, mas terá um desempenho melhor. Alguma sugestão? Plano

Um de nossos trabalhos de replicação está falhando na etapa 3, que executa sp_MSdetect_nonlogged_shutdown , retorna uma 'String ou dados binários seriam truncados' . O que, obviamente, nos levou ao caminho de tentar encontrar um problema nos bancos de dados. No entanto, comparamos os dois bancos de dados e eles são idênticos. Pelo que posso dizer, o erro é na verdade um bug em sp_MSdetect_nonlogged_shutdown .

Eventualmente, verifiquei o trabalho novamente e a etapa 2 também estava falhando e lançando um minidespejo. Quando olhamos para o dump, ele diz:

o encadeamento tentou ler ou gravar em um endereço virtual para o qual não tem o acesso apropriado

A ID que executa o trabalho é uma ID SQL que é sysadmin, a etapa (2) está sendo executada na conta de serviço do agente. A conta de serviço tem acesso ao diretório de instantâneos. Temos vários outros trabalhos de replicação usando a mesma configuração de segurança que estão funcionando bem.

Versão SQL:

Microsoft SQL Server 2016 (SP2-GDR) (KB4532097) - 13.0.5102.14 (X64) 31 de dezembro de 2019 22:39:35 Copyright (c) Microsoft Corporation Enterprise Edition: licenciamento baseado em núcleo (64 bits) no Windows Server 2016 Standard 10.0 (Build 14393: ) (Hipervisor)

Alguém tem alguma idéia de onde posso encontrar o erro de permissões? Ou passos que posso usar para começar a reduzi-lo?

Estou tendo um problema de segurança estranho. Eu tenho um usuário que está usando o SSMS 18.2 em um servidor SQL 2016. Eles são membros de db_datareader, mas quando eles puxam a coluna Row Count em Object Explorer Details, ela está em branco. O melhor que posso dizer é que está exigindo o DBO para que as contagens de linhas apareçam.

Usuário com acesso de leitura:

Usuário com acesso dbo:

Isso é um bug ou intencional? Alguém sabe se existe um nível mais baixo de permissões que dará essa contagem de linhas? Eu sei que existem muitas outras maneiras de obter a contagem de linhas, sys.partitions , por exemplo, no entanto, o usuário insiste que deseja usar a janela OED.

Estou tentando executar um BULK INSERT, mas estou recebendo um erro de acesso negado. Até agora tentei o seguinte:

• Eu posso abrir o arquivo da minha máquina
• Estou logado no SQL Server (tentei v2008 R2 e v2016) usando a autenticação do Windows
• Eu tenho permissões de administrador do sistema
• Eu posso typeo arquivo usando xp_cmdshell (usa a conta de serviço SQL, mas elimina a ideia de que é um firewall)
• O caminho é um URL de rede e não uma unidade local

O comando que estou usando é esse:

BULK INSERT ken_temp
FROM '\\network_path\temp\kdf\text_file.txt'
WITH
   (
    FIELDTERMINATOR = ',', ROWTERMINATOR = '\n'
   ,ROWS_PER_BATCH = 50000
   ,MAXERRORS = 10
   )

Alguma ideia?

Recentemente, tivemos uma pergunta em que o usuário dboem um banco de dados tinha um sidque não correspondia ao owner_sidarquivo sys.databases. Entendo como o proprietário do banco de dados é diferente dos membros da função db_owner, mas sempre pensei que o usuário dbofosse o proprietário real do banco de dados. Não é esse o caso? E se sim, existem diferenças reais entre dboe o que está dentro sys.databases?

Atualmente, temos um banco de dados em SIMPLErecuperação e planejamos configurar um Availability Grouppara fins de relatório (Enterprise SQL 2016). Meu entendimento é que isso exigirá mover o banco de dados para FULLrecuperação. Não precisamos dos backups de log e não temos interesse em armazená-los, então estava pensando em configurar os backups de log para NUL(balde de bits). Nada do que li disse que terei problemas com isso, mas queria ter certeza de que não estou perdendo nada.

Estou tentando ajustar uma consulta bastante irritante em que várias tabelas têm algo parecido com:

date = '9999-12-31 23:59:59.9999999'

Pelo menos algumas das tabelas estão na faixa de 300 mil linhas e, quando filtro isso, acabo na faixa de 2 mil. Parecia razoável tentar um índice filtrado.

CREATE TABLE test (col1 int PRIMARY KEY, col2 int, col3 varchar(50), col4 datetime2(7), col5 int);
CREATE INDEX ix_filtered ON test(col2,col3) INCLUDE (col4) 
       WHERE col4 = '9999-12-31 23:59:59.9999999' ;
GO

SELECT col2,col3 FROM test 
WHERE col4 = '9999-12-31 23:59:59.9999999';
GO

No entanto, quando verifiquei o plano de consulta, ele não usaria o índice. Ele apenas fez uma varredura de índice clusterizado e uma pesquisa de chave. Obviamente, sem nenhum dado, isso faz sentido, mas mesmo com todos os meus dados, aconteceu a mesma coisa. A razão pela qual não me preocupei em fornecer nenhum dado é esse segundo problema que ocorre de qualquer maneira.

Quando tentei forçar o índice para ver como ficaria o plano de consulta:

SELECT col2,col3 FROM test 
WITH (index (ix_filtered))
WHERE col4 = '9999-12-31 23:59:59.9999999'

Eu recebo este erro:

Msg 8622, Nível 16, Estado 1, Linha 52 O processador de consulta não pôde produzir um plano de consulta devido às dicas definidas nesta consulta. Reenvie a consulta sem especificar nenhuma dica e sem usar SET FORCEPLAN.

Estou tentando descobrir por que estou recebendo o erro com a dica de consulta. Meu palpite é que a resposta para isso também me dirá por que o índice filtrado não está sendo usado.

Trabalhando em algum SQL dinâmico para criar uma tabela particionada contínua de 13 meses. Veja aqui algumas informações básicas .

A parte do SQL dinâmico é bastante simples e a primeira partição é alternada sem problemas. Infelizmente, quando chego à segunda partição, começo a receber este erro:

Msg 4972, Level 16, State 1, Line 16
ALTER TABLE SWITCH statement failed. Check constraints or partition function of source table 'DBName.dbo.TableName_Partition2' allows values that are not allowed by check constraints or partition function on target table 'DBName.dbo.TableName'.

Tenho certeza de que é algo simples, mas não consigo entender. Aqui está o código.

-- Existing structure
USE [SourceDB]
GO

CREATE TABLE [dbo].[SourceTable](
    [Col1] [bigint] NULL,
    [Col2] [int] NULL,
    [Col3] [int] NULL,
    [Col4] [int] NULL,
    [Col5] [int] NULL,
    [Col6] [money] NULL,
    [Modified] [datetime] NULL,
    [ModifiedBy] [varchar](50) NULL,
    [ModifiedType] [char](1) NULL
); 

CREATE CLUSTERED INDEX [SourceTable_Modified] ON [dbo].[SourceTable]
(   [Modified] ASC   )
GO

USE [DestinationDB]
GO

CREATE PARTITION FUNCTION [ThirteenMonthPartFunction](datetime) AS 
 RANGE RIGHT FOR VALUES 
    (   N'2015.08.01',
        N'2015.09.01',
        N'2015.10.01',
        N'2015.11.01',
        N'2015.12.01',
        N'2016.01.01',
        N'2016.02.01',
        N'2016.03.01',
        N'2016.04.01',
        N'2016.05.01',
        N'2016.06.01',
        N'2016.07.01',
        N'2016.08.01'
 );

CREATE PARTITION SCHEME [ThirteenMonthPartScheme] 
    AS PARTITION [ThirteenMonthPartFunction] ALL TO ([PRIMARY]);

CREATE TABLE [dbo].[DestinationTable](
    [Col1] [bigint] NULL,
    [Col2] [int] NULL,
    [Col3] [int] NULL,
    [Col4] [int] NULL,
    [Col5] [int] NULL,
    [Col6] [money] NULL,
    [Modified] [datetime] NULL,
    [ModifiedBy] [varchar](50) NULL,
    [ModifiedType] [char](1) NULL
) ON ThirteenMonthPartScheme (Modified);
GO

CREATE CLUSTERED INDEX [DestinationTable_Modified] ON [dbo].[DestinationTable]
(
    [Modified] ASC
) ON ThirteenMonthPartScheme (Modified);
GO

SELECT * 
    INTO [TableName_Partition2]
FROM SourceDB.dbo.[SourceTable]
WHERE Modified >= N'2015.08.01'
  AND Modified < N'2015.09.01';
GO

CREATE CLUSTERED INDEX [TableName_Modified]  
    ON [dbo].[TableName_Partition2] ([Modified] ASC);  
GO

ALTER TABLE [dbo].[TableName_Partition2] 
    ADD CONSTRAINT [CK_TableName_Partition2] 
    CHECK ([Modified] >= N'2015.08.01'
      AND  [Modified] < N'2015.09.01');
GO

ALTER TABLE [TableName_Partition2] 
    SWITCH TO [DestinationTable] PARTITION 2;
GO

DROP TABLE TableName_Partition2;
GO

Eu tentei cada número de partição, tentei reduzir o intervalo de tempo para uma única data (ou seja, modificado = '2015.09.02'), mas ainda recebo o mesmo erro. Estou perplexo.

Obrigado por qualquer ajuda.

Tarefa

Arquive todos, exceto um período contínuo de 13 meses, de um grupo de tabelas grandes. Os dados arquivados devem ser armazenados em outro banco de dados.

• O banco de dados está no modo de recuperação simples
• As tabelas têm 50 mil linhas a vários bilhões e, em alguns casos, ocupam centenas de GB cada.
• As tabelas atualmente não estão particionadas
• Cada tabela tem um índice clusterizado em uma coluna de data cada vez maior
• Cada tabela possui adicionalmente um índice não clusterizado
• Todas as alterações de dados nas tabelas são inserções
• O objetivo é minimizar o tempo de inatividade do banco de dados primário.
• O servidor é 2008 R2 Enterprise

A tabela "arquivo" terá cerca de 1,1 bilhão de linhas, a tabela "ao vivo" cerca de 400 milhões. Obviamente, a tabela de arquivo aumentará com o tempo, mas espero que a tabela ao vivo também aumente razoavelmente rápido. Digamos 50% nos próximos anos, pelo menos.

Eu tinha pensado nos bancos de dados estendidos do Azure, mas infelizmente estamos no 2008 R2 e provavelmente ficaremos lá por um tempo.

Plano atual

• Criar um novo banco de dados
• Crie novas tabelas particionadas por mês (usando a data modificada) no novo banco de dados.
• Mova os dados dos 12 a 13 meses mais recentes para as tabelas particionadas.
• Faça uma troca de renomeação dos dois bancos de dados
• Exclua os dados movidos do banco de dados agora "arquivado".
• Particione cada uma das tabelas no banco de dados "arquivo".
• Use trocas de partição para arquivar os dados no futuro.
  • Percebo que terei que trocar os dados a serem arquivados, copiar essa tabela para o banco de dados de arquivo e, em seguida, trocá-la na tabela de arquivo. Isso é aceitável.

Problema: estou tentando mover os dados para as tabelas particionadas iniciais (na verdade, ainda estou fazendo uma prova de conceito nela). Estou tentando usar o TF 610 (conforme o Guia de desempenho de carregamento de dados ) e uma INSERT...SELECTinstrução para mover os dados inicialmente pensando que seriam minimamente registrados. Infelizmente, toda vez que tento, é totalmente logado.

Neste ponto, estou pensando que minha melhor aposta pode ser mover os dados usando um pacote SSIS. Estou tentando evitar isso, pois estou trabalhando com 200 tabelas e tudo o que posso fazer por script, posso gerar e executar facilmente.

Há algo que estou perdendo em meu plano geral e o SSIS é minha melhor aposta para mover os dados rapidamente e com uso mínimo do log (preocupações de espaço)?

Código de demonstração sem dados

-- Existing structure
USE [Audit]
GO

CREATE TABLE [dbo].[AuditTable](
    [Col1] [bigint] NULL,
    [Col2] [int] NULL,
    [Col3] [int] NULL,
    [Col4] [int] NULL,
    [Col5] [int] NULL,
    [Col6] [money] NULL,
    [Modified] [datetime] NULL,
    [ModifiedBy] [varchar](50) NULL,
    [ModifiedType] [char](1) NULL
); 
-- ~1.4 bill rows, ~20% in the last year

CREATE CLUSTERED INDEX [AuditTable_Modified] ON [dbo].[AuditTable]
(   [Modified] ASC   )
GO


-- New DB & Code
USE Audit_New
GO

CREATE PARTITION FUNCTION ThirteenMonthPartFunction (datetime)
AS RANGE RIGHT FOR VALUES ('20150701', '20150801', '20150901', '20151001', '20151101', '20151201', 
                            '20160101', '20160201', '20160301', '20160401', '20160501', '20160601', 
                            '20160701') 

CREATE PARTITION SCHEME ThirteenMonthPartScheme AS PARTITION ThirteenMonthPartFunction
ALL TO ( [PRIMARY] );

CREATE TABLE [dbo].[AuditTable](
    [Col1] [bigint] NULL,
    [Col2] [int] NULL,
    [Col3] [int] NULL,
    [Col4] [int] NULL,
    [Col5] [int] NULL,
    [Col6] [money] NULL,
    [Modified] [datetime] NULL,
    [ModifiedBy] [varchar](50) NULL,
    [ModifiedType] [char](1) NULL
) ON ThirteenMonthPartScheme (Modified)
GO

CREATE CLUSTERED INDEX [AuditTable_Modified] ON [dbo].[AuditTable]
(
    [Modified] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON ThirteenMonthPartScheme (Modified)
GO

CREATE NONCLUSTERED INDEX [AuditTable_Col1_Col2_Col3_Col4_Modified] ON [dbo].[AuditTable]
(
    [Col1] ASC,
    [Col2] ASC,
    [Col3] ASC,
    [Col4] ASC,
    [Modified] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON ThirteenMonthPartScheme (Modified)
GO

Mover código

USE Audit_New
GO
DBCC TRACEON(610);

INSERT INTO AuditTable
SELECT * FROM Audit.dbo.AuditTable
WHERE Modified >= '6/1/2015'
ORDER BY Modified

Eu tenho um procedimento armazenado que se parece com isso:

SELECT columnlist
INTO #temptable
FROM Table
JOIN lotsofothertables
WHERE severalconditions

UPDATE anothertable
SET column = #temptable.column
FROM anothertable 
JOIN #temptable
    ON anothertable.PKColumn = #temptable.PKColumn

A consulta inicial frequentemente produzirá apenas algumas colunas (<100) para que a atualização seja rápida. Mas, ocasionalmente (e essas são as execuções com as quais estamos tendo problemas), ele produz 1.000 ou mesmo 10.000. Seria razoável acrescentar algo assim entre eles?

IF @@RowCount > 100
   CREATE INDEX ix_temp ON #temptable(PKColumn)

Ou é melhor apenas criar o índice na tabela, independentemente, já que com tão poucas linhas, a quantidade de tempo gasto criando o índice será bem pequena?

Uma das configurações para um usuário do SQL Server é o arquivo DEFAULT_SCHEMA. Isso é frequente, dbomas nem sempre. Sei que você pode alterar a configuração usando este código:

ALTER USER [UserName] WITH DEFAULT_SCHEMA = [SchemaName]

Pelo que posso dizer, sempre que crio um USERe não especifico DEFAULT_SCHEMAque ele usa dbo. Mas ainda estou descobrindo USERSque tem um esquema padrão diferente.

Se bem me lembro quando você tem uma instância que é atualizada do SQL 2000, o esquema padrão é o esquema correspondente ao nome do usuário. Eu estou supondo que é de onde vem a maioria, se não tudo, do que estou vendo.

Existem outras maneiras de criar um USERsem especificar DEFAULT_SCHEMAe fazer com que seja criado com algo diferente de dbo?

Nota: Isso é para versões do SQL Server 2005 e superiores.

Eu tenho uma consulta bastante simples

SELECT TOP 1 dc.DOCUMENT_ID,
        dc.COPIES,
        dc.REQUESTOR,
        dc.D_ID,
        cj.FILE_NUMBER
FROM DOCUMENT_QUEUE dc
JOIN CORRESPONDENCE_JOURNAL cj
    ON dc.DOCUMENT_ID = cj.DOCUMENT_ID
WHERE dc.QUEUE_DATE <= GETDATE()
  AND dc.PRINT_LOCATION = 2
ORDER BY cj.FILE_NUMBER

Isso está me dando um desempenho horrível (como nunca se preocupou em esperar que terminasse). O plano de consulta tem esta aparência:

No entanto, se eu removê- TOP 1lo, obtenho um plano parecido com este e é executado em 1 a 2 segundos:

PK correto e indexação abaixo.

O fato de ter TOP 1mudado o plano de consulta não me surpreende, estou apenas um pouco surpreso por torná-lo muito pior.

Observação: li os resultados desta postagem e entendi o conceito de a Row Goaletc. O que estou curioso é como posso alterar a consulta para que ela use o plano melhor. Atualmente, estou despejando os dados em uma tabela temporária e extraindo a primeira linha dela. Eu estou querendo saber se existe um método melhor.

Editar Para as pessoas que estão lendo isso depois do fato, aqui estão algumas informações extras.

• Document_Queue - PK/CI é D_ID e tem ~ 5k linhas.
• Correspondence_Journal - PK/CI é FILE_NUMBER, CORRESPONDENCE_ID e tem aproximadamente 1,4 mil linhas.

Quando comecei não havia outros índices. Acabei com um em Correspondence_Journal (Document_Id, File_Number)

Estou trabalhando em um pacote que precisa usar uma transação, mas estou recebendo o seguinte erro:

SSIS package "CATS-Package.dtsx" starting.
Information: 0x4004300A at Data Flow Task, SSIS.Pipeline: Validation phase is beginning.
Information: 0x4001100A at CATS-Package: Starting distributed transaction for this container.
Error: 0xC001401A at CATS-Package: The SSIS Runtime has failed to start the distributed transaction due to error 0x8004D01B "The Transaction Manager is not available.". The DTC transaction failed to start. This could occur because the MSDTC Service is not running.
SSIS package "CATS-Package.dtsx" finished: Failure.

Aqui está o que eu sei até agora:

• pacote 2012
• Estou executando na implantação do pacote
• A propriedade TransactionOption é definida como Obrigatório
• Executando em uma instância 2008 R2
• Posso criar uma transação distribuída manualmente na instância e de acordo com o visualizador de eventos que o MSDTC está executando.
• MSDTC tem as seguintes configurações

Alguém pode apontar em uma direção para encontrar informações adicionais.

Edit: Uma das etapas que li disse para executar o DTC na máquina local que executa o pacote, bem como no servidor que mantém a instância. Depois que fiz isso, recebi um novo erro:

Information: 0x4001100A at CATS-Package: Starting distributed transaction for this container.
Error: 0xC001402C at CATS-Package, Connection manager "connectionName": The SSIS Runtime has failed to enlist the OLE DB connection in a distributed transaction with error 0x8004D024 "The transaction manager has disabled its support for remote/network transactions.".
Error: 0xC0202009 at CATS-Package, Connection manager "connectionName": SSIS Error Code DTS_E_OLEDBERROR.  An OLE DB error has occurred. Error code: 0x8004D024.
Error: 0xC00291EC at Execute SQL Task - Max Product ID, Execute SQL Task: Failed to acquire connection "connectionName". Connection may not be configured correctly or you may not have the right permissions on this connection.

Com a parte importante sendo The transaction manager has disabled its support for remote/network transactions. Estou faltando alguma coisa nas permissões? Nota: o Allow Remote Clientstambém foi verificado.

Eu vi o ping do MSDTC mencionado (inclusive nos comentários abaixo), mas quando olhei para ele, não tenho certeza do que fazer com ele.

Meu entendimento é que um dos grandes benefícios de usar uma VM é que você pode compartilhar recursos entre as máquinas virtuais em um host. Assim, você pode ter um host com 120 CPUs e colocar 5 VMs com 32 CPUs cada. As CPUs extras são "compartilhadas" entre as VMs com o host atribuindo CPUs dinamicamente com base na necessidade. O mesmo para a memória.

Eu também entendi que isso é um grande não-não para VMs que hospedam SQL Servers, mas meus administradores de VM discordam. Alguém tem alguma evidência ou documentação de uma forma ou de outra?

Não sei se isso importa, mas estamos usando VMWare.

Eu estava tentando fazer alguns testes em índices filtrados ontem e criei uma situação bastante simples:

CREATE TABLE IndexTest 
(
    ID INT NOT NULL IDENTITY(1,1) CONSTRAINT pk_IndexTest PRIMARY KEY, 
    Col1 CHAR(1)
)
GO

CREATE INDEX ix_IndexTest ON IndexTest(Col1)
WHERE Col1 IS NOT NULL
GO

INSERT INTO IndexTest VALUES ('A'),('B'),('C'),('D')
INSERT INTO IndexTest VALUES (''),(''),(''),('')
INSERT INTO IndexTest VALUES (NULL),(NULL),(NULL),(NULL)
GO

Em seguida, tentei executar a seguinte consulta usando uma dica para forçá-la a usar o índice filtrado.

SELECT * 
FROM IndexTest WITH (INDEX(ix_IndexTest))
GO

Mas continuo recebendo o erro:

O processador de consulta não pôde produzir um plano de consulta devido às dicas definidas nesta consulta. Reenvie a consulta sem especificar nenhuma dica e sem usar SET FORCEPLAN.

Funciona se eu remover o filtro, mas não com ele. Eu até tentei trocar o filtro de várias maneiras, como WHERE Col1 = ''etc. Sempre que tenho um filtro, recebo esse erro. Alguém pode me dizer o porquê? Estou fazendo algo errado?

Eu tentei isso em uma instância do SQL Server 2012 e 2014 e criei um sqlfiddle dele aqui:

http://www.sqlfiddle.com/#!6/4a850/1

Edit: Não tenho certeza se isso importa, mas especificamente eu estava tentando ver se conseguia ver quais linhas estavam realmente contidas no índice. A ideia surgiu ao ver alguém usar essa técnica para recuperar dados (usando um índice não filtrado) de uma tabela corrompida.

Esta é a primeira vez que trabalho com TDE, então espero não ter feito nada terrivelmente errado.

Estou tentando mover meu banco de dados TDE de um servidor para outro. Eu criei uma chave mestra no banco de dados mestre do novo servidor. Em seguida, restaurei meu certificado do backup usando o seguinte comando:

CREATE CERTIFICATE MyServerCert
FROM FILE = 'CertBackupFile'

Quando o criei originalmente, não tinha uma chave de criptografia privada, então apenas a criptografei com uma senha.

Agora, quando tento restaurar o backup do meu TDE, recebo o seguinte erro

Msg 15507, Level 16, State 1, Line 2
A key required by this operation appears to be corrupted.
Msg 3013, Level 16, State 1, Line 2
RESTORE DATABASE is terminating abnormally.

Eu tentei olhar para a declaração de criação, mas não vejo onde posso colocar minha senha original. Além disso, quando olho para sys.certificates no meu servidor original, o pvt_key_encryption_type_desc = ENCRYPTED_BY_MASTER_KEY, mas no novo, ele diz NO_PRIVATE_KEY. Então, suponho que estou fazendo algo errado com o create.

Alguém pode me apontar na direção certa para consertar isso?

Estou escrevendo um trecho de código que usa correspondência de padrões em caracteres unicode, mas estou enfrentando um problema estranho. Alguns personagens funcionam e outros não.

DECLARE @Pattern nvarchar(50) = N'%[^a-z]%' -- Simple pattern
SELECT PatIndex(@Pattern, nchar(46797)), nchar(46797) -- Works
SELECT PatIndex(@Pattern, nchar(14843)), nchar(14843) -- Doesn't Work

O padrão deve buscar qualquer caractere que não seja az, mas por algum motivo não está capturando alguns caracteres. Alguém sabe por que alguns caracteres unicode combinariam e outros não?

Estou tentando usar o DMF sys.dm_io_virtual_file_stats para gerar informações de espera de IO em vários de meus servidores. Me deparei com esta postagem de Paul Randall: http://www.sqlskills.com/blogs/paul/survey-tempdb-and-transaction-log-io-latencies/ . Nela, ele pedia às pessoas que respondessem com os resultados dessa consulta:

SELECT
    [database_id],
    [file_id],
    [ReadLatency] =
        CASE WHEN [num_of_reads] = 0
            THEN 0 ELSE ([io_stall_read_ms] / [num_of_reads]) END,
    [WriteLatency] =
        CASE WHEN [num_of_writes] = 0
            THEN 0 ELSE ([io_stall_write_ms] / [num_of_writes]) END
FROM
    sys.dm_io_virtual_file_stats (NULL, NULL)
WHERE
    [file_id] = 2 OR [database_id] = 2;
GO

Minha pergunta é por que ele está usando io_stall_read_ms / num_of_readsem vez de io_stall_read_ms / num_of_bytes_readobter a média. Eu acho que ms/byte seria mais informativo do que ms/read. O que, pelo menos em parte, me leva a acreditar que não entendo o que as colunas num_of_reads/writes realmente representam.

BOL apenas diz

Número de leituras emitidas no arquivo.

o que realmente não me ajuda muito. Agradeceria qualquer esclarecimento que pudesse obter.

Estou tentando melhorar o desempenho da seguinte consulta:

        UPDATE  [#TempTable]
        SET     Received = r.Number
        FROM    [#TempTable] 
        INNER JOIN (SELECT  AgentID,
                            RuleID,
                            COUNT(DISTINCT (GroupId)) Number
                    FROM    [#TempTable]
                    WHERE   Passed = 1
                    GROUP BY AgentID,
                            RuleID
                   ) r ON r.RuleID = [#TempTable].RuleID AND
                          r.AgentID = [#TempTable].AgentID                            

Atualmente, com meus dados de teste, leva cerca de um minuto. Eu tenho uma quantidade limitada de entrada em alterações no procedimento armazenado geral em que essa consulta reside, mas provavelmente posso fazer com que eles modifiquem essa consulta. Ou adicione um índice. Tentei adicionar o seguinte índice:

CREATE CLUSTERED INDEX ix_test ON #TempTable(AgentID, RuleId, GroupId, Passed)

E na verdade dobrou a quantidade de tempo que a consulta leva. Eu recebo o mesmo efeito com um índice NON-CLUSTERED.

Eu tentei reescrever da seguinte forma sem nenhum efeito.

        WITH r AS (SELECT  AgentID,
                            RuleID,
                            COUNT(DISTINCT (GroupId)) Number
                    FROM    [#TempTable]
                    WHERE   Passed = 1
                    GROUP BY AgentID,
                            RuleID
            ) 
        UPDATE  [#TempTable]
        SET     Received = r.Number
        FROM    [#TempTable] 
        INNER JOIN r 
            ON r.RuleID = [#TempTable].RuleID AND
               r.AgentID = [#TempTable].AgentID                            

Em seguida, tentei usar uma função de janela como esta.

        UPDATE  [#TempTable]
        SET     Received = COUNT(DISTINCT (CASE WHEN Passed=1 THEN GroupId ELSE NULL END)) 
                    OVER (PARTITION BY AgentId, RuleId)
        FROM    [#TempTable] 

Neste ponto eu comecei a receber o erro

Msg 102, Level 15, State 1, Line 2
Incorrect syntax near 'distinct'.

Então eu tenho duas perguntas. Primeiro você não pode fazer um COUNT DISTINCT com a cláusula OVER ou eu apenas escrevi incorretamente? E segundo, alguém pode sugerir uma melhoria que eu ainda não tenha tentado? Para sua informação, esta é uma instância do SQL Server 2008 R2 Enterprise.

EDIT: Aqui está um link para o plano de execução original. Também devo observar que meu grande problema é que essa consulta está sendo executada 30 a 50 vezes.

https://onedrive.live.com/redir?resid=4C359AF42063BD98%21772

EDIT2: Aqui está o loop completo em que a instrução está conforme solicitado nos comentários. Estou verificando com a pessoa que trabalha com isso regularmente quanto ao propósito do loop.

DECLARE @Counting INT              
SELECT  @Counting = 1              

--  BEGIN:  Cascading Rule check --           
WHILE @Counting <= 30              
    BEGIN      

        UPDATE  w1
        SET     Passed = 1
        FROM    [#TempTable] w1,
                [#TempTable] w3
        WHERE   w3.AgentID = w1.AgentID AND
                w3.RuleID = w1.CascadeRuleID AND
                w3.RulePassed = 1 AND
                w1.Passed = 0 AND
                w1.NotFlag = 0      

        UPDATE  w1
        SET     Passed = 1
        FROM    [#TempTable] w1,
                [#TempTable] w3
        WHERE   w3.AgentID = w1.AgentID AND
                w3.RuleID = w1.CascadeRuleID AND
                w3.RulePassed = 0 AND
                w1.Passed = 0 AND
                w1.NotFlag = 1        

        UPDATE  [#TempTable]
        SET     Received = r.Number
        FROM    [#TempTable] 
        INNER JOIN (SELECT  AgentID,
                            RuleID,
                            COUNT(DISTINCT (GroupID)) Number
                    FROM    [#TempTable]
                    WHERE   Passed = 1
                    GROUP BY AgentID,
                            RuleID
                   ) r ON r.RuleID = [#TempTable].RuleID AND
                          r.AgentID = [#TempTable].AgentID                            

        UPDATE  [#TempTable]
        SET     RulePassed = 1
        WHERE   TotalNeeded = Received              

        SELECT  @Counting = @Counting + 1              
    END

Resultados de @@Version

Microsoft SQL Server 2008 (SP3) - 10.0.5500.0 (X64) 
Sep 21 2011 22:45:45 
Copyright (c) 1988-2008 Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)

Aqui está a definição do banco de dados

CREATE DATABASE [Scratch] ON  PRIMARY 
( NAME = N'Scratch_mdf', FILENAME = N'N:\MSSQL\TEST\Primary\Scratch_mdf.mdf' , SIZE = 17664KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
 FILEGROUP [DATA]  DEFAULT 
( NAME = N'Scratch_dat1a', FILENAME = N'N:\MSSQL\TEST\Data\Scratch_dat1a.ndf' , SIZE = 14539584KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
( NAME = N'Scratch_dat1b', FILENAME = N'N:\MSSQL\TEST\Data\Scratch_dat1b.ndf' , SIZE = 12016128KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
 FILEGROUP [INDEX] 
( NAME = N'Scratch_idx1', FILENAME = N'N:\MSSQL\TEST\Index\Scratch_idx1.ndf' , SIZE = 92864KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
( NAME = N'Scratch_idx2', FILENAME = N'N:\MSSQL\TEST\Index\Scratch_idx2.ndf' , SIZE = 84416KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
( NAME = N'Scratch_idx3', FILENAME = N'N:\MSSQL\TEST\Index\Scratch_idx3.ndf' , SIZE = 84416KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
( NAME = N'Scratch_idx4', FILENAME = N'N:\MSSQL\TEST\Index\Scratch_idx4.ndf' , SIZE = 92864KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%), 
 FILEGROUP [PM_G0] 
( NAME = N'PM_data0', FILENAME = N'N:\MSSQL\PDB1\Data\PM_data0.ndf' , SIZE = 768000KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%)
 LOG ON 
( NAME = N'Scratch_log1', FILENAME = N'N:\MSSQL\TEST\Log\Scratch_log1.ldf' , SIZE = 833024KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%) 
GO

ALTER DATABASE [Scratch] SET COMPATIBILITY_LEVEL = 100
GO

Aqui está o código para criar a tabela e adicionar um índice clusterizado. Em ambos os casos, estou especificando o grupo de arquivos PM_G0, mas quando verifico seu grupo de arquivos DATA.

CREATE TABLE Scratch.dbo.STUPID_TEST (dummycol int) ON [PM_G0];
CREATE CLUSTERED INDEX ix_test ON stupid_test(dummycol) ON PM_G0; 
-- Tried the filegroup name with/without brackets just in case

Estou verificando a localização do primeiro heap e, em seguida, o índice clusterizado usando esta consulta:

SELECT o.name objectname, fg.name filegroupname, sdf.name as datafile,i.name indexname, partition_id, partition_number, [rows]
FROM sys.partitions p
INNER JOIN sys.objects o ON o.object_id=p.object_id
INNER JOIN sys.tables t ON o.object_id = t.object_id
INNER JOIN sys.indexes i ON i.object_id=p.object_id and p.index_id=i.index_id
INNER JOIN sys.filegroups fg ON fg.data_space_id = i.data_space_id
INNER JOIN sys.database_files sdf ON sdf.data_space_id=fg.data_space_id
WHERE o.name = 'STUPID_TEST'

Teste interessante. Alterei o grupo de arquivos padrão para [index]. Confirmado que [index] era de fato o índice padrão em sys.filegroups, em seguida, descartei e recriei meu índice clusterizado e ele ainda foi para o grupo de arquivos [DATA]. Código abaixo

ALTER DATABASE Scratch MODIFY FILEGROUP [index] DEFAULT;
GO
DROP INDEX dbo.STUPID_TEST.IX_test;
CREATE CLUSTERED INDEX ix_test ON stupid_test(dummycol) ON [PM_G0];
GO