O SQL Server 2019 introduziu um novo procedimento armazenado do sistema (e não documentado):
sys.xp_delete_files
O que exatamente esse novo procedimento armazenado estendido faz? Como ele difere do xp_delete_fileque já existe há anos? Ele substitui xp_delete_file?
Tenho várias versões do SQL Server, usadas para testes, instaladas no meu laptop (2012, 2014, 2016 e 2017). Percebi outro dia que havia uma pasta contendo versões anteriores de arquivos entre atualizações (SPs, CUs). Em todas as versões, há bastante espaço sendo ocupado:
(em C:\Program Files (x86)\Microsoft SQL Server\ )
110\Setup Bootstrap\Log - 91.8 MB (818 files)
110\Setup Bootstrap\Update Cache - 608 MB (2,382 files)
(todas as pastas abaixo residem em: C:\Program Files\Microsoft SQL Server\ )
110\Setup Bootstrap\Log - 1.18 GB (3,715 files)
110\Setup Bootstrap\Update Cache - 9.58 GB (14,766 files)
120\Setup Bootstrap\Log - 569 MB (2,963 files)
120\Setup Bootstrap\Update Cache - 5.74 GB (12,797 files)
130\Setup Bootstrap\Log - 448 MB (2,808 files)
130\Setup Bootstrap\Update Cache - 3.84 GB (8,579 files)
140\Setup Bootstrap\Log - 84.3 MB (687 files)
140\Setup Bootstrap\Update Cache - 937 MB (1,571 Files)
Os totais para essas pastas são (MB foram normalizados para GB):
Folder GB Files
---------- ----- ------
Log 2.35 10,991
Update Cache 20.66 40,095
TOTAL 23.01 51,086
Inicialmente, imaginei que deveria ser seguro remover as pastas Log e Update Cache , mas então achei melhor primeiro verificar se outras pessoas perguntaram isso e, em caso afirmativo, quais foram as respostas. Encontrei este artigo da KB:
Descrição da pasta Update Cache no SQL Server
quais Estados:
O que acontece se você remover esta pasta ou excluir seu conteúdo?
Se a pasta Cache de Atualização ou alguns patches forem removidos dessa pasta, você não poderá mais desinstalar uma atualização para sua instância do SQL Server e reverter para uma compilação de atualização anterior. Nessa situação, as entradas Adicionar/Remover Programas apontam para binários inexistentes e, portanto, o processo de desinstalação não funciona. Portanto, a Microsoft recomenda que você mantenha a pasta e seu conteúdo intactos.
OK. Não tenho planos de fazer downgrade ou desinstalar um SP ou CU, então devo estar bem, certo? Bem, existem outras referências, como esta:
É seguro excluir a pasta "Atualizar cache"?
em que alguém fez referência ao seguinte artigo da base de conhecimento:
que afirma (grifo nosso):
Quando você instala o SQL Server, o Windows Installer armazena arquivos críticos no Cache do Windows Installer (o padrão é C:\Windows\Installer). Esses arquivos são necessários para desinstalar e atualizar aplicativos.
Agora, este artigo em particular parece específico para a pasta C:\Windows\Installer , e não estou falando sobre a exclusão dessa pasta. Ainda assim, devido à menção da possibilidade de não poder aplicar atualizações, queria mais informações primeiro.
Alguém já removeu essas pastas antes, ou pelo menos apenas seu conteúdo? Se sim, houve algum efeito negativo? Essas pastas só aumentam. Acabei de aplicar os patches "Spectre / Meltdown" para todas as quatro versões e os totais aumentaram em 3,65 GB e 6.900 arquivos (o resultado final são os números mostrados no gráfico acima).
Para ser claro, não estou procurando se devo ou não remover uma ou ambas as pastas; Estou procurando posso ou não remover um ou ambos (sem quebrar nada além da capacidade de desinstalar/rebaixar, que já aceito como consequência).
Às vezes, tenho um script SQL que tem uma ou mais strings super longas (às vezes até estúpidas). Normalmente são VARBINARYliterais/constantes que representam arquivos/assemblies, mas ocasionalmente são texto.
O principal problema com strings realmente longas é que alguns editores de texto não lidam com elas muito bem. Por exemplo, tenho um VARBINARYliteral que uso em uma CREATE ASSEMBLY [AssemblyName] FROM 0x....instrução e o próprio Assembly tem pouco mais de 1 MB de tamanho, o que equivale a pouco mais de 2 milhões de caracteres em um arquivo de texto, pois cada byte exige que dois caracteres sejam representados em notação hexadecimal (por exemplo 0x1F= a 1e an F). O SQL Server Management Studio (SSMS) não lida bem com isso e trava por vários segundos enquanto tento rolar sobre essa linha. E, de fato, algumas versões (não tenho certeza se isso ainda acontece) exibirão até um aviso sobre linhas longas ao abrir um script que tenha pelo menos uma linha em um determinado comprimento.
Um problema secundário é que ele complica a formatação ao usar em um editor sem o Word-wrap habilitado ou ao postar online. O problema aqui é que o controle deslizante da barra de rolagem horizontal é muito estreito e movê-lo um pouco geralmente rola o texto não super longo para fora da vista.
Agora, o T-SQL não encerra comandos com novas linhas ou até mesmo ponto e vírgula (embora o ponto e vírgula seja preferido/recomendado, começando com o SQL Server 2005). Portanto, como o SQL Server sabe como analisar cada instrução de forma que saiba quando ela termina, parece que dividir a linha longa em várias linhas, separadas apenas por um newline/ carriage-return+ line-feed, não parece irracional. Mas isso não funciona em nenhum dos casos.
PRINT 'Line1
Line2';
retorna (na aba "Mensagens"):
Line1
Line2
E isso faz sentido o suficiente, pois a nova linha está dentro de um literal/constante. Mas fazer isso para um VARBINARYtambém não funciona.
PRINT 0x1234
5678;
me dá um erro.
Tenho um banco de dados pré-SQL Server 2017 que restaurei/atualizei para o SQL Server 2017. Neste banco de dados tenho um Assembly SQLCLR. O Assembly está marcado como SAFE, pois não faz nada que exija um nível mais alto de permissões e o banco de dados TRUSTWORTHYdesabilitou / OFF. As funções SQLCLR e os procedimentos armazenados funcionaram conforme o esperado antes de migrar para o SQL Server 2017, mas agora quando tento executar qualquer um deles recebo o seguinte erro:
Msg 10314, Level 16, State 11, Server XXXXXXXXXXX, Line YYYYYY
Ocorreu um erro no Microsoft .NET Framework ao tentar carregar o ID do assembly ZZZZZ. O servidor pode estar ficando sem recursos ou o assembly pode não ser confiável. Execute a consulta novamente ou verifique a documentação para ver como resolver os problemas de confiança do assembly. Para obter mais informações sobre este erro:
System.IO.FileLoadException: não foi possível carregar o arquivo ou assembly '{assembly_name}, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' ou uma de suas dependências. Ocorreu um erro relacionado à segurança. (Exceção de HRESULT: 0x8013150A)
Confirmei que a integração CLR/SQLCLR foi habilitada no servidor/instância.
Estou usando o SQL Server 2017, Release Candidate 2 (RC2) no Linux (Ubuntu 16.04).
Quando o servidor é inicializado, o SQL Server geralmente também é iniciado. Mas, por algum motivo, o SQL Server não inicia mais. Pelo menos não consigo me conectar a ele usando sqlcmd . Eu recebo um erro de tempo limite de ODBC ( "Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server ") todas as vezes agora:
Login timeout expired.
TCP Provider: Error code 0x2749.
A network-related or instance-specific error has occurred while establishing a
connection to SQL Server. Server is not found or not accessible. Check if instance
name is correct and if SQL Server is configured to allow remote connections.
For more information see SQL Server Books Online..
No entanto, quando eu executo:
ps aux | grep mssql
Recebo duas entradas retornadas mostrando que o mssqlusuário está executando o sqlservrprocesso.
Além disso, o arquivo de log de erros em /var/opt/mssql/log/ não tem um carimbo de data/hora correspondente quando iniciei a VM (ou reiniciei o serviço), nem há novas entradas nesse arquivo.
E, em /var/log/messages , tudo o que aparece é:
Esta é uma versão de avaliação. Faltam [141] dias no período de avaliação.
Se eu executar systemctl status mssql-server, recebo o seguinte:
● mssql-server.service - Mecanismo de banco de dados do Microsoft SQL Server
Carregado: carregado (/lib/systemd/system/mssql-server.service; ativado; predefinição do fornecedor: ativado)
Ativo: falhou (Resultado: código de saída) desde segunda-feira de 2017- 09-04 20:01:56 BST; 36s atrás
Documentos: https://learn.microsoft.com/en-us/sql/linux
Processo: 8009 ExecStart=/opt/mssql/bin/sqlservr (code=exited, status=255)
PID principal: 8009 (code= saiu, status=255)Started Microsoft SQL Server Database Engine. This is an evaluation version. There are [141] days left in the evaluation period. Stopping Microsoft SQL Server Database Engine... mssql-server.service: Main process exited, code=exited, status=255/n/a Stopped Microsoft SQL Server Database Engine. mssql-server.service: Unit entered failed state. mssql-server.service: Failed with result 'exit-code'.
Acabei de descobrir,por puro brilhoacidentalmente, esse SQL Server permite que você crie variáveis, parâmetros, variáveis de tabela, tabelas temporárias (locais e globais) e stored procedures temporárias (locais e globais) sem nenhum nome! Bem, pelo menos não no que eu consideraria ser um nome. Ou seja, você pode especificar DECLARE @ INT = 5;e isso é T-SQL válido: ele executa sem erro e nem mesmo é sinalizado com um sublinhado vermelho rabiscado no SSMS (código com lista completa de exemplos mostrados no final desta pergunta).
Dado que a página do MSDN para identificadores de banco de dados declara (ênfase minha):
Existem duas classes de identificadores:
Identificadores regulares
...
Identificadores delimitados ... Os identificadores
regulares e delimitados devem conter de 1 a 128 caracteres. Para tabelas temporárias locais, o identificador pode ter no máximo 116 caracteres.
e isso certamente não parece ser o comportamento pretendido, inicialmente considerei isso um defeito (não causa nenhum erro, mas não parece ser o comportamento "correto") e registrei um bug do Connect: Parâmetro, Variável e Temporário Nomes/identificadores de tabelas e procedimentos podem estar vazios .
NO ENTANTO, essa mesma página do MSDN também afirma:
Regras para identificadores regulares
Os nomes de variáveis, funções e procedimentos armazenados devem obedecer às seguintes regras para identificadores Transact-SQL.
O primeiro caractere deve ser um dos seguintes:
- Uma letra conforme definido pelo Padrão Unicode 3.2. A definição de letras Unicode inclui caracteres latinos de a a z, de A a Z e também caracteres de letras de outros idiomas.
O sublinhado (_), arroba (@) ou sinal de número (#).
Certos símbolos no início de um identificador têm um significado especial no SQL Server. Um identificador regular que começa com o sinal de arroba sempre denota uma variável ou parâmetro local e não pode ser usado como nome de nenhum outro tipo de objeto. Um identificador que começa com um sinal numérico denota uma tabela ou procedimento temporário. Um identificador que começa com sinais numéricos duplos (##) denota um objeto temporário global. Embora o sinal de número ou o sinal de número duplo possam ser usados para iniciar os nomes de outros tipos de objetos, não recomendamos essa prática.
Portanto, pode-se interpretar que o requisito mínimo de 1 caractere para o nome (da parte superior citada mostrando "1 a 128 caracteres") seria satisfeito simplesmente tendo um @ou #desde:
@ou #é o primeiro caractere, são necessários de 2 a 128 caracteres.ENTÃO, se esse comportamento não é um bug nem um defeito, há algum benefício em usar essa habilidade? Existe um caso de uso legítimo que é beneficiado por ser capaz de fazer isso (ou seja, algum benefício funcional para um projeto e não apenas reduzir a contagem de caracteres do código-fonte)?
Não consigo pensar em um, além de ser pouco profissional e deixar um código terrivelmente incontrolável para todos quando você muda para um novo empregador.
Mas também posso ver um problema funcional relacionado, pois existem vários blocos de código em muitos projetos que analisam objetos T-SQL. Se alguém usar um padrão RegEx procurando @seguido por algo como (\w+), ele ignorará essas entradas.
-- Local variables:
DECLARE @ INT = 99;
DECLARE @@ VARCHAR(10);
SELECT CONVERT(VARCHAR(20), @), STR(@);
SET @@ = STR(@);
SELECT @@;
GO
-- Table Variable:
DECLARE @ TABLE (Col1 INT);
INSERT INTO @ (Col1) VALUES (86);
SELECT * FROM @;
GO
-- Local Temporary Table:
CREATE TABLE # (Col2 DATETIME);
INSERT INTO # (Col2) VALUES (GETDATE());
SELECT * FROM #;
SELECT OBJECT_ID(N'tempdb..#');
GO
-- Global Temporary Stored Procedure
CREATE PROCEDURE ## ( @ INT = 999 )
AS
SELECT @ AS [Huh?];
GO
EXEC ##;
EXEC ## 204;
DECLARE @ INT = 12345;
EXEC ## @ = @;
-- The above also work in another session on the same instance, in a different Database
SELECT * FROM tempdb.sys.parameters tsp WHERE tsp.[object_id] = OBJECT_ID(N'tempdb..##');
-- returns 1 row showing a name of just "@"
PS Pesquisei aqui, nos Googles e no Microsoft Connect e não consegui encontrar nenhuma referência a nomes de variáveis "ausentes" ou "vazios" ou "identificadores". No entanto, @MartinSmith apontou essa "habilidade" sendo usada na seguinte resposta do StackOverflow para reduzir a contagem de caracteres do código: Crie um gráfico ASCII das palavras mais usadas em um determinado texto .
Eu criei alguns certificados (via CREATE CERTIFICATE ) e chaves assimétricas (via CREATE ASYMMETRIC KEY ) e os usei para assinar e contra-assinar vários procedimentos armazenados, funções definidas pelo usuário (UDFs), gatilhos e assemblies (via ADD SIGNATURE ) . Mas agora preciso descobrir quais Certificados e/ou Chaves Assimétricas foram usados para assinar quais módulos específicos.
Preciso criar alguns dados de teste que envolvam uma hierarquia. Eu poderia facilitar e fazer alguns CROSS JOINs, mas isso me daria uma estrutura completamente uniforme / sem nenhuma variação. Isso não apenas parece monótono, mas a falta de variação nos dados de teste às vezes mascara problemas que, de outra forma, seriam encontrados. Então, estou querendo gerar uma hierarquia não uniforme que siga estas regras:
WHILEloops aninhados, a preferência é encontrar uma abordagem baseada em conjunto. De um modo geral, a geração de dados de teste não tem os requisitos de eficiência que o código de produção teria, mas buscar uma abordagem baseada em conjunto provavelmente será mais educacional e ajudará no futuro a encontrar abordagens baseadas em conjunto para problemas. Portanto WHILE, os loops não são descartados, mas só podem ser usados se nenhuma abordagem baseada em conjunto for possível.[ CROSS | OUTER ] APPLY, que foi declarado acima como ok.Não tenho certeza se essas informações adicionais são importantes, mas apenas no caso de ajudar a ter algum contexto, os dados do teste estão relacionados à minha resposta a esta pergunta:
Importar arquivos XML para o SQL Server 2012
Embora não seja relevante neste ponto, o objetivo final de gerar essa hierarquia é criar uma estrutura de diretório para testar métodos recursivos do sistema de arquivos. Os níveis 1 e 2 serão diretórios e o nível 3 acabará sendo o nome do arquivo. Eu pesquisei (tanto aqui quanto nos Googles) e encontrei apenas uma referência para gerar uma hierarquia aleatória:
Linux: criar diretório aleatório/hierarquia de arquivos
Essa pergunta (no StackOverflow) é realmente muito próxima em termos de resultado desejado, pois também visa criar uma estrutura de diretório para teste. Mas essa pergunta (e as respostas) estão focadas em scripts de shell Linux/Unix e não tanto no mundo baseado em conjuntos em que vivemos.
Agora, sei gerar dados aleatórios, e já estou fazendo isso para criar o conteúdo dos arquivos para que eles também apresentem variações. A parte complicada aqui é que o número de elementos dentro de cada conjunto é aleatório, não um campo específico. E , o número de elementos dentro de cada nó precisa ser aleatório de outros nós nos mesmos níveis.
Exemplo de Hierarquia
Level 1
Level 3
|---- A
| |-- 1
| | |--- I
| |
| |-- 2
| |--- III
| |--- VI
| |--- VII
| |--- IX
|
|---- B
| |-- 87
| |--- AAA
| |--- DDD
|
|---- C
|-- ASDF
| |--- 11
| |--- 22
| |--- 33
|
|-- QWERTY
| |--- beft
|
|-- ROYGBP
|--- Poi
|--- Moi
|--- Soy
|--- Joy
|--- Roy
Conjunto de resultados de exemplo descrevendo a hierarquia acima
Level 1 Level 2 Level 3
A 1 I
A 2 III
A 2 VI
A 2 VII
A 2 IX
B 87 AAA
B 87 DDD
C ASDF 11
C ASDF 22
C ASDF 33
C QWERTY beft
C ROYGBP Poi
C ROYGBP Moi
C ROYGBP Soy
C ROYGBP Joy
C ROYGBP Roy