5 Funcionalidades que poderiam ser retiradas do SQL Server

Boa Noite Pessoal,

Dando uma olhada no blog do Fabiano, vi um post bacana sobre 5 coisas que deveriam ser removidas do SQL Server. Vi também que a idéia começou com o Paul Randal e que rapidamente outros profissionais de SQL Server começaram a escrever suas listas com 5 funcionalidades que deveriam ser removidas (ou ajeitadas) no SQL Server. Achei a idéia interessante e resolvi postar minha sugestão. Não é uma crítica às funcionalidades existentes ou ao produto. É apenas uma lista de coisas que considero dispensáveis.

Full Recovery Model como opção Default

Acho que pelo menos uma vez por dia vejo alguém dizendo: "Meu banco tem 100GB e o log está consumindo 99GB. Como faço para limpar esse Log ? Daqui a pouco vai acabar o espaço em disco e o banco vai parar". Isso só ocorre porque o Recovery Model está como Full (Default) e as entradas do log só vão sumir se um backup for realizado ou se o Recovery Model for alterado (no 2005 e anteriores era possível truncar o log com o BACKUP LOG WITH TRUNCATE_ONLY). Tenho minhas considerações sobre esses procedimentos em "Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE ONLY – Parte I" e "Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE ONLY – Parte II", mas o fato é que a maioria das pessoas que passam por problemas de log não fazem backups de log e por isso não precisam dele. Se o Recovery Model fosse Simple por Default essas pessoas teriam uma vida mais tranquila.

Auto Shrink

Pode até parecer utópico, mas ambiente bem administrado raramente necessita de SHRINK. Qual é o sentido de reduzir o tamanho de um arquivo apenas por reduzir ? Não há melhora de desempenho no banco de dados por conta da redução do espaço não utilizado de um arquivo. O disco continuará o mesmo e sua vida útil também (independente do arquivo ser grande ou pequeno). Há um "inútil" senso de que se o arquivo tiver espaço vazio há desperdício, mas reduzir um arquivo e deixar mais espaço livre no disco não irá fazer com que o disco tenha mais tempo de vida. Não acho correto gastar mais do que o necessário, mas acho completamente errado reduzir um arquivo ao seu tamanho mínimo sabendo que ele irá crescer de novo. Isso só irá aumentar o nível de fragmentação do arquivo, pois, toda vez que ele precisar crescer dificilmente irá utilizar uma área contígua. Com o nível de fragmentação aumentando e o SHRINK ocorrendo a todo instante, as chances do desempenho cair são altas, pois, será necessário que o arquivo cresça e reduza seu tamanho constantemente além de afetar bastante as pesquisas baseadas em RANGE, SORT, etc. Recomendo a leitura do artigo "Auto-shrink: Turn It Off" para conhecer melhor seu comportamento e porque ele deveria ser retirado. O SHRINK tem o seu lugar em algumas situações como expurgo de grandes volumes de dados, eliminação de colunas que liberem muito espaço, etc mas o Auto SHRINK ao meu ver não tem utilidade nenhuma. Se é realmente necessário limpar a todo instante o espaço vazio há um entendimento incorreto de como ele funciona ou um mau dimensionamento do espaço necessário.

Auto Close

A descrição do Books OnLine é a seguinte:

"When set to ON, the database is shut down cleanly and its resources are freed after the last user exits. The database automatically reopens when a user tries to use the database again. When set to OFF, the database remains open after the last user exits."

Em outras palavras, se ela estiver marcada como ON, o SQL Server irá liberar o acesso aos arquivos quando ninguém mais estiver conectado e quando alguém precisar conectar-se novamente, o SQL Server voltará a bloquear os arquivos. Se ela estiver marcada como OFF, o SQL Server sempre irá bloquear os arquivos MDF e LDF de forma exclusiva mesmo que ninguém precise de acesso à base. O problema é que se o SQL Server não bloquear os arquivos (AUTO_CLOSE ON), qualquer um poderá utilizá-los (copiar, renomear, excluir, etc). Quando o SQL Server precisar deles novamente, ou seja, quando alguém for conectar-se à base, se por qualquer razão eles estiverem em uso, o SQL Server poderá colocar a base no estado de Suspect e isso pode ser irreversível. Mesmo para edições como o MSDE e o SQL Server Express que tem essa opção marcada como DEFAULT, eu acredito que o SQL Server deve sim bloquear os arquivos MDF e LDF para uso externo. Não é porque se utiliza a edição Express ou MSDE que os dados deixam de ser importantes.

Server Roles Fixas

Desde o SQL Server 7 (não mexi com o 6.0 e o 6.5) existem as roles fixas de servidor. Ao contrário das roles de banco, não é permitido criar novas roles de servidor. limitando-nos às roles já existentes. A partir do SQL Server 2005 é possível a atribuição de Securables em nível de servidor e assim pode-se por exemplo dar permissão de rodar o Trace a um login específico sem a necessidade de incluí-lo na Role SysAdmin como era o caso do SQL Server 7 & 2000. Isso aumenta as possibilidades na gestão de privilégios, mas não é possível criar um grupo e incluir logins no grupo para evitar concessões individuais. Alguns roles eu até acho úteis como a DBCreator, BulkAdmin e a SysAdmins (é claro), mas outras como DiskAdmin e SetupAdmin eu nunca vi marcadas em nenhum servidor. Com as possibilidades da troca de contexto de execução com a cláusula EXECUTE AS elas perdem ainda mais o sentido. Seria muito interessante se pudéssemos criar roles em nível de servidor e atribuir as permissões desejadas. Isso evitaria darmos mais permissões que o necessário (típico das servers roles fixas como SysAdmin) ou conceder permissões para logins individuais.

Uso da procedure XP_CMDSHELL

Na transição do SQL Server 2000 para o 2005 várias Extended Procedures foram retiradas (xp_makecab, xp_executeresultset, etc), mas a xp_cmdshell ainda permanece. No meu entendimento, um banco de dados deve servir ao seu principal propósito (gravar e recuperar dados). Recursos como xp_cmdshell não se relacionam de forma direta a essas atividades e só abrem brechas de segurança além de deixar alguns implementadores mal acostumados. É inegável que essa stored procedure concede certa flexibilidade como criação de pastas, execução de utilitários como o BCP, SQLCMD ou o DTEXEC, mas uma arquitetura "correta" não delegaria essas atividades para o banco de dados (já vi gente mandando arquivo via FTP e criando usuário no AD com TSQL). Não imagino um desenvolvedor perguntando a um DBA ORACLE qual é o comando PL/SQL que irá dropar arquivos no File System do UNIX ou questionar um DBA DB2 do porquê não é possível utilizar esse SGBD para que ele compacte automaticamente os arquivos de backup com o GZIP em um sistema operacional Linux. Ninguém sequer irá cogitar essa possibilidade, pois, tarefas como criação de pastas, compactação de arquivos ou execução de utilitários nem de longe são atribuições de um banco de dados. Aquelas soluções que utilizam o SQL Server como Middleware e necessitam implementar essas tarefas no SQL Server deveriam considerar o uso do CLR ao invés da xp_cmdshell. É uma alternativa muito mais segura e administrável.

E você ? Qual é a sua lista ? Que cinco coisas você acha desnecessárias no SQL Server ?

[ ]s,

Gustavo

6 Respostas para “5 Funcionalidades que poderiam ser retiradas do SQL Server

  1. Tirar XP_CMDSHELL?! Tá louco!!! rseu sofreria muito sem ele…… xDQuanto ao Auto Close, concordo em gênero, número e grau!

  2. Olá Gustavo,Também vi o post do Fabiano via Feed. Como sabes estou meio cheio de coisas e acabei por postar aqui mesmo fazendo uma ligação com o post do Fabiano.Blog Fabiano – Concordo plenamento com Fabiano quanto aos backups em versões anteriores. Inclusive acho ridículo um backup do 2008 não ser restaurado no 2005.Minhas considerações (não li todos os links citados por Fabiano):1 – Size e autogrow padrão de uma base de dados:Acredito que estas opções deveriam ser obrigatórias na cláusula create database e o valor padrão da base model fosse um pouco maior. Já vi muitas bases de 100 200 GB com crescimento de 1MB (padrão).2 – Cláusula create de objetos:Já está na hora do SQL Server adicionar algo do tipo CREATE OR REPLACE…3 – CDCCampos incluídos após a criação do Change Data Capture não entram na captura. Alterações de campos entram mas onclusão não. Acho que deveria existir a opção de capturar ou não campos incluídos após a configuração do CDC.4 – Maior controle da replicação transacional:Quem usa replicação n SQL Server sabe que, em especial a Transacional, a administração é bem "fechada". Algumas informações úteis não estão disponíveis ao usuário ( onde na merge tenho como saber cada alteração realizada e na transacional não é de forma tão aberta assim )Quanto ao Shrink, vale lembrar que o mesmo fragmenta os índices ( Fonte: Paul Randal, não lembro link agora).Abraços Demétrio Silva

  3. Fabiano Neves

    Boa Gustavo, mas tenho que concordar com o Cléber… Tirar a xp_cmdSheel? … vai perder a graça do banco de dados… seria a mesma coisa que falar… "Acho que deveria remover o comando SHUTDOWN WITH NOWAIT" :-)Abraços

  4. Boa noite Gustavo.Eu só não sou a favor com relação a xp_cmdshell, onde trabalho nós adiministramos os servidores em um datacenter via Terminal Server, ocorre que algumas vezes ao invés de efetuar logoff no server o pessoal simplesmente clica no "X" então a sessão permanece aberta, a única forma que encontrei para resolver esse problema foi usando a xp_cmdshell para derrubar as sessões.Para isso eu execute um script como este:–Habilitando a procedure de sistemasp_configure \’show advanced options\’, 1reconfiguregosp_configure \’xp_cmdshell\’,1goreconfigurego–Executar comandos do DOS, "qualquer" comando DOS será aceito.declare @SQLStr as varchar(200)set @SQLStr = \’query session /server:NOMEDOSERVER\’ –Lista as sessões do TSexec Master..xp_cmdshell @SQLStrgodeclare @SQLStr as varchar(200)set @SQLStr = \’reset session 2 /server:NOMEDOSERVER\’ –Mata a sessão de ID=1exec Master..xp_cmdshell @SQLStr–Desabilitando a procedure de sistema, é fundamental desabilitar a procedure após o procediento.sp_configure \’xp_cmdshell\’, 0reconfiguregosp_configure \’show advanced options\’, 0reconfiguregoQuanto a sugestões eu postei no Microsoft Connect uma para criar uma espécie de lixeira para objetos dropados (algo parecido com o que temos no Oracle 10g +). Segue o link:http://connect.microsoft.com/SQLServer/feedback/details/550445/implementing-a-trash-like-function-for-dropped-objectsNo mais concordo com você.Abraço,Ricardo Muramatsu

  5. Oi Pessoal,Bons comentário e ótimas idéias. Se essa nossa Wish list for atendida seria ótimo.Eu acho a xp_cmdshell útil. Se ele ficasse pelo menos restritas a algumas tarefas administrativas e com limitação de uso (com uma DAC por exemplo), ia ser interessante mantê-la. O problema é que "vicia" e aí se começa a desenvolver em cima dela. Quando vejo um negócio igual ao do link http://social.msdn.microsoft.com/Forums/pt-BR/520/thread/e5ef374c-6887-461a-bc80-ffeb58eb05b4 aí realmente dá vontade de arrancá-la fora…[ ]s,

  6. Olá Gustavo, muito bom o artigo, concordo com voce em partes com relação ao xp_cmdshell. Acho que deveria ser melhor gerenciado quando as restrições. Assim como varias outras xp (deletar arquivos por exemplo)
    .Porem, muitas funcionalidade só são possivel com essa função.

    Duvida : AUTO_CLOSE interfere no backup ?

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s