DForck42's questions

Eu executei o script de instalação sem e com o parâmetro -Force do documento de introdução no github

Install-Module dbatools -Scope CurrentUser
Install-Module dbatools -Scope CurrentUser -Force

Este código funciona no meu servidor antigo, mas não está funcionando no novo.

$Params =
@{
    Column1 = $Column1;
    Column2 = $Column2
}


$InsertQuery =
"           
    insert into dbo.Table
    (
        Column1,
        Column2
    )
    values
    (
        @Column1,
        @Column2
    )
"


Invoke-DbaQuery -SqlInstance "server" -Database "database" -Query $TableSizeInsertQuery -SqlParameter $Params

Eu continuo recebendo esse erro:

Error connecting to [server]: Cannot find an overload for "SqlCommand" and the argument count: "2". At C:\Users\username\Documents\WindowsPowerShell\Modules\dbatools\1.1.46\allcommands.ps1:92862 char:9
+         throw $records[0]
+         ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (server:String) [], Exception
    + FullyQualifiedErrorId : dbatools_Invoke-DbaQuery

Eu também executei estes comandos:

Install-Module -Name SqlServer
import-module -name SqlServer
install-module -name dbatools
Import-Module -name dbatools

Temos uma lista cada vez maior de guids para os quais precisamos rastrear uma lista sempre crescente de ids inteiros. Nossa implementação atual cria uma sequência sem cache para cada guid.

No entanto, não antecipamos o impacto no desempenho do banco de dados que geraria milhares de sequências e a seleção delas. Devido ao número de sequências em uso de uma só vez, o cache do plano é absolutamente destruído. Outras consultas no servidor estão sofrendo com isso.

Existe uma maneira melhor de rastrear um id sempre crescente para esses guias que podem evitar condições de corrida? Cada guid precisa começar em 1 e incrementar em 1 sem nunca pular um número. Também precisaremos ser capazes de cortar para esse novo método de nossas sequências atuais.

Por exemplo, atualmente o guid 'F642631D-AD28-4943-8340-5E7793EB82B8' terá a sequência dbo.F642631D-AD28-4943-8340-5E7793EB82B8 criada e os valores recuperados comselect Next Value for dbo.F642631D-AD28-4943-8340-5E7793EB82B8

Eu tenho uma consulta que estou escrevendo para converter algumas tabelas de heap com chaves primárias em tabelas em cluster, mas a string que estou gerando trunca em objetos além de um determinado comprimento, parece.

SELECT 
    --t.name,
 --   t.schema_id,
 --   t.type,
 --   t.type_desc,
 --   i.name,
 --   i.type,
 --   i.type_desc,
 --   i.is_primary_key,
    --c.name,
    'print ''dropping index on dbo.' + CAST(t.name AS VARCHAR(MAX)) + ''';' + CAST(CHAR(10) AS VARCHAR(MAX)) + CAST(CHAR(13) AS VARCHAR(MAX))  + 
    'drop index ' + CAST(i.name AS VARCHAR(MAX)) + ' on dbo.' + CAST(t.name AS VARCHAR(MAX)) + ';' + CAST(CHAR(10) AS VARCHAR(MAX)) + CAST(CHAR(13) AS VARCHAR(MAX)) +
    'go' + CAST(CHAR(10) AS VARCHAR(MAX)) + CAST(CHAR(13) AS VARCHAR(MAX)) +
    'print ''creating clustered primary key on dbo.' + CAST(t.name AS VARCHAR(MAX)) + ''';' + CAST(CHAR(10) AS VARCHAR(MAX)) + CAST(CHAR(13) AS VARCHAR(MAX)) +
    'alter table dbo.' + CAST(t.name AS VARCHAR(MAX)) + ' add constraint ' + CAST(i.name AS VARCHAR(MAX)) + ' primary key clustered (' + CAST(c.name AS VARCHAR(MAX)) + ');'
FROM sys.tables t
    INNER JOIN sys.indexes i
        ON i.object_id = t.object_id
    INNER JOIN sys.index_columns ic
        ON i.object_id = ic.object_id
            AND i.index_id = ic.index_id
    INNER JOIN sys.columns c
        ON t.object_id = c.object_id
            AND ic.index_column_id = c.column_id
WHERE i.type = 2
    AND t.object_id NOT IN
(
    SELECT distinct t.object_id AS tableid
    FROM sys.tables t
        INNER JOIN sys.indexes i
            ON t.object_id = i.object_id
    WHERE i.type  = 1
)
ORDER BY t.name,
    i.index_id

Como você pode ver, tentei envolver todas as colunas que estou usando em uma instrução cast, mas não ajudou. Eu não estou realmente certo por que isso não está funcionando.

exemplo do código completo:

print 'dropping index on dbo.Account';

drop index PK_Account on dbo.Account;

go

print 'creating clustered primary key on dbo.Account';

alter table dbo.Account add constraint PK_Account primary key clustered (Id);

exemplo do código truncado:

drop index PK_ALongerTableNameABC on dbo.ALongerTableNameABC;

go

print 'creating clustered primary key on dbo. ALongerTableNameABC';

alter table dbo.ALongerTableNameABC add constraint PK_ALongerTableNa

Estou pegando o código gerado executando a consulta com resultados para texto.

Temos um processo que cria uma nova sequência usando sql dinâmico. Em seguida, usamos sql dinâmico para obter o próximo valor da sequência. Nós temos muitas dessas sequências dinâmicas, mas não chamamos muito nenhuma delas, mas chamamos muitas delas.

No cache do plano é algo assim:

(@new int OUTPUT)SELECT @new = Next Value for dbo.[UniqueSequenceName1]
(@new int OUTPUT)SELECT @new = Next Value for dbo.[UniqueSequenceName2]
--etc

Eles estão consumindo muito do nosso cache de planos e tendem a ser chamados apenas uma vez antes de serem expulsos. Eu tenho o Optimize for Ad Hoc Workload ativado, mas isso não mudou o comportamento. Ativar a parametrização forçada ajudaria a reduzir a carga no cache do plano? Existe outra configuração que possa ajudar?

Estamos lutando contra um problema de pressão estranha de memória em um servidor específico há alguns meses. Veja como foi o último incidente no SentryOne:

Memoria do sistema

Memória do SQL Server

Configuração de memória:

• Memória Total do Servidor - 96 GB
• Memória máxima do servidor - 84 GB

A razão pela qual isso parece estranho é que, se fosse pressão de memória externa, eu esperaria que a categoria Outros na Memória do Sistema crescesse durante isso, o que não acontece.

Parte do que vemos acontecer nesse período é que as consultas acabam gerando planos ruins e acabam causando problemas de desempenho para o aplicativo. Historicamente, executar o DBCC FreeProcCache durante essa situação aliviou a pressão, mas ainda não sabemos a causa. Eu acho que os planos de um plano ruim são um sintoma e não uma causa desse problema, mas posso estar errado.

Coisas que fizemos para tentar resolver esse problema:

• Removida uma junção no que pensávamos ser o sp problemático
• Registros duplicados excluídos no banco de dados
• Maior memória no servidor (acho que adicionamos 16-32 gb)
• Bloqueio de páginas na memória ativado

Estou completamente perdido quanto ao que olhar a seguir. Nosso arquiteto acha que talvez precisemos mexer em algumas configurações de VM com memória, mas ainda não chegamos lá.

O que posso ver para corrigir esse problema estranho de pressão de memória?

Criamos um processo automatizado para criar um novo SQL Server usando TFS e powershell. Como parte de uma nova compilação de servidor, implantamos um banco de dados e um conjunto de trabalhos para uso de dba. Como parte da instalação, precisamos criar uma credencial para um proxy de agente sql para alguns de nossos trabalhos. No entanto, não queremos armazenar nossas senhas em código.

Existe uma solução para armazenar senhas (ou gerar uma senha) onde não estamos armazenando em texto simples ou em linha no código?

Nossos servidores estão no prim, não no Azure. Temos acesso ao Keepass, mas isso está sendo preterido para o Thycotic.

Encontramos um problema na produção algumas vezes em que parece que um procedimento armazenado recebe um plano novo e ruim e começa a causar estragos. Infelizmente, não conseguimos capturar o plano antes e depois para ver como era o plano ruim antes de fazermos um dbcc freeproccache, também não temos o armazenamento de consultas configurado.

Minha pergunta é, o que tudo pode fazer com que o sql server gere um novo plano para um procedimento armazenado? Especialmente para um sp que é executado o tempo todo. Alguns dos que conheço são:

• dbcc freeproccache
• reiniciando o servidor
• opção recompilar

Internamente, como o SQL Server determina o resultado de um select(*)? É diferente entre um heap e um índice clusterizado? É capaz de fazer coisas inteligentes com o índice clusterizado para não precisar carregar a tabela inteira?

Eu tenho um módulo Powershell que escrevi e carreguei no meu SQL Server em C:\Program Files\WindowsPowerShell\Modules. Eu tenho um trabalho do SQL Agent com uma etapa de powershell que chama o módulo. Isso tudo funciona e tem funcionado.

No entanto, recentemente fiz uma alteração na maneira como o módulo Powershell funciona. Atualizei o código e o carreguei no servidor, mas o SQL Server parece estar executando a versão desatualizada do código ainda, mesmo que o arquivo tenha sido substituído.

Preciso dizer ao SQL Server ou Powershell para "atualizar" o módulo de alguma forma? Como eu posso fazer isso?

Temos uma coluna configurada com Always Encrypted e a estamos adicionando a um AG. Gostaríamos que a criptografia continuasse funcionando se/quando tivermos que fazer failover para um servidor secundário. O Grupo de Disponibilidade copiará os certificados ou precisamos instalá-los manualmente?

Eu tenho uma tabela chamada dbo.messages. Estamos esperando muitos dados nesta tabela. Para manter as coisas em um nível razoável, estamos analisando um particionamento semanal nessa tabela. O que eu gostaria de fazer é pegar a partição semanal mais antiga, uma vez por semana, e trocá-la. Eu configurei que cada semana estará em seu próprio arquivo/grupo de arquivos. Isso em si não é grande coisa.

O que eu gostaria de fazer é pegar essa tabela trocada e transformá-la em uma cópia de arquivo da tabela. Preciso de uma função e esquema de partição separados para a tabela de arquivamento? Há alguma pegadinha com isso?

Estamos nos deparando com um erro estranho ao tentar fazer um teste de estresse em nosso aplicativo que atinge um AG. Se apontarmos o aplicativo diretamente para o servidor primário, não veremos nenhum problema com o teste. No entanto, se você apontar o aplicativo para o ouvinte, obteremos este erro:

provedor: TCP Provedor, erro: 0 - Você não foi conectado porque existe um nome duplicado na rede. Se ingressar em um domínio, vá para Sistema no Painel de Controle para alterar o nome do computador e tente novamente. Se ingressar em um grupo de trabalho, escolha outro nome de grupo de trabalho.

Nossa string de conexão é semelhante a esta:

> connection string= "data source=DB_C_Name; MultiSubnetFailover=True;
> initial catalog=DBName; integrated security=True;
> MultipleActiveResultSets=True; App=EntityFramework;"

O DB_C_Name é um AD CName que aponta para o Ouvinte, que por sua vez aponta para o WFC.

Verificamos duas vezes e todas as configurações do WFC parecem estar bem e não conseguimos encontrar nenhum IP duplicado em nossa rede.

Não sabemos por que isso aconteceria ao passar pelo ouvinte, mas não ao servidor diretamente. Também notamos isso acontecendo em alguns outros locais.

Temos duas filas, SSBInitiator e SSBTarget. Na minha situação de exemplo, executei o seguinte código para criar uma conversa:

BEGIN DIALOG CONVERSATION @ConversationHandle
                FROM SERVICE [//BLAH/Events/SSBInitiator]
                TO SERVICE '//BLAH/Events/SSBTarget'
                ON CONTRACT [//BLAH/Events/SSBContract]
                WITH ENCRYPTION = OFF;

Agora vamos dizer que, por algum motivo, decidi que essa conversa é desnecessária: ou o usuário cancelou a solicitação, ou algo mais aconteceu. Eu sei que posso encerrar a conversa usando:

end conversation @ConversationHandle

ou

END CONVERSATION @ConversationHandle   
      WITH ERROR = 1 DESCRIPTION = 'Ending Convo cause reasons';

Agora, com a conversa encerrada e nenhuma mensagem foi enviada, o serviço Target precisa fazer alguma coisa com a conversa? IE, há processamento adicional que precisa acontecer para garantir que a conversa seja completamente encerrada?

No meu trabalho, temos muitos objetos dos quais rastreamos versões. Estamos tentando criar um número bastante grande de objetos de sequência para acompanhar essas versões. Minha preocupação é que o sql server pode ter um número máximo deles que podemos criar, mas não consigo encontrar essa documentação.

Então, existe um número máximo de sequências que podem ser criadas no SQL Server 2014 e 2016?

Eu tenho um banco de dados de tráfego muito alto. No aplicativo, eles emitirão exclusões e, frequentemente, essas exclusões travarão com outras exclusões na mesma tabela. Estou pesquisando maneiras de remediar isso, e uma resposta que vi foi garantir que as exclusões tenham o caminho mais rápido para o registro.

Atualmente, todas as exclusões seguem este formulário:

(@0 int) delete [dbo].[table] where (table_id = @0)

Cada uma dessas tabelas tem uma chave primária e um índice clusterizado em table_id.

Minha pergunta é: adicionar um índice não clusterizado table_idpode ajudar a acelerar essas exclusões e impedir a ocorrência de deadlocks?

Gráfico de impasse:

<deadlock victim="process2b53a408c8"><process-list><process id="process2b53a408c8" taskpriority="0" logused="284" waitresource="KEY: 19:72057597368270848 (0e2c6d2527ac)" waittime="2034" ownerId="14899585071" transactionname="user_transaction" lasttranstarted="2018-03-07T09:47:18.833" XDES="0x50746b1c0" lockMode="S" schedulerid="7" kpid="967168" status="suspended" spid="185" sbid="2" ecid="0" priority="0" trancount="2" lastbatchstarted="2018-03-07T09:47:18.850" lastbatchcompleted="2018-03-07T09:47:18.850" lastattention="1900-01-01T00:00:00.850" clientapp="redacted_service" hostname="redacted_host" hostpid="164656" loginname="redacted_domain\_SQL_redacted_database_P" isolationlevel="read committed (2)" xactid="14899585071" currentdb="19" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056" databaseName="redacted_database"><executionStack><frame procname="adhoc" line="1" stmtstart="16" stmtend="120" sqlhandle="0x020000001335f1027371c186c8d7405191cdef00ddd0ebe70000000000000000000000000000000000000000">
unknown     </frame><frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
unknown     </frame></executionStack><inputbuf>
(@0 int)DELETE [dbo].[redacted_table]
WHERE ([id] = @0)    </inputbuf></process><process id="process218b0a5468" taskpriority="0" logused="284" waitresource="KEY: 19:72057597368270848 (c94c2713ec0f)" waittime="2036" ownerId="14899585063" transactionname="user_transaction" lasttranstarted="2018-03-07T09:47:18.833" XDES="0x1fcd0c4d10" lockMode="S" schedulerid="4" kpid="962372" status="suspended" spid="384" sbid="2" ecid="0" priority="0" trancount="2" lastbatchstarted="2018-03-07T09:47:18.850" lastbatchcompleted="2018-03-07T09:47:18.847" lastattention="1900-01-01T00:00:00.847" clientapp="redacted_service" hostname="redacted_host" hostpid="164656" loginname="redacted_domain\_SQL_redacted_database_P" isolationlevel="read committed (2)" xactid="14899585063" currentdb="19" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056" databaseName="redacted_database"><executionStack><frame procname="adhoc" line="1" stmtstart="16" stmtend="120" sqlhandle="0x020000001335f1027371c186c8d7405191cdef00ddd0ebe70000000000000000000000000000000000000000">
unknown     </frame><frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
unknown     </frame></executionStack><inputbuf>
(@0 int)DELETE [dbo].[redacted_table]
WHERE ([id] = @0)    </inputbuf></process></process-list><resource-list><keylock hobtid="72057597368270848" dbid="19" objectname="redacted_database.dbo.redacted_table_2" indexname="PK_redacted_table_2" id="lock9d21dab80" mode="X" associatedObjectId="72057597368270848"><owner-list><owner id="process218b0a5468" mode="X" /></owner-list><waiter-list><waiter id="process2b53a408c8" mode="S" requestType="wait" /></waiter-list></keylock><keylock hobtid="72057597368270848" dbid="19" objectname="redacted_database.dbo.redacted_table_2" indexname="PK_redacted_table_2" id="lock4de4b1800" mode="X" associatedObjectId="72057597368270848"><owner-list><owner id="process2b53a408c8" mode="X" /></owner-list><waiter-list><waiter id="process218b0a5468" mode="S" requestType="wait" /></waiter-list></keylock></resource-list></deadlock>

definição da tabela:

create table [dbo].[redacted_table](
    [id] [int] identity(1,1) not for replication not null,
    [loan_id] [int] not null,
    [user_role_id] [int] not null,
    [assigned_by_user_id] [int] not null,
    [out_for_assignment] [bit] not null,
    [assignment_date] [datetime] not null,
    [recognize_date] [datetime] not null,
    [routing_source] [varchar](50) null,
    [request_guid] [uniqueidentifier] null,
 constraint [PK_redacted_table] primary key clustered 
(
    [id] asc
)with (pad_index = off, statistics_norecompute = off, ignore_dup_key = off, allow_row_locks = on, allow_page_locks = on, fillfactor = 90) on [PRIMARY]
) on [PRIMARY]

go

alter table [dbo].[redacted_table] add  constraint [DF_redacted_table_assignment_date]  default (getdate()) for [assignment_date]
go

alter table [dbo].[redacted_table] add  constraint [DF_redacted_table_recognize_date]  default (getdate()) for [recognize_date]
go

alter table [dbo].[redacted_table]  with check add  constraint [FK_redacted_table_redacted_table3] foreign key([loan_id])
references [dbo].[redacted_table3] ([id])
go

alter table [dbo].[redacted_table] check constraint [FK_redacted_table_redacted_table3]
go

alter table [dbo].[redacted_table]  with check add  constraint [FK_redacted_table_user_redacted_table4] foreign key([user_role_id])
references [dbo].[user_redacted_table4] ([id])
go

alter table [dbo].[redacted_table] check constraint [FK_redacted_table_user_redacted_table4]
go

alter table [dbo].[redacted_table]  with check add  constraint [FK_redacted_table_redacted_table5] foreign key([assigned_by_user_id])
references [dbo].[redacted_table5] ([id])
go

alter table [dbo].[redacted_table] check constraint [FK_redacted_table_redacted_table5]
go

Encontramos um caso curioso hoje em que uma visão que está fazendo "selecionar * da tabela" tinha alguns campos de data e hora retornando como números inteiros. Isso estava funcionando anteriormente até muito recentemente. Isso não é nada na própria exibição que está forçando essas colunas a retornar como números inteiros.

Outra coisa curiosa é que reescrever a view para selecionar explicitamente todas as colunas faz com que os dados voltem como datetimes. Estou pensando que talvez seja algum tipo de plano de cache ruim, mas não tenho certeza.

Qual poderia ser o culpado dos dados sendo retirados incorretamente?

Estou tentando executar algumas análises sobre índices ausentes em um servidor (nunca fiz isso neste servidor antes). Eu estava executando sp_blitzindex e ele desligava em "Inserindo dados em #MissingIndexes". Pesquisei na consulta e encontrei onde ela atinge sys.dm_db_missing_index_details.

Tentar selecionar em sys.dm_db_missing_index_details retornará cerca de 300 registros e, em seguida, ele ficará sentado e girando. Eu não queria deixá-lo continuar para ver quanto tempo levaria para terminar, mas deixei correr por mais de dois minutos e não foi concluído.

Por que isso levaria muito tempo para retornar? O que causaria isso?

Estou usando o SentryOne e tenho o que acredito ser um processo de bloqueio. Ele o mostra com um ID de banco de dados de 32767 e um ID de objeto de -710746692. Procurei em sys.databases e sys.objects e não encontrei nada para isso. Fiz uma pesquisa pelo ID do banco de dados e acredito que seja o banco de dados de recursos oculto que o sql server possui. No entanto, uma pesquisa no google não retornou nada significativo para o id do objeto.

O que é o ID do objeto -710746692?

Eu tenho uma consulta construída dinamicamente com uma cláusula where que se parece com isso:

where column in ('a', 'a', 'a', 'b')

Os dados reais são MUITO mais longos com muitas duplicatas, como no exemplo acima, onde aé repetido três vezes.

Existe um impacto potencial de desempenho para uma WHEREcláusula muito grande usando um INcom um grande número de valores, muitos dos quais são duplicados?

Eu tenho a replicação configurada entre dois servidores. Hoje de manhã cheguei e estava falhando. Eu estava recebendo esses erros:

Mensagens de erro:

• O processo não pôde executar 'sp_replcmds' em 'PSQL3'. (Fonte: MSSQL_REPL, Número do erro: MSSQL_REPL20011) Obtenha ajuda:
• Não é possível executar como principal do banco de dados porque o principal "dbo" não existe, esse tipo de principal não pode ser representado ou você não tem permissão. (Fonte: MSSQLServer, Número do erro: 15517)
• O processo não pôde executar 'sp_replcmds' em 'PSQL3'. (Fonte: MSSQL_REPL, Número do erro: MSSQL_REPL22037)