Funções determinísticas e não determinísticas - SQL Server

          As funções determinísticas sempre retornam o mesmo resultado quando são chamadas com o uso de um conjunto específico de valores de entrada e quando recebem o mesmo estado do banco de dados. 
          As funções não determinísticas podem retornar resultados diferentes cada vez que são chamadas com um conjunto específico de valores de entrada, mesmo que o estado do banco de dados que elas acessam permaneça o mesmo. Por exemplo, a função AVG sempre retorna o mesmo resultado, dadas as qualificações declaradas acima, mas a função GETDATE, que retorna o valor datetime atual, sempre retorna um resultado diferente. Este tópico identifica o determinismo de funções de sistema internas e o efeito da propriedade determinística de funções definidas pelo usuário.

Determinismo de função interna

Você não pode influenciar o determinismo de nenhuma função interna. Cada função interna é determinística ou não determinística com base no modo como a função é implementada peloSQL Server. Por exemplo, a especificação de uma cláusula ORDER BY em uma consulta não altera o determinismo de uma função usada nessa consulta.

As seguintes funções internas pertencentes a categorias de funções internas que sempre são determinísticas.

ABS	DATEDIFF	POWER
ACOS	DAY	RADIANS
ASIN	DEGREES	ROUND
ATAN	EXP	SIGN
ATN2	FLOOR	SIN
CEILING	ISNULL	SQUARE
COALESCE	ISNUMERIC	SQRT
COS	LOG	TAN
COT	LOG10	YEAR
DATALENGTH	MONTH
DATEADD	NULLIF

As funções a seguir nem sempre são determinísticas, mas podem ser usadas em exibições indexadas ou índices em colunas computadas quando são especificadas de uma maneira determinística.

Todas as funções de agregação: Todas as funções de agregação são determinísticas, a menos que sejam especificadas com as cláusulas OVER e ORDER BY. 

CAST Determinística a menos que usado com datetime, smalldatetimeou sql_variant.

CHECKSUM Determinístico, com a exceção de CHECKSUM().

ISDATE Determinístico somente se usado com a função CONVERT, o parâmetro de estilo CONVERT é especificado e o estilo não é igual a 0, 100, 9 ou 109.

RAND RAND só é determinística quando um parâmetro seed é especificado.

CONVERT  Determinística, a menos que um destas condições exista:

O tipo é sql_variant. O tipo de destino é sql_variant e seu tipo de origem é não determinístico.

O tipo de origem ou de destino é datetime ou smalldatetime, o outro tipo de origem ou destino é uma cadeia de caracteres, e um estilo não determinístico é especificado. Para ser determinístico, o parâmetro de estilo deve ser uma constante. Além disso, estilos menores ou iguais a 100 são não determinísticos, com exceção dos estilos 20 e 21. Estilos maiores que 100 são determinísticos, com exceção dos estilos 106, 107, 109 e 113.

Todas as funções estatísticas de configuração, cursor, metadados, segurança e sistema são não determinísticas. As funções a seguir nunca são determinísticas

@@CONNECTIONS	GETDATE
@@CPU_BUSY	GETUTCDATE
@@DBTS	GET_TRANSMISSION_STATUS
@@IDLE	LAG
@@IO_BUSY	LAST_VALUE
@@MAX_CONNECTIONS	LEAD
@@PACK_RECEIVED	MIN_ACTIVE_ROWVERSION
@@PACK_SENT	NEWID
@@PACKET_ERRORS	NEWSEQUENTIALID
@@TIMETICKS	NEXT VALUE FOR
@@TOTAL_ERRORS	NTILE
@@TOTAL_READ	PARSENAME
@@TOTAL_WRITE	PERCENTILE_CONT
AT TIME ZONE	PERCENTILE_DISC
CUME_DIST	PERCENT_RANK
CURRENT_TIMESTAMP	RAND
DENSE_RANK	RANK
FIRST_VALUE	ROW_NUMBER
FORMAT	TEXTPTR

Microsoft anuncia novas imagens Azure VM: SQL Server 2017 Linux e Windows

Estamos compartilhando que a Microsoft disponibilizou novas imagens VM's SQL Server 2017 em Linux e Windows

Estão disponíveis no Azure Marketplace! Para implantação do SQL Server on Azure VMs, com flexibilidade, segurança e conectividade híbrida do Azure.

O que significa que você tem a opção de execução o SQL Server em máquinas virtuais baseadas

em Windows, Red Hat Enterprise Linux, SUSE Enterprise Linux Servidor ou Ubuntu, de sua preferencia.

Novas VMs publicadas, são para todas as edições SQL Server 2017:

• SQL Developer - edição completa grátis do SQL Server para desenvolvimento e teste (não para produção)
• SQL Express - banco de dados livre de entrada para carros de trabalho (1 GB de memória, 10 GB de armazenamento)
• Web SQL - banco de dados de baixo custo para pequenas aplicações web de médio porte
• SQL Standard - capacidades de banco de dados núcleo para cargas de trabalho de médio porte
• SQL Enterprise - edição completa do SQL Server com recursos abrangentes para o processamento missão crítica ou grandes volumes transacional, armazenamento de dados e cargas de trabalho de B.I inteligência de negócios

SQL SERVER - Backup Database with RETAINDAYS

SQL SERVER - Backup Database with RETAINDAYS, realmente funciona ?

Recentemente, fomos questionados por um dos clientes por que eles estão enfrentando
determinada situação. Em que eles especificaram em sua opção de backup, WITH RETAINDAYS 

mas que na realidade os sistemas não estão excluindo seus backups mais antigos após o período.. 

Bem, aqui está, é que a realidade e suposição de excluir backup automaticamente
 é absolutamente errada! 

Eu imagino que a palavra RETAINDAYS dá impressões errada ao usuário que, 

Quando o backup é criado, permanece disponível até os dias em que 
a opção RETAINDAYS sugere e, depois, ele é excluído automaticamente. Conclusão Errada! 

Se quiserem excluir seus arquivos de backup que foram criados anteriormente,

Devem executar com as rotinas de sqlcmd ou powershell. 

Opção RETAINDAYS tem uma finalidade muito diferente com backups.

Esta apenas impede que os usuários substituam o arquivo de backup gerado anteriormente,

se o usuário estiver tentando fazê-lo com a opção INIT.

Caso contrário, realmente não faz mais nada. 

*
Nota do autor :

Se o usuário estiver usando a opção FORMAT, o backup será substituído de qualquer maneira.
Isso significa que o uso de RETAINDAYS é muito limitado.

Eu acho que é isso. Não existe nada que possamos aprofundar sobre esta feature,

pois possui capacidades muito limitadas. Espero que possa ter esclarecidos,

as incompreensões sobre o uso desta funcionalidade.

Exemplo de script de como esta opção é usada no SQL Server:

SQL Server - Como ativar a compactação de backup por padrão (default)

SQL Server - Como ativar a compactação de backup por padrão (default)

Nesta publicação do blog, discutiremos como ativar a Compressão de backup por default.

No SQL Server 2008 foi inserido o recursos de backup compactados e hoje em dia muitas bases usufruem deste recurso.

Quando instalamos o SQL Server, por padrão, esta opção está desativada. 

Então, se você quer fazer o backup com a compressão, geralmente descrevemos o seguinte parâmetro: WITH COMPRESSION

1 2	BACKUP DATABASE [AdventureWorks2014] TO DISK = N'C:\AdventureWorks2014.bak' WITH COMPRESSION GO

Isso se torna muito tedioso e repetitivo depois de um tempo, pois cada vez que devemos tomar um backup, precisamos especificar o parametro.

 SQL Server possui uma opção padrão no nível do servidor, que podemos habilitar ou desativar.

1 2 3 4

EXEC sys.sp_configure N'backup compression default', N'1' GO RECONFIGURE WITH OVERRIDE GO

Quando executamos o script acima, ele permitirá a compactação por padrão em todo o seu banco de dados,

mesmo que a palavra-chave with compression não seja incluída. 

Caso deseja desativar para um único banco de dados específico, pode especificar a palavra-chave:

WITH NO_COMPRESSION para desativar a compactação desse banco de dados.

Podemos também pode ativar as mesmas configurações com o SQL Server Management Studio (modo grafico).

Na paga - Database Setting está a propriedade do servidor onde você podemos alterar a configuração de compactação de backup (Compress Backup) default.

*

Nota: Quando você habilitamos a compactação podemos notar que seu backup ocupa/demanda menos espaço,

ao mesmo tempo em que haverá um aumento maior consumo de CPU.

Particularmente, habilitamos a Compressão de backup em todos os clientes de bancos de dados.

Uma nova DMV SQL Server 2017 sys.dm_os_enumerate_fixed_drives

Microsoft apresentou uma nova DMV Para SQL Server 2017 - sys.dm_os_enumerate_fixed_drives.

Em substituição de xp_fixeddrives

Olhando para o modo como o SQL Server evoluiu, há mudanças no SQL Server 2017 Que o demostra a importância em facilitar os utilitários de Gerenciamento em multi-plataformas Windows e Linux. 

Há algumas novas aprendizagens que eu tenho abordado enquanto experimentamos o SQL Server 2017. Nas versões anteriores do SQL Server, quando necessário identificar espaços livre na unidade era usado:

1	xp_fixeddrives

De saída simples como abaixo neste servidor que possui tem apenas Duas unidades.

Drive MB livre
 ----- -----------
 C 260245
 E 259023

No SQL Server 2017, uma nova DMV foi adicionada, o que complementa os resultados anteriores! 

Exemplo do script:

1 2 3 4

SELECT fixed_drive_path     ,free_space_in_bytes / (1024 * 1024) 'Free Space'     ,drive_type_desc FROM sys.dm_os_enumerate_fixed_drives

retorno:

Como podemos compreender, o resultado é o mesmo que o procedimento avançado anterior complementado.

Desejamos ainda que a Microsoft tivesse adicionado também o espaço total em disco, que está faltando.

Quem sabe em uma próxima, grande abraços

SQL SERVER 2016 - Uma nova alternativa para DBCC INPUTBUFFER - sys.dm_exec_input_buffer

DBCC INPUTBUFFER foi um dos comandos dbcc mais populares para monitorar e identificar a última execução enviada de um client para uma instância do Microsoft SQL Server. Todos usamos isso há bastante tempo. No entanto, este comando DBCC sempre limitou-se aos poucos detalhes de informação. No SQL Server 2016, teremos disponivel uma nova Função de Gerenciamento Dinâmico (DMV) sys.dm_exec_input_buffer, que fornece muitos detalhes adicionais.

Anteriormente, toda vez que eu costumava executar o DBCC INPUTBUFFER, eu sempre senti que deveria ter alguns detalhes adicionais, juntamente com este, como quantas linhas as consultas são processadas ou quantos recursos eles estão consumindo. Nesta nova versão, temos muitas informações úteis junto com IDs de sessão e detalhes da execução de consultas.

Outra limitação do DBCC INPUTBUFFER foi que ele precisava ser identificado em um unico session_id e não havia nenhuma maneira em que pudéssemos juntar isso com o DMV atual para executá-lo para diversos IDs de sessão. Essa limitação também desaparece quando a nova função sys.dm_exec_input_buffer agora pode ser associada a sys.dm_exec_sessions.

Testamos executar a seguir a consulta e observar seu retorno.

1 2 3 4 5 6 7

SELECT es.session_id, ib.event_info, status, cpu_time,memory_usage, logical_reads, writes, row_count, total_elapsed_time, login_time,last_request_start_time, last_request_end_time,  host_name, program_name, login_name, open_transaction_count FROM sys.dm_exec_sessions AS es CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) AS ib WHERE es.session_id > 50

Este é o retorno do conjunto da consulta acima:

referências:  Pinal Dave (blog.sqlauthority.com)