Como DBA, como eu faria a transição do Oracle para o SQL Server?

Sou um DBA Oracle que também tem experiência com Sybase.

Quais são as principais diferenças arquiteturais e conceituais entre as duas plataformas RDBMS?

Uma resposta semelhante à pergunta do SQL Server-> Oracle aqui seria mais útil.

Eu troquei o trabalho no Oracle e no SQL Server nos últimos anos e escrevi um resumo sobre o caminho inverso aqui. Existem várias diferenças idiomáticas e arquitetônicas, e vários bits de terminologia são usados ​​de maneira diferente pelas comunidades de fornecedores e desenvolvedores / DBA que cercam cada produto.

Arquitetura física

O SQL Server organiza várias coisas de maneira um pouco diferente do Oracle e possui um ou dois conceitos principais que não possuem 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ê conhece a Sybase, eles funcionam da mesma forma que os bancos de dados da Sybase, devido às origens comuns do produto.

• Os grupos de arquivos são aproximadamente equivalentes aos espaços de tabela, embora sejam locais em 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 cópias diferentes de uma linha até que os bloqueios na versão antiga sejam liberados. O SQL Server não tem equivalente direto a um segmento de reversão. Por padrão, não está ativo nos bancos de dados do SQL Server.

• O Tempdb é muito mais usado no SQL Server. O sistema o utiliza para tabelas temporárias e resultados de junção intermediária. Mais sobre o tempdb mais tarde.

• O particionamento de tabela é um pouco mais desajeitado que o Oracle. Você precisa configurar uma função de partição que crie uma chave de partição a partir do que estiver 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 e devolução de partições requer que você configure uma restrição em uma tabela vazia na estrutura correta. A restrição garante que os valores da chave da partição sejam apropriados para a partição que você pretende trocar por ela.

• Exibições materializadas são chamadas exibições indexadas no SQL Server. A GROUP BYcláusula tem um CUBEoperador e a documentação alude 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 suporte a confirmação em duas fases por meio de protocolos de transação XA ou OLEDB.

• Os índices agrupados são um pouco diferentes das tabelas ordenadas por índices no Oracle, pois não exigem que todas as colunas da tabela participem do índice agrupado. Eles são muito mais usados ​​na arquitetura do SQL Server do que os IOTs no Oracle.

• O SQL Server oferece suporte à cobertura de índices, mas não possui índices de junção. Os índices de bitmap não são suportados, embora ele possua um operador de interseção de índice / transformação em estrela que possa calcular interseções sem atingir a tabela de fatos.

• Sequências são uma adição relativamente recente ao SQL Server. As chaves tradicionalmente automáticas são feitas através de colunas de identidade. Você pode carregar valores em uma coluna de identidade set identity_insert on.

Programação

O Idiomatic T-SQL possui algumas diferenças em relação ao PL / SQL idiomático. Funciona de maneira diferente o suficiente para que algumas diferenças paradigmáticas mereçam ser explicadas com mais profundidade.

• T-SQL não tem conceito de pacote. Todos os procedimentos e funções armazenados em um banco de dados vivem em um espaço para nome comum, embora os esquemas possam ser usados ​​para dividir isso, e o espaço para nome seja local em um banco de dados.

• Tenha uma idéia 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 feitas com operações definidas. SELECT INTOO tempdb é minimamente registrado e também minimamente registrado em certos modos de recuperação nos 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 Idiomatic T-SQL usará tabelas temporárias no tipo de funções que você veria variáveis ​​de cursor no PL / SQL, mas fará muito mais uso das operações definidas. As tabelas temporárias podem, no entanto, gerar um código bastante obtuso, portanto, use com cuidado.

• O dicionário de dados do sistema era muito mais obtuso que o do Oracle em versões mais antigas, mas ficou muito melhor com o SQL Server 2005. Embora as ferramentas fornecidas pela Microsoft possuam bastante material de introspecção embutido no SSMS Explorer, ainda vale a pena conhecer o seu ao redor do dicionário de dados. Ele não faz distinção entre ALL, USEReDBA pontos de vista dos objetos de banco de dados, no entanto.

• O SSMS possui um visualizador de plano de consulta incorporado.

• Identificadores no código T-SQL podem ser citados com [] e podem conter todos os tipos de lixo, se citados. No entanto, se pegar você chamar uma coluna 'Direto / Transferência', que vai rasgar seus intestinos para fora.

• O SQL Server possui funções de janela (desde 2005 IIRC), para que você possa fazer pedidos, executar somas e afins em grupos agora.

• O T-SQL não tem equivalente direto CONNECT BY, embora a recursão possa ser feita por meio de CTEs recursivas.

• Se você precisar escrever um código que passe pelos bancos de dados (em oposição aos esquemas de um banco de dados), considere usar sinônimos públicos para alias os objetos para algo local e consulte os aliases no código. Isso evita dependências codificadas nos nomes dos bancos de dados.

• Se você evitar dependências codificadas nos nomes dos bancos de dados, os bancos de dados facilitarão 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ê deseja escapar de um contexto de transação (por exemplo, para falsificar uma transação autônoma para registro de erros à prova de reversão), pode usar um sproc CLR, pois ele pode criar uma conexão local fora do contexto de transação atual.

Segurança

Os logins 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 as '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 de usuário e função sejam mantidas locais 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 logon nos bastidores para autenticar um usuário em uma máquina ou domínio em um logon 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') possui uma espécie de privilégio de superusuário em 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. Os 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) assumem como propriedade o esquema 'dbo', a menos que outro esquema seja fornecido explicitamente.

• As informações de segurança não são mantidas com um 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 de usuário e função sejam mantidos localmente em um banco de dados com um novo recurso '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 de usuário nas tabelas subjacentes podem afetar a exibiçã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 com o 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 possui 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): é uma ferramenta de relatório baseada na Web para publicar relatórios. Os relatórios podem ser criados através 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 programaticamente servidores SSRS.

• Serviços de Integração do SQL Server (SSIS): esta é uma ferramenta ETL fornecida com o SQL Server. Em termos de arquitetura, é 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 para o servidor de banco de dados. Os pacotes SSIS podem ser desenvolvidos com o BIDS e executados independentemente com uma ferramenta de linha de comando chamada DTEXEC.EXE.

• BI Development Studio (BIDS): este é um ambiente visual studio baseado no desenvolvimento de relatórios, pacotes SSIS e cubos SSAS. Se outras ferramentas de desenvolvimento baseadas em VS estiverem instaladas (por exemplo, VS Professional), as ferramentas poderão 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 no conjunto.

• SQL Server Agent: um utilitário de agendamento de tarefas que pode executar tarefas periódicas de um tipo ou outro.

Nosso principal produto funciona no SQL Server e no Oracle. Aqui estão algumas outras diferenças que tivemos que solucionar e talvez seja bom lembrar:

• A manipulação de data e hora é muito diferente: diferentes precisões, diferentes conjuntos de funções para trabalhar

• Seqüências de caracteres vazias são NULLs no Oracle, não no SQL Server

• O tratamento da 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 que tipo de codificação usar.