Via Transact-SQL

Neste  post , quero apresentar um recurso interessante do SQL Server: as tabelas temporárias globais . Talvez você já conheça o recurso de criação de tabelas temporárias : usando o caracter  # ( hastag , ou antigamente, sustenido) ao criar uma tabela prefixada por este caracter, os dados inseridos nesta tabela poderão ser visíveis durante toda a conexão que está trabalhando. Esta tabela somente existe para a conexão atual. Ao finalizar, a tabela deixará de existir. O que talvez ainda não conheça é que se usar dois caracteres ##, sua tabela será global, ou seja, todas conexões abertas poderão enxergá-la. Na figura 1, a conexão 1 está criando 3 tabelas temporárias : #Tmp_Local, ##Tmp_Global, #Tmp_Local_2. Figura 1 - Criação das tabelas temporárias na conexão 1 Ao visualizar as tabelas criadas (figura 2), todos os resultados são visualizados. Figura 2 - Visualização das tabelas temporárias na conexão 1 Na figura 3, a conexão 2 está criando apenas 1 tabela temporária : #Tmp_Loca...

Neste post , apresento como aumentar o tamanho inicial do tempdb .  Mas porque aumentar o tamanho inicial? O tamanho já não é autoincremental? Sim, o tempdb é autoincremental e aumentar automaticamente o seu tamanho conforme a necessidade de uso do SQL Server. Porém, isso toma transações que o SQL Server solicita para incrementar o tamanho. Deixar um tamanho fixo grande suficiente para que possamos trabalhar com as bases diminui instruções desnecessárias do SGBD durante tempo de execução. Além do mais, devemos garantir que o servidor de banco de dados tenha espaço suficiente para crescer. Então, este é o primeiro item a observar: garanta que seu HD ou SSD tenha espaço suficiente para que o SQL Server possa usufruir das gravações e leitura de dados. Espaço livre de 4Gb no HD, por exemplo,  vai comprometer consideravelmente a performance do SQL Server. Garanta ao menos uns 70Gb de espaço. Isso estou considerando que você esteja com uma base de produção de uns 20 - 50Gb. Se for m...

Sobre o tema "Performance SQL Server" ( Tuning SQL Server) quero fazer uma série de posts para demonstrar os métodos de melhoria de desempenho do banco de dados em relação aos front-end' s que recuperam os resultados e exibem aos usuários finais.  Neste primeiro post , tratarei sobre a criação de índices. Não apresentarei aqui sobre nenhum front-end , mas em futuros posts explicarei sobre o Profiler para obter as instruções utilizadas por qualquer front-end que esteja interagindo com o SQL Server. O primeiro ponto a esclarecer é que a criação de índices para uma base de baixa performance é um estudo de caso de cada instância em particular. Isso quer dizer que não adianta encontrar um índice que melhora o desempenho de uma base e que podemos sair distribuindo a todos os clientes que estejam utilizando mesmo software . Algumas vezes sim, se reaproveita.  Por isso, o primeiro passo é verificar o que o SQL Server desta instância que estamos analisando nos diz sobre algum SE...

Neste post vou descrever o método de backup compactado com código Transact-SQL com o mesmo efeito da postagem anterior de modo visual. A vantagem em codificar é de agendar a execução por qualquer aplicativo disponível, como o Agendador do Windows ou mesmo o SQL Agent nas versões em que este está instalado. E para quem estiver desenvolvendo um programa de backup, também será bastante útil para otimizar a execução. Vale ressaltar que a versão do SQL Express não possui a compactação, visto que a base somente vai até 10Gb. O próprio backup compactado é desnecessário neste caso. Na figura 1, apresento 5 comandos práticos para backup / restore / attach de base. Estou usando os exemplos em duas instâncias diferentes do SQL Server: 2014 (que é Express) e outra 2019 (que é Developer). Fiz as próprias descrições nos comentários do comando e relaciono abaixo o texto para você testar no seu Microsoft SQL Server Management Studio.  O código aqui, se aplica a bases simples, sem clusterização ou...

O uso de SSD atualmente nos proporciona uma performance considerável nos sistemas em uso. Porém, ainda é uma tecnologia muito cara para o usuário consumidor final que em geral possui um HD deste tipo na ordem de 256Gb. Empresas podem ter 1Tb ou mais, mas para o desenvolvedor de aplicações que irá ter várias bases de clientes restauradas, o pequeno espaço em disco pode ser um grande problema. Uma prática importante pra este caso é fazer o backup da base já compactado pelo próprio SGBD, gerando um arquivo de backup de até 10% do tamanho original, dispensando assim o uso de ferramentas externas para criar (por exemplo) um .zip do arquivo de backup da base enorme e evitando a necessidade de ter o dobro de espaço no HD para restaurá-la. Por exemplo : uma base possui 40Gb de tamanho e seu HD SSD tem apenas 70Gb de espaço livre. Para restaurar uma base precisaríamos de (no mínimo) 80Gb de espaço livre. Se você zipar o backup da base com uma ferramenta externa, ganhará na transferência...

  De acordo com a edição do SQL Server que instalamos ou versão, podemos encontrar algumas diferenças de limitações de software e hardware (no caso das edições) ou de estrutura de comandos (no caso da versão). Em geral, mudanças de versão acrescentam poucas diferenças na consulta e manipulação de dados, mas acontecem. Porém, sempre podemos recorrer aos comandos puramente ANSI SQL, ou seja, comandos básicos disponíveis em qualquer SGBD. Algo de suma importação a ser comentada é que: se um banco de dados for restaurado em uma certa versão do SQL, esta banco não poderá ser restaurado numa versão anterior . Para verificar a versão do seu SQL Server, digite "SELECT @@version" no editor do SQL Management Studio (Figura 1):         Figura 1: Versão do SQL Server instalada a partir do SQL Management Studio Alguns possíveis resultados, dependendo a versão do SQL Server:   SQL Server 2000      Microsoft SQL Server 2000 - 8.00.760 (...