Reaces's questions

Estou assumindo um projeto que envolve a remoção e limitação de permissões de todos os usuários de banco de dados em nosso farm de servidores. (momentos divertidos)

Uma das permissões atualmente limitadas são as permissões db_owner.
Essa permissão está sendo analisada caso a caso, mas uma alteração comum é substituir as permissões db_owner pelo seguinte:

• db_datareader
• db_datawriter
• db_ddladmin
• db_executor

Eu gostaria de definir a diferença exata entre os dois (para informar os clientes).
No entanto, tanto quanto posso dizer, a diferença entre os dois deve ser:

• permissões db_accessadmin
• permissões db_backupoperator
• permissões db_securityadmin

Então, com efeito, eles perderiam:
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE], [BACKUP LOG], [CHECKPOINT]
[ALTER ANY APPLICATION ROLE],[ALTER ANY ROLE]
[DROP DATABASE]

Existe mais alguma coisa que um usuário perderia quando db_owner for substituído pelas quatro funções acima?
Isso realmente serve muito para um propósito de segurança?

Estou tentando recuperar algum espaço em disco em algumas de nossas máquinas de desenvolvimento.
Estas são máquinas que não estão tendo backup, não estão sendo desenvolvidas diretamente e não estão sendo mantidas particularmente bem.
Qualquer recuperação é feita de PRD ou PRE-PRD para o ambiente DEV, nada neste ambiente DEV específico é crítico.

Os modelos de recuperação nesses bancos de dados devem permanecer ativados FULLporque foram ordenados (apesar de nenhum backup real ser feito).
Como esses bancos de dados, em alguns casos, existem há algum tempo sem backups, estou procurando uma maneira adequada de reduzir seus logs.

Eu encontrei duas abordagens que podem servir ao propósito:

BACKUP LOG [databasename] TO DISK=’NUL:’

Seguido pela redução do log.

Ou:

ALTER DATABASE [databasename] SET RECOVERY SIMPLE;
ALTER DATABASE [databasename] SET RECOVERY FULL;

Seguido pela redução do log.

Minhas perguntas atuais:
Quais são as diferenças entre essas duas abordagens?
Há algo que estou perdendo / negligenciando?

Recentemente, tive que recriar um usuário várias vezes.
Para facilitar a criação do usuário, eu clicaria com o botão direito no usuário e escolheria script login as, create to, New Query Editor Window.

No entanto, depois de fazer isso, recebo um erro de sintaxe:

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

O que está acontecendo aqui?

Eu tenho um usuário que foi adicionado com autenticação do Windows a uma máquina SQL Server 2008 R2.

Ele havia deixado a empresa há alguns meses, quando seu usuário do AD foi desativado e movido para uma UO diferente.
Os logins e usuários do banco de dados dos usuários não foram afetados.
Ele então voltou para a empresa, seu usuário AD foi reativado e movido para a UO correta.

No entanto, todos os logins do banco de dados estão apresentando falhas de login.
O problema é resolvido se as seguintes ações forem executadas:

1. Solte o login existente
2. Crie o login novamente
3. Remapear o login para os usuários do banco de dados existentes

Este é um método impraticável, pois significa rastrear cada login e recriá-lo.

Como posso resolver isso de uma forma mais prática?
Na falta de uma solução mais prática, qual é a causa desse problema?

Estou fazendo um teste de desempenho em um banco de dados Microsoft Dynamics de alto tráfego (mais de 16.000 usuários, estimados mais de 1.000 simultâneos no pico).
O servidor está online há alguns meses, e estou fazendo alguns testes para ver como ele está lidando com o tráfego atual.

Ao verificar alguns contadores de desempenho durante o horário comercial, encontrei uma esquisitice na memória de destino e total do servidor.
Embora eu só sinalizasse isso como um problema se a memória de destino fosse claramente maior que a memória total, combinada talvez com outros contadores (dependendo da quantidade de diferença), os resultados aqui são um tanto estranhos.

Usando:

SELECT object_name, counter_name, cntr_value FROM sys.dm_os_performance_counters 
where (object_name like '%Buffer Manager%' and counter_name like '%page life%')
or (object_name like '%Memory Manager%' and counter_name like '%memory grants pending%')
or (object_name like '%Memory Manager%' and counter_name like '%target server memory%')
or (object_name like '%Memory Manager%' and counter_name like '%total server memory%');

Cheguei aos seguintes resultados:

counter_name                 |    cntr_value  
------------------------------------------------
Page life expectancy         |    14887
Memory Grants Pending        |    0
Target Server Memory (KB)    |    44040192
Total Server Memory (KB)     |    44040184

Claramente, atualmente não há pressão de memória e a expectativa de vida útil da página é maior do que o necessário. No entanto, parece que em algum momento o servidor SQL estava com exatamente 8 KB de memória.

Algo sobre esses números parece estranho para mim, mas não consigo identificar.
Isso é uma indicação de que em algum momento o servidor sql estava à beira de um problema de memória?
Estou correto ao pensar que, como esses números são tão semelhantes, posso descartá-los por enquanto e testar novamente quando passar um tempo decente?

Estou recebendo um erro de estouro aritmético e não consigo descobrir o caso.
Recentemente, tive que ajustar alguns procedimentos armazenados, para permitir a inclusão de datas no futuro.

A seguinte parte da extração de dados resultante agora falha com erros de estouro aritmético:

SELECT  
  CONVERT(varchar(8),DATEDIFF(week, CONVERT(date,convert(varchar(8),Column1)), GETDATE()))/[Column2]  
FROM Table1;

Não sei ao certo por que esse erro está ocorrendo.
Não há mais de 8 caracteres em qualquer entrada e alterá-la para varchar(max)não faz nada (como seria de esperar).

Remover o /[Column2]remove o erro, mas não consigo descobrir o porquê.

EDIT:
CAST([Column2] as numeric(8))faz o truque.
No entanto, select max(len([Column2]))diz que o campo mais longo tem 2 caracteres.

[Column1]é um decimal (32,0)
[Column2]é um decimal (3,0)

Então o que está acontecendo? Por que isso está causando um problema?

Ao revisar parte do nosso código, um colega postulou que estava aborrecido por sempre ter que escrever TRUNCATE TABLEquando não havia outro uso real para TRUNCATE.

Pesquisando isso no Google, realmente não consigo encontrar um motivo específico pelo qual a TABLEpeça é necessária.
o que estou perdendo? Existe alguma razão histórica para o TABLEin TRUNCATE TABLE?

Como você chama a seguinte expressão?

(TableName == NULL) ? "0" : TableName

Eu tenho uma noção do que isso faz, mas gostaria de procurar toda a definição de sintaxe, no entanto, como não há um descritor real na expressão, não consigo descobrir como é chamado.

Estou tentando entender como criar uma instrução de exclusão para uma tabela com uma chave composta.

Eu gostaria de criar algo como:

DELETE 
FROM 
    table_example1
WHERE
    COLUMN1, COLUMN2
    IN
    (SELECT COLUMN1, COLUMN2 FROM table_example2
    WHERE
        COLUMN_DATETIME > @Period);

Tendo em mente apenas a combinação de COLUMN1e COLUMN2é único, cada coluna por si só não é única.

Eu não consigo entender como eu realmente faria isso.

Recentemente, entrei em um ambiente em que muitos logins de bancos de dados não têm o enforce_password_policysinalizador ativado.
Uma auditoria futura está exigindo a verificação das senhas desses logins.

Usei a seguinte consulta para obter uma lista de logins e se os sinalizadores estão ativados ou desativados.

select 
    @@SERVERNAME as servername, 
    name, 
    IS_SRVROLEMEMBER('sysadmin', name) as SYSADMIN,
    type_desc,
    create_date,
    is_policy_checked,
    is_disabled,
    password_hash,
    PWDCOMPARE(name, password_hash) as UsernameAsPassword
FROM sys.sql_logins

No entanto, isso não me diz se as senhas realmente aderem à política de senhas, pois o sinalizador só é relevante ao criar um usuário.

Existe uma maneira conhecida de testar usuários existentes quanto à conformidade com a política de senha?
Não tenho acesso às senhas antigas e prefiro um método que não as exija.

Recentemente, atualizei do SQL Server 2005 para 2012. No entanto, durante a validação, um bug foi descoberto.

Um determinado gatilho foi codificado da seguinte forma:

CREATE TRIGGER [dbo].[trigger] on [dbo].[foo]
FOR UPDATE, UPDATE
AS
    UPDATE foobar
    SET datetime = GetDate()
    FROM bar
    WHERE foobar.id = bar.id
GO

Posso executar isso com segurança (estranhamente) no SQL Server 2005.

No entanto, no SQL Server 2012, ele lança (o que eu esperaria) um erro de sintaxe.

Erro de sintaxe: Especificação duplicada da ação "UPDATE" na declaração do gatilho.

Por que isso não gera um erro de sintaxe no SQL Server 2005? Meu google-fu sobre isso falhou comigo.

Por que isso aparentemente funciona no SQL Server 2005?

Tenho trabalhado para melhorar o desempenho de um grande banco de dados de relatórios.
Esse banco de dados tem 2 TB de tamanho e uma das tabelas maiores heapcontém três índices não agrupados.

Cada um dos índices não agrupados lida com uma combinação de Case_IDs com dados relevantes.
No entanto, os IDs de caso não são exclusivos, pois cada entrada de caso é armazenada no mesmo heap com Case_ID.
As investigações no lado comercial das coisas me levaram ao fato de que uma combinação de Case_ID, Line_Number e Document_ID é única.

No entanto, quase todas as consultas são definidas por datas (usando uma datetimecoluna chamada DATE).
Normalmente por WHERE DATE = 'xxxx-xx-xx 00:00:00.000, ou WHERE DATE > 'xxxx-xx-xx 00:00:00.000'. E os valores Line_Number e Document_ID na maioria dos casos nem são incluídos nos relatórios.

Como tal, criei um índice clusterizado no heap (no DEV), digitado na datetimecoluna.
O desempenho dos relatórios aumentou bastante, reduzindo os tempos de consulta de 5 minutos para 3 minutos para a maioria dos meus relatórios de teste, e não vi nenhum impacto negativo nos relatórios não estipulados por data.

No entanto, estou preocupado por estar indo longe demais, pois entendo que índices clusterizados não exclusivos raramente são a solução . O que estou fazendo é uma abordagem válida? Ou devo simplesmente indexar na chave composta exclusiva e criar um índice de cobertura na datetimecoluna?

Estou procurando atualizar vários usuários em bancos de READ_ONLYdados.
Como os bancos de dados são usados ​​24 horas por dia, 7 dias por semana em todo o mundo e as janelas de manutenção acabaram, gostaria de fazer isso durante um momento de baixa atividade (para poder cumprir os prazos).

Atualmente estou pensando em usar:

USE MASTER
GO
ALTER DATABASE SQL SET READ_WRITE
GO
USE SQL
GO
EXEC sp_addrolemember N'db_datareader', N'USER'
GO
USE MASTER
GO
ALTER DATABASE SQL SET READ_ONLY
GO

No entanto eu quero:

1. Garanta que isso não fique travado indefinidamente
2. Certifique-se de que nada pode ser gravado no banco de dados durante esta ação

Como não posso colocar esses comandos em uma transação e não tenho um servidor de aplicativos disponível nos ambientes DEV ou STG para testar as alterações antecipadamente, existe alguma documentação sobre a alteração read_onlyde estados para ações únicas? (Eu testei as instruções T-SQL e elas funcionam)

Além disso, como isso requer um bloqueio exclusivo no banco de dados, é provável que eu consiga passar minha declaração?

Estou inclinado a apenas propor que isso terá que esperar até a próxima janela de manutenção, ponto final. Mas espero que alguém aqui possa provar que estou errado.

Em um servidor sql dedicado a um banco de dados do Dynamics CRM, tenho visto alguns comportamentos estranhos.

Ao monitorar o crescimento usando a seguinte consulta como base, notei que o tempdb cresceu com bastante frequência nas últimas horas:

DECLARE @path NVARCHAR(1000)
SELECT @path = Substring(PATH, 1, Len(PATH) - Charindex('\', Reverse(PATH))) +
                      '\log.trc'
FROM   sys.traces
WHERE  id = 1
SELECT databasename,
       e.name   AS eventname,
       cat.name AS [CategoryName],
       starttime,
       e.category_id,
       loginname,
       loginsid,
       spid,
       hostname,
       applicationname,
       servername,
       textdata,
       objectname,
       eventclass,
       eventsubclass
FROM   ::fn_trace_gettable(@path, 0)
       INNER JOIN sys.trace_events e
         ON eventclass = trace_event_id
       INNER JOIN sys.trace_categories AS cat
         ON e.category_id = cat.category_id
WHERE  e.name IN( 'Data File Auto Grow', 'Log File Auto Grow' )
ORDER  BY starttime DESC 

Dá várias linhas de crescimento dos arquivos de dados:

tempdb  Data File Auto Grow Database    2015-03-02 09:50:33.187 2

No entanto, quando olho para o espaço ocupado pelo tempdb, não vejo onde está a crise de espaço:

USE tempdb 
GO 
SELECT DB_NAME() AS DbName, 
name AS FileName, 
size/128.0 AS CurrentSizeMB,  
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS FreeSpaceMB 
FROM sys.database_files; 

Dá a seguinte saída:

DbName  FileName    CurrentSizeMB   FreeSpaceMB
tempdb  tempdev     7500.000000     7492.625000
tempdb  templog     156.132812      93.820312
tempdb  tempdev2    7250.000000     7245.625000
tempdb  tempdev3    7250.000000     7245.312500
tempdb  tempdev4    7366.500000     7360.875000

A pessoa que mantém o CRM nos pediu para reduzir o tempdb.
Meu colega, no passado, obrigado. No entanto, não estou disposto a fazê-lo sem uma explicação. Especialmente considerando que o encolhimento se tornou uma ocorrência quase semanal.

Alguém pode me dar uma indicação de por que o tempdb tem tantos eventos de crescimento e como lidar com isso corretamente?
No momento, estou pensando em pedir mais armazenamento e aumentar a unidade tempdb em 50%.
No entanto, isso parece tratar o sintoma, não a causa.

No momento, estou revisando um caso em que um servidor SSRS está enfrentando bloqueios e impasses frequentes.
Os relatórios não são críticos para os negócios e são frequentemente eliminados para aliviar o bloqueio.

No entanto, este mesmo SQL Server possui alguns bancos de dados críticos (está compartilhando um servidor sql com um grande farm de sharepoint), que têm mostrado desempenho em declínio.
O plano do meu antecessor é o seguinte:

1. Migre 4 TB de bancos de dados de A para B
2. Migrar servidor de relatórios (originalmente A) de B para C
3. Migrar servidor de relatórios (originalmente C) de C para B

O raciocínio é que teremos um hardware melhor (B), poderemos nos livrar de um servidor antigo (A) e remover o servidor de relatórios (termina em C) do servidor de banco de dados crítico (agora B).

No entanto, não estou totalmente convencido de que isso afetará muito o desempenho (exceto para o hardware mais recente).
Eu tenho monitorado os blocos por quase uma semana, e é consistentemente o WriteLockSession bloqueando um ReadChunkSegment. O que, pelo que posso dizer da documentação (google), está perfeitamente bem.

Como posso determinar isso/se um processo bloqueado está causando lentidão em um banco de dados diferente?
Se eu pudesse mostrar que os problemas de desempenho não estão relacionados (relatórios e outros bancos de dados) além do hardware compartilhado, gostaria de configurar conjuntos de dados compartilhados . Como a maioria dos relatórios e todos os relatórios de execução longa estão consultando o mesmo pequeno subconjunto de dados.

Recentemente, tive uma discussão com um colega que estava pressionando para remover as cláusulas order by de uma consulta de produção porque a coluna order by era igual à chave primária .

Depois de uma longa discussão na qual tentei explicar que ele não pode garantir a ordenação com base na chave primária, a conclusão final foi que ele não iria pressionar para que as consultas MSSQL fossem alteradas.
Mas ele ainda iria mudar as consultas do DB2.

Não consegui encontrar imediatamente um artigo refutando que o DB2 ordena as consultas pela chave primária e, no momento, estou me perguntando se isso acontece ou não.

Portanto, minha pergunta é: como o DB2 ordena uma consulta se não houver uma cláusula order by? Ele usa a chave primária?
Como garantir que os dados saiam ordenados corretamente, sem uma cláusula order by, em um sistema paralelo?

Estou procurando uma opinião, que sei que geralmente é desaprovada, então peço desculpas antecipadamente.

Atualmente, estou em um ambiente em que todas as instâncias são SQL Server Enterprise Edition. As tarefas de manutenção estão sendo executadas por um plano personalizado. Este plano, por padrão, faz uma reconstrução offline durante a noite.

Não há janelas de manutenção noturna e, como o ambiente é multinacional, nem sempre a parte "noturna" da manutenção significa o ponto de menor atividade (no entanto, significa em 95% dos casos). E há muitos trabalhos noturnos que estão lentos devido, em parte, à manutenção agressiva da indexação. (Uma consulta de relatório que ficou presa esperando a reconstrução do índice de uma tabela de 300 GB com dados do cliente me levou a esse caminho)

Posso assumir que o seguinte terá um impacto principalmente positivo:

• Adicione um valor mínimo de fragmentação de 10% para reorganizar (atualmente feito todas as noites, independentemente de %)
• Alterando os requisitos mínimos de reconstrução para 30% (atualmente em 5%)
• Alterando o comportamento padrão para ONLINE
• Alterando a contagem mínima de páginas para 1.000 (atualmente em 50)

Principalmente, o que estou perguntando aqui é se estou correto ao assumir que o cronograma de manutenção atual é muito agressivo. E que as 4 mudanças acima terão um efeito líquido positivo.

Estou mais preocupado em reorganizar tudo todas as noites para tudo... Isso parece excessivo.

Estou examinando as consultas executadas por um aplicativo de terceiros. O aplicativo foi sinalizado como lento por alguns de nossos usuários finais.

Parece INSERTgravar em um HEAP e, em seguida, DELETEnovamente após o término da sessão (sem nenhuma seleção acontecendo neles?) Mas no final de cada INSERTinstrução, há um arquivo SELECT 0.

Estou vendo algum tipo de artefato do cache do plano de consulta? É possível que esteja faltando algum parâmetro? Todos os outros parâmetros são claramente indicados como por exemplo @P1.

Existem 350 INSERTações por minuto e uma hora DELETEde tudo na tabela. O que parece ser um bom caso para usar um HEAP, no entanto, se este SELECT 0 estiver realmente selecionando algo deste heap, estou me perguntando se devo adicionar um índice clusterizado.

Atualização: Adicionada uma captura de tela para mostrar a seleção:

Recentemente, encontrei um banco de dados com fragmentação muito alta em tabelas grandes.

Contagem de páginas > 1'000'000 com fragmentação 99,...

Gostaria de saber quanto tempo esta tabela ficou sem uma reorganização/reconstrução. Assim posso rever as alterações feitas nessa data, para tentar encontrar uma causa. (Também ficaria bem no meu relatório "este banco de dados não foi mantido adequadamente desde ...)

Como estou no processo de configurar um trabalho para reorganizar rapidamente as tabelas afetadas (provavelmente esta noite), qualquer solução que pudesse me oferecer um histórico de operações de índice seria muito apreciada. Caso contrário, simplesmente saber que posso verificar esses dados no futuro seria muito útil.

Estou procurando uma maneira de provar que alguns índices adicionados recentemente estão impactando positivamente um sistema de produção.

Eu coletei algumas estatísticas dmv para mostrar que os índices estão realmente sendo usados ​​(com frequência), mas preciso de alguma maneira para provar que eles estão tendo um impacto positivo o suficiente nas consultas selecionadas, que qualquer impacto negativo do tempo adicionado de atualização/exclusão é offput.

Estou procurando por qualquer insight / conselho sobre como provar que esses índices têm um impacto positivo.