Funcionalidades do SQL Server que fazem falta no Oracle

0576.sql-server

Eu sempre digo que não gosto da pergunta “qual é o melhor banco de dados?”, por que não gosto da resposta. É o mesmo que perguntar qual é o melhor carro. Depende do que você quer fazer.

Também não gosto das explicações simplistas e não científicas “o banco de dados X é mais parrudo” ou “banco X é mais indicado para grandes empresas”. Aliás, vários dos itens desta lista são a habilidade de alterações em reiniciar a instância, o que geralmente é requisito para uma aplicação importante de grande empresa…

Aliás, veja quem é o SGBD campeão dos Benchmarks TPC-H e TPC-E.

Em minha experiência, o Oracle Database é o banco de dados com o conjunto mais avançado de funcionalidades (Oracle RAC, ASM, AWR), e com os melhores cenários sobre paradigmas de escalabilidade (ausência de Lock Escalation, Leitores nunca bloqueiam Gravadores e vice-versa). Por outro lado, parece ser o produto com pior qualidade de código, com literalmente milhares de Bugs a cada release. Pode ser que o segundo ponto seja consequência do primeiro.

Como minha base de conhecimento é em Oracle Database (embora meu primeiro SGBD tenha sido o SQL Server 6.5), sou suspeito para fazer uma lista defendendo o Oracle. Então resolvi fazer uma lista das coisas que o Microsoft SQL Server tem, que dão inveja a qualquer DBA Oracle.

Irei implementando esta lista conforme eu for lembrando dos itens.

 

– O SQL Server Management Studio, claro. Seu par no Oracle é o SQL Developer (e não o Enterprise Manager / Enterprise Manager Express / Grid Control / Cloud Control), que está uns 10 – 15 anos atrás em usabilidade.

– Aumentar memória sem reiniciar. A propósito memória automática (SGA_TARGET) do Oracle só surgiu em 2003, com o 10g;

– Aumentar limite de conexões sem reiniciar. Aliás, o padrão é não ter limite;

– Alterar o modo de proteção (Full  / Bulk / Simple) sem reiniciar, ao contrário do ARCHIVELOG / NOARCHIVELOG;

– O Shink Database. Sua implementação pode trazer fragmentação física, mas que falta ele faz quando não há espaço algum. Acho que todo DBA ficou executando RESIZE várias vezes seguidas por DATAFILE, e enfim tendo que executar um MOVE e REBUILD, tentando conseguir algum espaço;

– Um Redo Log não circular (o Transaction Log), o que causa o tão comum “checkpoint incomplete”;

– Formatação de discos em 64k, ideal para BI. Utilizando os blocos de 8k, uma única leitura física lê 8 blocos. Esta funcionalidade não é do SQL Server, mas sim do Windows, mas não existe no ext4 (apenas no xfs, que passou a ser o padrão no RHEL / OEL 7);

– Dettach / Attach. Sim, esta funcionalidade chegou no 12c, mas ela existe desde que o SQL Server existe, acho. Torna uma migração de Storage, por exemplo, muito mais simples do que o Transportable Tablespace.

– Auto Update Statistics, que ainda fornece ao DBA a opção de ser síncrona ou assíncrona.

– Mais um item que não do SQL Server, mas sim do Windows: o sistema de gerenciamento de serviços init, o padrão do RHEL / OEL (os Linux largamente mais utilizados para Oracle Database) até a versão 6, é simples e elegante, mas no mundo de múltiplos processadores, serviços, e até múltiplas VMs, já passou sua época. O sistema de gerenciamento de serviços do Windows permite inicialização paralela, configuração de dependências, modo de recuperação, e controle de segurança, enquanto o init é apenas um monte de scripts executados de forma serial. O padrão do RHEL / OEL 7 passará a ser o systemd, e este sim possui funcionalidades avançadas.

A proveitando o Post, uma funcionalidade do Sybase ASE que faz falta no Oracle: mirror de device. Um device no Sybase ASE é o equivalente a um datafile no Oracle: Mirror de Device no Sybase.

22 comments

  1. Muito legal o post…

    Mas de algumas coisas eu discordo, por exemplo:

    – Um Redo Log não circular (o Transaction Log), o que causa o tão comum “checkpoint incomplete”;

    Eu prefiro uma estrutura circular, veja que o redo log file é um estrutura do todo (bem menos em termos de dimensão que o Transaction Log), imagine esta estrutura linear em um mesmo disco (Sem stripe) ou em RAID 5, deve desastroso, além do esforço administrativo (Ter que implementar job de limpeza ou se preocupar em usar um job nativo, sei la…). Na própria geometria elementar, que aprendemos no ensino médio, dá para concluir que estruturas lineares só é vantajoso se essas não forem reutilizáveis ou sofrerem dilatações. Talvez se o Transaction Log não crescer excessivamente parece ser atrativo (Não conheço muito de SQL Server).

    – Formatação de discos em 64k, ideal para BI. Utilizando os blocos de 8k, uma única leitura física lê 8 blocos. Esta funcionalidade não é do SQL Server, mas sim do Windows, mas não existe no ext4 (apenas no xfs, que passou a ser o padrão no RHEL / OEL 7);
    Não conheço muito de Windows, mas o ext4 introduziu um conceito de extent, não é similar?

    – Dettach / Attach. Sim, esta funcionalidade chegou no 12c, mas ela existe desde que o SQL Server existe, acho. Torna uma migração de Storage, por exemplo, muito mais simples do que o Transportable Tablespace.
    Não dá para fazer isso a nível de SO ? (Desmontar de um lado e montar em outros?)
    Do ponto de vista de migração, isso pode ser compreensível, pq o SQL Server é Uni-plataforma, certo ?

    Abraços, Portilho.
    Feliz 2015.

    1. Oi Carlos!

      – Redo Log: O Transaction Log do SQL Server é ao mesmo tempo equivalente ao Redo e o Archive do Oracle, então ele cresce conforme a quantidade e tamanho de alterações. O job de limpeza necessário para ele (Backup de Transaction Log) é o mesmo trabalho que daria um Job de limpeza de Archives.
      O ponto contra do Transaction Log, para mim, é a ausência de multiplexação.

      – Formatação: Não é a mesma coisa, Extents são conjuntos de blocos, a intenção é reduzir a quantidade de metadados. Mas sobre desempenho, veja o que achei em https://ext4.wiki.kernel.org:
      Currently, the ext2/ext3 filesystem, like other traditional UNIX filesystems, uses a direct,
      indirect, double indirect, and triple indirect blocks to map file offsets to on-disk blocks.
      This scheme, sometimes simply called an indirect block mapping scheme, is not efficient for
      large files, especially large file deletion. In order to address this problem, many modern
      filesystems (including XFS and JFS on Linux) use some form of extent maps instead of the
      traditional indirect block mapping scheme.
      Since most filesystems try to allocate blocks in a contiguous fashion for performance reasons,
      extent maps are a more efficient way to represent the mapping between logical and physical
      blocks for large files. An extent is a single descriptor for a range of contiguous blocks,
      instead of using hundreds of entries to describe hundreds of blocks individually.

      – Dettach / Attach: No Oracle dá sim para fazer pelo SO, mas no SQL Server não é necessário um RENAME (se trocar o PATH) nem nada parecido.

      1. Legal…

        Imaginava que o Transaction Log era uma estrutura similar somente ao redo log, sem o archive. Neste caso, realmente é mais vantajoso ! Em relação a formatação, realmente é um belo de um recurso, deu um lida e gostei bastante.

        Parabéns pelo posto, esta fantástico como sempre !

        Abraços.

  2. Excelente post! Sou analfabeto em SQL Server!

    A única consideração que eu faria é sobre o tópico de migração de storages: se os servidores forem os mesmos, o rebalance no ASM são espetaculares!

    Agora se você considerar a migração para novos servidores, com certeza o detach/attach fazem toda a diferença!

    Parabéns pelo excelente trabalho, Portilho!

    1. Obrigado Vinicius!
      O tipo de migração a que eu me referia era “do D: para o E:”, ou “do /u01 para o /u02”. Outro ponto a lembrar é que eu vejo essa funcionalidade no SQL Server desde o 6.5, o primeiro que eu vi. Acho que foi em 1998.

  3. Opa, perfeito!

    Sim, desta forma o detach/attach faz toda a diferença.

    Se bem que um backup as copy do RMAN também é bastante prático né, só fazer o switch para a cópia depois. Tempo de parada pequeno também. Mas enfim, de fato é uma funcionalidade bastante antiga no SQL Server!

    Grande abraço!

    1. Isso, e o BACKUP AS COPY ainda precisa do RECOVER. Se o comando BACKUP levou uma hora, é uma hora de Archives (não de relógio) a aplicar.

  4. Excelente post, Portilho !

    Minha formação é em Oracle, mas também atuo com com ambientes SQL Server e, realmente, são funcionalidades que fazem falta num ambiente Oracle.

  5. Muito legal este post, Portilho, ainda mais vindo de um DBA “Oracle” – já que, como sabemos, uma boa parte dos colegas são “xiitas” a ponto de sequer tentar conhecer outros SGDBS. Este tipo de post ajuda a quebrar paradigmas.

    Enfim, eu apontaria também: rename de banco de dados ou alteração de owner online, backups finalizados por completo, e recursos avançados já inclusos na versão Enterprise, sem necessidade de comprar à parte.

    E, também gosto muito da opção de Dettach / Attach .

    Abçs,
    Lílian

    1. Obrigado pela colaboração Lilian. Eu adicionaria ainda ao item dos recursos Enterprise, a complexidade do licenciamento Oracle x SQL Server.

      Abraço 1

  6. Em Relação a um Ponto ou Outro Talvez você até tenha Razão, mas de cabeça acho que existem algumas observações
    – Quanto as Estatísticas Automáticas
    Estatísticas Automaticas No Oracle podem ser habilitadas através do GATHER_STATS_JOB.
    – Alocação de 64K
    A ASM suporta AU de até 64MB e isso independe da Blocagem do Filesystem.
    – Aumentar Limites de Conexões
    O SQLServer Trabalha exclusivamente com Threads, o que seria similar a trabalhar no Oracle com Shared_servers e ai na teoria o Ceu é o Limite mas isso pode causar um problema de LOAD em ambientes UNIX e ai travar a máquina
    – Mirror de Device?
    Não vejo porque utilizar isso se existem 3 Níveis de Stripe no ASM
    – Checkpoint Incomplete
    Isso indica que alguém não fez o trabalho direito e configurou a quantidade e tamanho adequados de REDOLOG.

    1. Seguem abaixo minhas observações a respeito de suas observações: 😀

      – Quanto as Estatísticas Automáticas
      Estatísticas Automaticas No Oracle podem ser habilitadas através do GATHER_STATS_JOB.
      Resposta: Pelo GATHER_STATS_JOB, as estatísticas são coletadas na janela de coleta. No SQL Server, esta coleta é executada imediatamente (de forma síncrona ou assíncrona). Esta é a diferença. Por exemplo, no Oracle, se às 08:00 (após a janela de coleta do GATHER_STATS_JOB) uma tabela sofrer uma grande alteração, as estatísticas ficarão erradas até a próxima janela de coleta.

      – Alocação de 64K
      A ASM suporta AU de até 64MB e isso independe da Blocagem do Filesystem.

      Resposta: Correto, se for utilizado ASM (o ASM não usa filesystem).

      – Aumentar Limites de Conexões
      O SQLServer Trabalha exclusivamente com Threads, o que seria similar a trabalhar no Oracle com Shared_servers e ai na teoria o Ceu é o Limite mas isso pode causar um problema de LOAD em ambientes UNIX e ai travar a máquina.

      Resposta: O problema não é a quantidade de conexões suportada, e sim ter que parar a instância para alterar este limite. Continua sendo necessário parar o Oracle para aumentar o limite de conexões, sendo SHARED ou não. A propósito, o Oracle permite conexões por threads no 12c (THREADED_EXECUTION).

      – Mirror de Device?
      Não vejo porque utilizar isso se existem 3 Níveis de Stripe no ASM
      Resposta: Por exemplo, para mover um DATAFILE do /u01 para o /u02 (ou do +DATA01 para o +DATA02), de forma online. Ou até mesmo um REDO LOG.

      – Checkpoint Incomplete
      Isso indica que alguém não fez o trabalho direito e configurou a quantidade e tamanho adequados de REDOLOG.
      Resposta: A diferença continua, no SQL Server este trabalho não precisa ser executado, e nem reavaliado em caso de mudança na carga. O mesmo argumento poderia ser utilizado para o item de quantidade de conexões (“alguém não fez o trabalho direito e não colocou o limite de conexões corretamente”), mas aí é que está, este trabalho inexiste no SQL Server.

      1. Mover um Redolog? Não tem necessidade… Basta você adicionar um novos grupos no novo caminho, fazer o switch depois deletar os antigos.

        Estatísticas Automáticas eu não vejo como vantagem principalmente em ambientes com tabelas muito grandes. Já que isso impediria de fazer um backup de estatísticas para garantir que no caso de uma mudança brusca de performance eu possa restaurar as estatísticas anteriores. E além disso para ambientes críticos as estatísticas padrão não são suficientes para dar inteligência que o otimizador precisa. Como por exemplo no caso de histogramas.

        Em Relação ao Mirror de Device eu não entendi porque a correlação já que você mencionou na resposta a movimentação de datafile de um filesystem pra outro. Aí realmente o Oracle antes da versão 12 não consegue fazer isso totalmente online. Agora se for pra migrar de storage como você menciona no Attach, já migrei um database de 4TB inteiro de storage sem o usuário nem perceber usando ASM. Pra mim o Grande problema é que alguns ainda insistem em usar filesystem para o Oracle. No datacenter já banimos essa prática.

        Enfim, minha praia não é SQLServer, sempre trabalhei com DB2 e com Oracle. Os únicos Tópicos que tenho uma tendência em concordar são em relação às conexões e à ferramenta de administração, pois não sou muito fã da Interface Web, mas isso não me faz falta porque sempre usei o Toad e muitas vezes prefiro o sqlplus.

        E sinceramente prefiro a granularidade e um leque maior de possibilidades, que justamente fazem a diferença em ambientes mais críticos.

        Mas respeito sua opinião!

        1. Concordo com você a respeito do Restore de Estatísticas, não conheço se essa possibilidade existe no SQL Server.

          O Mirror de Device permite migração de caminhos (e não de discos) online, pois você adiciona um Mirror do +DATA02, e remove o Mirror do +DATA01. Isto como você disse, só é possível no 12c, mas o método do Move do Oracle é péssimo: ele faz sequential read, de bloco a bloco, e não uma cópia como um Mirror. Fiz um teste movendo um DATAFILE de 1GB, em uso, e levou 8 horas.

          Eu também prefiro ASM, só vejo vantagens sobre Filesystem, mas nem sempre o encontro.

    1. Sobre as reações, é engraçado (por favor, não estou falando sobre o Maiko), o que mais se vê por aí é o DBA que só conhece o produto A, mas acha ele melhor que o B.
      – Qual a melhor fruta, na sua opinião?
      – A banana, com toda certeza. Tem a vitamina A, C, potássio, e mais um monte de coisas.
      – E sobre a maçã, o que você acha dela?
      – Não gosto da maçã, ela não tem potássio.
      – Tem sim.
      – Tem? Ah, mas aquela casca vermelha dela, parece algo bem ruim…
      – Como assim parece? Você nunca provou?
      – Não, mas eu já um cara provando, e isto já basta. E olha só quanta gente comendo banana você vê por aí, eles não podem estar errados. E se maça fosse boa a bruxa da branca de neve não tinha usado ela.

  7. Fantástico seu post Portilho. Acho muito interessante o conhecimento e a mente aberta para outros SGBD’s. Sou contra o fanatismo!

  8. Uma coisa que, particularmente, acho demais no SQL Server, é o fato dos metadados ficarem armazenados no próprio database, o que permite o attach/detach, além de propiciar o modo full apenas para bases necessárias, ao contrário do Orcle, que se existir um schema de teste junto com produção, irá gerar redo e archives. Outra vantagem dessa arquitetura é o fato de se dropar bases muito rapidamente, em contrapartida ao Oracle, que precisa desalocar os metadados da System. São particularidades destes dois SGBDs fantásticos. Gosto dos 2.

    1. Oi Bruno.
      Sobre os metadados no próprio database (e o consequente Attach/Dettach), é a ideia da arquitetura MultiTenant do 12c.
      Sobre o Recovery Model do SQL Server, no Simple sempre será gerado Redo (Transaction Log), mas ao término de uma transação, o Log para de crescer e pode ser reutilizado. Mas se você fizer uma transação de 1TB, continuará gerando 1TB de “Redo”.
      No Oracle o ARCHIVELOG só pode ser definido de forma global, mas o modo LOGGING (que equivale ao modo Bulk-logged do SQL Server) tem uma granularidade maior ainda, pois pode ser aplicado em nível de objeto (apenas uma tebale em NOLOGGING).
      Sobre remover DATABASEs / SCHEMAs, não considero uma vantagem (não se faz isso toda hora), e sim apenas uma característica.
      A propósito da SYSTEM, você pode perder a “SYSTEM” do SQL Server (o database master), e recuperar-se, sem backup. Já no Oracle, não.

      Muito obrigado por adicionar mais a nossa discussão!

Leave a Reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.