Sou um DBA Oracle que também possui experiência em Sybase.
Quais são as principais diferenças arquitetônicas e conceituais entre as duas plataformas RDBMS?
Uma resposta semelhante à pergunta SQL Server->Oracle aqui seria mais útil.
Sou um DBA Oracle que também possui experiência em Sybase.
Quais são as principais diferenças arquitetônicas e conceituais entre as duas plataformas RDBMS?
Uma resposta semelhante à pergunta SQL Server->Oracle aqui seria mais útil.
Eu troquei entre trabalhar no Oracle e no SQL Server nos últimos anos e escrevi uma sinopse sobre o caminho inverso aqui. Há várias diferenças idiomáticas e arquitetônicas, e várias partes da terminologia são usadas de maneira diferente pelas comunidades de fornecedores e desenvolvedores/DBA em torno de cada produto.
Arquitetura física
O SQL Server organiza várias coisas de maneira um pouco diferente do Oracle e tem um ou dois conceitos-chave que não têm análogos diretos no Oracle.
Um 'Banco de dados' é um item separado no SQL Server, com suas próprias permissões de usuário, esquemas/espaços de nome e armazenamento. Se você estiver familiarizado com o Sybase, eles funcionam da mesma forma que os bancos de dados do Sybase, devido às origens comuns do produto.
Grupos de arquivos são aproximadamente equivalentes a espaços de tabelas, embora sejam locais para um banco de dados.
Um esquema é um conceito distinto de um usuário de banco de dados no SQL Server, embora os usuários possam ter um esquema padrão.
O MVCC funciona de maneira um pouco diferente no SQL Server. É um recurso relativamente recente, mantendo diferentes cópias de uma linha até que os bloqueios da versão antiga sejam liberados. O SQL Server não tem equivalente direto a um segmento de reversão. Ele não está ativo por padrão nos bancos de dados do SQL Server.
Tempdb é muito mais usado no SQL Server. O sistema o utiliza para tabelas temporárias e resultados de junções intermediárias. Mais sobre tempdb mais tarde.
O particionamento de tabela é um pouco mais desajeitado do que o Oracle. Você precisa configurar uma função de partição que crie uma chave de partição de tudo o que você está fornecendo e, em seguida, um esquema de partição sobre essa função de partição. O esquema de partição se comporta um pouco como um grupo de arquivos em que você cria a tabela no esquema de partição.
A troca de partições para dentro e para fora exige que você configure uma restrição em uma tabela vazia na estrutura correta. A restrição garante que os valores da chave de partição sejam apropriados para a partição que você pretende trocar por ela.
As exibições materializadas são chamadas de exibições indexadas no SQL Server. A
GROUP BY
cláusula tem umCUBE
operador e a documentação faz alusão a um recurso de reescrita de consulta. No entanto, essa funcionalidade não está bem documentada e pode não estar muito madura. YMMV.O SQL Server não oferece suporte a transações autônomas, embora ofereça suporte a confirmação de duas fases por meio de protocolos de transação XA ou OLEDB.
Os índices clusterizados são um pouco diferentes das tabelas ordenadas por índice no Oracle, pois não exigem que todas as colunas da tabela participem do índice clusterizado. Eles são muito mais usados na arquitetura do SQL Server do que os IOTs no Oracle.
O SQL Server oferece suporte a índices de cobertura, mas não possui índices de junção. Índices de bitmap não são suportados, embora tenha um operador de conversão de estrela/interseção de índice que pode calcular interseções sem acessar a tabela de fatos.
As sequências são uma adição relativamente recente ao SQL Server. Tradicionalmente, as chaves de autoincremento são feitas por meio de colunas de identidade. Você pode carregar valores em uma coluna de identidade por meio de
set identity_insert on
.Programação
O T-SQL idiomático tem algumas diferenças em relação ao PL/SQL idiomático. Funciona de maneira diferente o suficiente para que algumas das diferenças paradigmáticas mereçam uma explicação mais profunda.
T-SQL não tem conceito de pacote. Todos os procedimentos e funções armazenados em um banco de dados vivem em um namespace comum, embora esquemas possam ser usados para quebrar isso, e o namespace é local para um banco de dados.
Tenha uma ideia de como usar tabelas temporárias e
SELECT INTO
. É muito raro encontrar código T-SQL que realmente precise de um cursor; as tabelas temporárias permitem que as operações sejam divididas em etapas que podem ser executadas com operações definidas.SELECT INTO
em tempdb é minimamente registrado, e é minimamente registrado em certos modos de recuperação em bancos de dados do usuário, portanto, é tão rápido quanto o operador de consulta que persiste em um resultado de junção intermediário.O T-SQL idiomático usará tabelas temporárias no tipo de função que você veria em variáveis de cursor em PL/SQL, mas fará muito mais uso de operações definidas. As tabelas temporárias podem, no entanto, criar um código bastante obtuso, portanto, use com cuidado.
O dicionário de dados do sistema era muito mais obtuso do que o da Oracle em versões mais antigas, mas ficou muito melhor com o SQL Server 2005. Embora as ferramentas fornecidas pela Microsoft tenham bastante material de introspecção incorporado no explorador do SSMS, ainda vale a pena conhecer o seu maneira de contornar o dicionário de dados. No entanto, ele não diferencia entre
ALL
,USER
eDBA
visualizações dos objetos do banco de dados.O SSMS possui um visualizador de plano de consulta integrado.
Os identificadores no código T-SQL podem ser citados com [] e podem conter todos os tipos de lixo se citados. No entanto, se pegarmos você chamando uma coluna de 'Direta/Transferência', arrancaremos seus intestinos.
O SQL Server tem funções de janela (desde 2005 IIRC), então você pode fazer pedidos, executar somas e afins dentro de grupos agora.
T-SQL não tem equivalente direto para
CONNECT BY
, embora a recursão possa ser feita por meio de CTEs recursivas.Se você precisar escrever um código que salte entre bancos de dados (ao contrário de esquemas dentro de um banco de dados), considere o uso de sinônimos públicos para alias dos objetos para algo local e consulte os aliases no código. Isso evita dependências codificadas em nomes de banco de dados.
Se você evitar dependências codificadas em nomes de banco de dados, os bancos de dados facilitam bastante a manutenção de vários ambientes no mesmo servidor.
Algumas coisas, como funções agregadas personalizadas, só podem ser implementadas usando sprocs CLR. Além disso, se você quiser escapar de um contexto de transação (por exemplo, para falsificar uma transação autônoma para registro de erros à prova de reversão), você pode usar um sproc CLR, pois ele pode criar uma conexão local fora do contexto de transação atual.
Segurança
Os logons são definidos no nível da instância do SQL Server, mas cada logon é mapeado para zero ou mais bancos de dados como um 'usuário do banco de dados'. As permissões podem ser atribuídas a 'logins' (servidor) e 'usuários' (banco de dados), mas em um banco de dados 'funções' são normalmente usadas. Os usuários pertencem a funções, as permissões são atribuídas a funções. O SQL Server 2012 adiciona 'funções de servidor'.
O SQL Server 2012 apresenta um conceito chamado 'bancos de dados parcialmente contidos', que permite que as informações do usuário e da função sejam mantidas localmente nesse banco de dados.
Dentro de um banco de dados, o conceito de usuário e esquema é separado. Um usuário ou função pode ser atribuído a um esquema e um esquema possui objetos de banco de dados.
A autenticação do Windows usa informações de login nos bastidores para autenticar um usuário em uma máquina ou domínio para um login do SQL Server. O suporte do IIRC para isso é um extra opcional no Oracle.
Uma função especial, 'dbo' (abreviação de 'proprietário do banco de dados') tem uma espécie de privilégio de superusuário dentro de um banco de dados específico. Cada banco de dados tem uma função 'dbo' e os usuários podem ser atribuídos à função 'dbo' em um determinado banco de dados.
Há também um esquema 'dbo' padrão. Objetos podem pertencer ao esquema dbo - Objetos criados por usuários com a função 'dbo' (ou permissões de administrador em todo o sistema) serão padronizados como pertencentes ao esquema 'dbo', a menos que outro esquema seja fornecido explicitamente.
As informações de segurança não são mantidas com backup de um único banco de dados. Os usuários e as funções devem ser configurados explicitamente no servidor para o qual o backup é restaurado. O SQL Server 2012 permite que os dados do usuário e da função sejam mantidos localmente em um banco de dados com um novo recurso de 'bancos de dados parcialmente contidos'.
No SQL Server 2005, os procedimentos armazenados podem ser executados no contexto de segurança do chamador, do criador, do esquema proprietário ou de um usuário especificado.
Em uma exibição no SQL Server, as permissões nas tabelas subjacentes são baseadas nas permissões do esquema que possui a exibição. As permissões de usuário nas tabelas subjacentes não participam da segurança, embora uma definição de exibição possa incluir filtros que obtêm informações da sessão. No Oracle, as permissões do usuário nas tabelas subjacentes podem afetar a visualização, dependendo da configuração das concessões.
Monitoramento e ajuste
TBA - arquitetura de memória vs. SGA etc. no oracle
Restaurar e recuperar
TBA
ferramentas
A Microsoft agrupa um conjunto de ferramentas ao redor do SQL Server. Alguns dos principais itens fornecidos são:
SQL Server Management Studio (SSMS): faz algo semelhante ao SQL Developer no Oracle - fornece um editor e um recurso de execução de código. Alguns recursos úteis incluem um navegador de objetos de banco de dados e um visualizador de plano de consulta.
SQL Server Analysis Services (SSAS): Este é um servidor OLAP distinto do servidor de banco de dados. Ele usa sua própria linguagem de consulta (MDX) e API (XML/A) para comunicação cliente-servidor. Não pode ser consultado com SQL. O SSMS tem um recurso para editar consultas MDX e XMLA brutas e exibir os resultados. Uma ferramenta de consulta de linha de comando chamada ASCMD.EXE também é fornecida.
SQL Server Reporting Services (SSRS): Esta é uma ferramenta de relatórios baseada na Web para publicação de relatórios. Os relatórios podem ser criados por meio do BI Development Studio (BIDS) ou do Report Builder e publicados em um portal da web. O próprio servidor SSRS possui uma API de serviço da Web para gerenciar programaticamente o servidor. Observe que os relatórios do SSRS podem consumir dados de várias fontes, não apenas do SQL Server. Uma ferramenta de linha de comando chamada RS.EXE é fornecida para gerenciar servidores SSRS programaticamente.
SQL Server Integration Services (SSIS): Esta é uma ferramenta ETL fornecida com o SQL Server. Arquitetonicamente, é bem diferente do OWB ou ODI, pois não é uma ferramenta de geração de código. O tempo de execução fica no lado do cliente e pode estar em uma máquina separada do servidor de banco de dados. Os pacotes SSIS podem ser desenvolvidos com BIDS e executados independentemente com uma ferramenta de linha de comando chamada DTEXEC.EXE.
BI Development Studio (BIDS): Este é um ambiente baseado em estúdio visual para desenvolver relatórios, pacotes SSIS e cubos SSAS. Se outras ferramentas de desenvolvimento baseadas em VS estiverem instaladas (por exemplo, VS Professional), as ferramentas podem ser integradas em um único ambiente e em um agrupamento de projeto comum.
Cópia em massa (BCP): Uma ferramenta de inserção/extração em massa de linha de comando semelhante ao SQL*Loader
SQLCMD: Uma ferramenta de consulta de linha de comando semelhante ao SQL*plus
SQL Profiler: Uma ferramenta de rastreamento e criação de perfil que pode capturar e avaliar informações de rastreamento do SQL Server, SSAS e outras ferramentas do pacote.
SQL Server Agent: Um utilitário de agendamento de trabalho que pode executar trabalhos periódicos de um tipo ou outro.
Nosso principal produto funciona tanto no SQL Server quanto no Oracle, aqui estão algumas outras diferenças que tivemos que contornar e pode ser bom ter em mente:
A manipulação de data e hora é muito diferente: diferentes precisões, diferentes conjuntos de funções para trabalhar
Strings vazias são NULLs no Oracle, não no SQL Server
A manipulação de codificação de caracteres e Unicode é muito diferente. No SQL Server você pode ter colunas normais (
varchar
) ou Unicode (nvarchar
) misturadas no mesmo banco de dados, no Oracle você decide no nível do banco de dados qual tipo de codificação usar.