All perguntas(dba)

Eu tentei a criptografia aes usando a seguinte declaração:

SELECT encrypt('test', 'key', 'aes');

que funcionou, mas não consigo descriptografar o valor. Inseri-o em um campo do tipo de dados bytea mas não tenho certeza se foi o caminho certo.

SELECT decrypt(pw, 'key', 'aes') FROM table WHERE ID = 1;

me dá o erro

ERRO: função decrypt(bytea, desconhecido, desconhecido) não existe
LINHA 1: SELECT decrypt(pw, 'chave', 'aes') FROM tabela WHERE ID = 7; ^
DICA: Nenhuma função corresponde ao nome e aos tipos de argumento fornecidos. Talvez seja necessário adicionar conversões de tipo explícitas.

Isso realmente significa que encrypt() é uma função existente, mas não decrypt()? De que outra forma eu poderia recuperar valores criptografados com aes?

Nosso servidor SQL reside em uma SAN. Ele contém dezenas de bancos de dados OLTP, alguns com várias tabelas contendo mais de 1 milhão de registros.

Temos executado os scripts de manutenção de índice de Ola Hallengren semanalmente, e eles são executados por várias horas a cada vez. Com base no limite de fragmentação, o script reorganizará ou reindexará um índice. Observamos que durante a reindexação, os arquivos de log ficam enormes, o que leva a um consumo excessivo de largura de banda durante o envio de log.

Em seguida, vem um artigo de Brent Ozar no qual ele diz para parar de se preocupar com índices SQL :

Seus discos rígidos são compartilhados com outros servidores que também estão fazendo solicitações de unidade ao mesmo tempo, portanto, as unidades sempre estarão pulando por todo o lugar para obter dados. Desfragmentar seus índices é apenas um trabalho ocupado sem sentido.

Pesquisar essa questão no Google leva a opiniões variadas, a maioria apoiada em argumentos que parecem muito breves ou fracos. Nosso plano provisório é ajustar o limite de fragmentação em nosso script de manutenção para que ele se reorganize com muito mais frequência do que reindexe.

Qual é o veredicto final? Vale a pena desfragmentar índices SQL em uma SAN considerando os encargos associados à execução de trabalhos de manutenção semanais?

Eu tenho uma consulta que está levando em média 2500ms para ser concluída. Minha tabela é muito estreita, mas tem 44 milhões de linhas. Quais opções eu tenho para melhorar o desempenho, ou isso é o melhor possível?

A pergunta

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31'; 

A mesa

CREATE TABLE [dbo].[Heartbeats](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [DeviceID] [int] NOT NULL,
    [IsPUp] [bit] NOT NULL,
    [IsWebUp] [bit] NOT NULL,
    [IsPingUp] [bit] NOT NULL,
    [DateEntered] [datetime] NOT NULL,
 CONSTRAINT [PK_Heartbeats] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

O índice

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

Adicionar índices adicionais ajudaria? Se sim, como eles seriam? O desempenho atual é aceitável, porque a consulta é executada apenas ocasionalmente, mas estou pensando como um exercício de aprendizado, há algo que eu possa fazer para tornar isso mais rápido?

ATUALIZAR

Quando altero a consulta para usar uma dica de índice de força, a consulta é executada em 50 ms:

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WITH(INDEX(CommonQueryIndex))
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 

Adicionar uma cláusula DeviceID seletiva corretamente também atinge o intervalo de 50 ms:

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' AND DeviceID = 4;

Se eu adicionar ORDER BY [DateEntered], [DeviceID]à consulta original, estou na faixa de 50ms:

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 
ORDER BY [DateEntered], [DeviceID];

Todos eles usam o índice que eu esperava (CommonQueryIndex), portanto, suponho que minha pergunta agora seja: existe uma maneira de forçar esse índice a ser usado em consultas como essa? Ou o tamanho da minha tabela está atrapalhando demais o otimizador e devo apenas usar um ORDER BYou uma dica?

Eu estava olhando uma postagem no StackOverflow onde Aaron Bertrand propõe o uso de um CTE em vez de uma tabela de números, que é uma maneira elegante de executar a tarefa em questão. Minha dúvida é: por que a primeira linha do CTE começa com ponto e vírgula?

;WITH n AS (SELECT TOP (10000) n FROM 
  (SELECT n = ROW_NUMBER() OVER
    (ORDER BY s1.[object_id])
    FROM sys.all_objects AS s1
    CROSS JOIN sys.all_objects AS s2
  ) AS x ORDER BY n
)
SELECT n FROM n ORDER BY n; -- look ma, no gaps!

Isso é para garantir que a instrução WITH não seja analisada em uma anterior SELECTou algo assim? Não vejo nada no SQL Server 2005 BOL sobre o uso de ponto e vírgula antes de WITH.

DB: Oracle 10g

SO: Windows Server 2003 64 bits

Eu consulto lista de sessões Oracle geradas por aplicativos da web (filtro por programa=w3wp.exe)

select * from V$session
where UPPER(program) LIKE '%W3%'
order by logon_time

De acordo com Logon_Time, por que ainda estão ativas as sessões de 31/07/2012 ou 01/08/2012 ou qualquer sessão anterior a hoje (21/08/2012)?

Configurei no sqlnet.ora: SQLNET.EXPIRE_TIME= 20 Então significa que a cada 20 min o Oracle está verificando se as conexões ainda estão ativas.

Todos os esquemas de usuário têm perfil padrão. Isso significa que nenhuma sessão nunca expiraria ou morreria?

Adicionado em resposta ao comentário de Phil:

Adicionado em resposta à resposta de Phil:

Tenho trabalhado no código em T-SQL para adicionar novos agendamentos a um trabalho do SQL Agent usando o proc sp_add_jobschedule no banco de dados msdb. Quando adiciono um novo agendamento (normalmente uma execução única em uma data/hora específica) e imediatamente vejo os valores em sysjobschedules e sysschedules, posso ver que o novo agendamento foi adicionado e está vinculado ao job_id para meu SQL Agent trabalho. No entanto, os valores para next_run_date e next_run_time têm 0 neles. Quando volto e olho para eles novamente em 2 ou 3 minutos, eles ainda mostram 0 neles. No entanto, quando volto 5 ou 10 minutos depois, ele agora mostra corretamente os valores de data e hora correspondentes à próxima execução agendada.

Então minhas perguntas são:

• Com que frequência esses valores são atualizados?
• Que processo é esse que atualiza esses valores?
• Se eu adicionasse um agendamento que fosse, digamos, 1 minuto no futuro, isso significa que o trabalho não será executado, pois next_run_date/time ainda não foi atualizado?

Exemplo do código que uso para adicionar um novo agendamento:

exec msdb.dbo.sp_add_jobschedule @job_id = @jobID
                    , @name = @JobName
                    , @enabled = 1
                    , @freq_type = 1
                    , @freq_interval = 0
                    , @freq_subday_type = 0
                    , @freq_subday_interval = 0
                    , @freq_relative_interval = 0
                    , @freq_recurrence_factor = 0
                    , @active_start_date = @ScheduleRunDate
                    , @active_end_date = 99991231
                    , @active_start_time = @ScheduleRunTime
                    , @active_end_time = 235959

onde @jobID é binary(16) que contém o job_id do trabalho em questão, @ScheduleRunDate e @ScheduleRunTime são INTs com a data e hora respectivamente.

Ao tentar escrever uma consulta, descobri (da maneira mais difícil) que o SQL Server analisa WHEREs em uma consulta muito antes de analisar os SELECTs ao executar uma consulta.

Os documentos do MSDN dizem que a ordem de análise lógica geral é tal que SELECT é analisado quase por último (resultando assim em erros "no such object [alias]" ao tentar usar um alias de coluna em outras cláusulas). Houve até uma sugestão para permitir o uso de aliases em qualquer lugar, que foi abatida pela equipe da Microsoft, citando problemas de conformidade com os padrões ANSI (o que sugere que esse comportamento faz parte do padrão ANSI).

Como programador (não um DBA), achei esse comportamento um tanto confuso, já que me parece que ele anula em grande parte o propósito de ter aliases de coluna (ou, pelo menos, aliases de coluna poderiam ser significativamente mais poderosos se fossem analisado anteriormente na execução da consulta), já que o único lugar onde você pode realmente usar os aliases é em ORDER BY. Como programador, parece que está perdendo uma grande oportunidade de tornar as consultas mais poderosas, convenientes e DRY.

Parece que é um problema tão evidente que é lógico, então, que existem outras razões para decidir que aliases de coluna não devem ser permitidos em nada além de SELECT e ORDER BY, mas quais são essas razões?

Estou lendo alguma documentação e white paper sobre Transparent Data Encryption. Algumas documentações também mencionam o backup da chave mestra do serviço (para esclarecimento, não estou falando sobre a chave mestra do banco de dados). Só não entendo exatamente por que isso é necessário, porque consegui fazer backup/restaurar um banco de dados com criptografia TDE do servidor A (backup) para o servidor B (restaurar) sem usar nenhuma chave mestra de serviço.

Em que cenário preciso restaurar a chave mestra de serviço?

As VIEWS (CREATE VIEW) são representadas em um ERD? Em caso afirmativo, como você os representa e especifica de quais tabelas eles vieram?

Estou vendo um comportamento estranho com a seguinte consulta T-SQL no SQL Server 2012:

SELECT Id 
FROM dbo.Person 
WHERE CONTAINS(Name, '"John" AND "Smith"')
ORDER BY Name

A execução dessa consulta sozinha me fornece cerca de 1.300 resultados em menos de dois segundos (há um índice de texto completo em Name)

No entanto, quando mudo a consulta para isso:

SELECT Id 
FROM dbo.Person 
WHERE CONTAINS(Name, '"John" AND "Smith"')
ORDER BY Name
OFFSET 0 rows
FETCH NEXT 10 ROWS ONLY

Demora mais de 20 segundos para me dar 10 resultados.

A consulta a seguir é ainda pior:

SELECT Id 
FROM ( 
    SELECT ROW_NUMBER() OVER (ORDER BY Name) AS RowNum, Id 
    FROM dbo.Person
    WHERE CONTAINS(Name, '"John" AND "Smith"') ) AS RowConstrainedResult 
WHERE RowNum >= 0 AND RowNum < 11 
ORDER BY RowNum

Leva mais de 1,5 minutos para ser concluído!

Alguma ideia?

plano lento

plano rápido