En tant que DBA, comment procéder pour passer d’Oracle à SQL Server?

Je suis un administrateur de base de données Oracle qui possède également une expérience Sybase.

Quelles sont les principales différences architecturales et conceptuelles entre les deux plates-formes de SGBDR?

Une réponse similaire à la question SQL Server-> Oracle ici serait la plus utile.

Au cours des dernières années, j'ai alterné travail sur Oracle et SQL Server, et rédigé un texte de synthèse indiquant le contraire . Il existe un certain nombre de différences idiomatiques et architecturales, et divers éléments de terminologie sont utilisés différemment par les communautés de fournisseurs et de développeurs / administrateurs de base de données entourant chaque produit.

Architecture physique

SQL Server organise différentes choses un peu différemment par rapport à Oracle et comporte un ou deux concepts clés qui n'ont pas d'analogues directs dans Oracle.

• Une "base de données" est un élément distinct de SQL Server, doté de ses propres autorisations utilisateur, espaces de nom / schéma et espace de stockage. Si vous connaissez Sybase, leur fonctionnement est sensiblement identique à celui des bases de données Sybase, en raison des origines communes du produit.

• Les groupes de fichiers sont à peu près équivalents aux espaces table, bien qu'ils soient locaux à une base de données.

• Un schéma est un concept distinct d'un utilisateur de base de données dans SQL Server, même si les utilisateurs peuvent avoir un schéma par défaut.

• MVCC fonctionne un peu différemment dans SQL Server. Il s'agit d'une fonctionnalité relativement récente, qui conserve différentes copies d'une ligne jusqu'à la libération des verrous de l'ancienne version. SQL Server n'a pas d'équivalent direct à un segment d'annulation. Il n'est pas actif par défaut sur les bases de données SQL Server.

• Tempdb est beaucoup plus utilisé dans SQL Server. Le système l'utilise pour les tables temporaires et les résultats de jointure intermédiaires. Plus sur tempdb plus tard.

• Le partitionnement de table est un peu plus maladroit que Oracle. Vous devez configurer une fonction de partition qui crée une clé de partition à partir de ce que vous fournissez, puis un schéma de partition sur cette fonction de partition. Le schéma de partition se comporte un peu comme un groupe de fichiers car vous créez ensuite la table sur le schéma de partition.
  
  Pour échanger des partitions, vous devez définir une contrainte sur une table vide dans la structure appropriée. La contrainte garantit que les valeurs de clé de partition sont appropriées à la partition que vous souhaitez y basculer.

• Les vues matérialisées sont appelées vues indexées dans SQL Server. La GROUP BYclause a un CUBEopérateur et la documentation fait allusion à une fonctionnalité de réécriture de requête. Cependant, cette fonctionnalité n'est pas bien documentée et peut ne pas être terriblement mature. YMMV.

• SQL Server ne prend pas en charge les transactions autonomes, bien qu'il prenne en charge la validation en deux phases via les protocoles de transaction XA ou OLEDB.

• Les index clusterisés diffèrent légèrement des tables ordonnées par index dans Oracle, car ils ne nécessitent pas que toutes les colonnes de la table participent à l'index cluster. Ils sont beaucoup plus largement utilisés dans l'architecture SQL Server que les IOT dans Oracle.

• SQL Server prend en charge les index de couverture, mais n'a pas d'index de jointure. Les index bitmap ne sont pas pris en charge, bien qu’il dispose d’un opérateur de transformation intersection / étoile qui peut calculer les intersections sans toucher à la table de faits.

• Les séquences constituent un ajout relativement récent à SQL Server. Traditionnellement, les clés auto-incrémentées sont effectuées via des colonnes d'identité. Vous pouvez charger des valeurs dans une colonne d'identité via set identity_insert on.

Programmation

Idiomatic T-SQL présente quelques différences par rapport à PL / SQL idiomatique. Cela fonctionne assez différemment pour que certaines des différences paradigmatiques méritent d’être expliquées plus en profondeur.

• T-SQL n'a pas de concept de package. Toutes les procédures et fonctions stockées dans une base de données résident dans un espace de noms commun, bien que des schémas puissent être utilisés pour le décomposer et que cet espace de noms soit local à une base de données.

• Découvrez comment utiliser les tables temporaires, et SELECT INTO. Il est assez rare de rencontrer du code T-SQL qui nécessite un curseur; les tables temporaires permettent de diviser les opérations en étapes pouvant être effectuées avec les opérations définies. SELECT INTODans tempdb, la journalisation est minimale et dans certains modes de récupération des bases de données utilisateur également; elle est donc aussi rapide que l'opérateur de requête qui persiste dans un résultat de jointure intermédiaire.
  
  Idiomatic T-SQL utilisera des tables temporaires dans le type de rôles que vous verriez les variables de curseur dans PL / SQL, mais fera beaucoup plus usage des opérations définies. Les tables temporaires peuvent toutefois constituer un code assez obtus, utilisez-les avec précaution.

• Le dictionnaire de données système était beaucoup plus obtus que celui d’Oracle sur les versions antérieures, mais il s’est beaucoup amélioré avec SQL Server 2005. Bien que les outils fournis par Microsoft intègrent de nombreuses fonctions d’introspection intégrées dans l’explorateur SSMS, il est toujours utile de connaître votre contourner le dictionnaire de données. Il ne fait pas de distinction entre ALL, USERet DBAvues des objets DB, cependant.

• SSMS a un visualiseur de plan de requête intégré.

• Les identifiants dans le code T-SQL peuvent être cités avec [] et peuvent contenir toutes sortes de déchets s'ils sont cités. Cependant, si nous vous interpellons en train d' appeler une colonne 'Direct / Transfert', nous allons vous arracher les intestins.

• SQL Server a des fonctions de fenêtre (depuis 2005 IIRC), vous pouvez donc maintenant commander, exécuter des sommes et autres choses au sein de groupes.

• T-SQL n'a pas d'équivalent direct CONNECT BY, bien que la récursivité puisse être effectuée via des CTE récursifs.

• Si vous devez écrire du code qui traverse plusieurs bases de données (par opposition aux schémas d'une base de données), envisagez d'utiliser des synonymes publics pour aliaser les objets avec quelque chose de local et vous référer aux alias du code. Cela évite les dépendances codées en dur sur les noms de bases de données.

• Si vous évitez les dépendances codées en dur sur les noms de base de données, celles-ci facilitent la gestion de plusieurs environnements sur le même serveur.

• Certaines choses, telles que les fonctions d'agrégat personnalisées, ne peuvent être implémentées qu'à l'aide de sprocs CLR. De plus, si vous souhaitez échapper à un contexte de transaction (par exemple, simuler une transaction autonome pour la consignation d’erreurs sans annulation), vous pouvez utiliser un sproc CLR, car il peut créer une connexion locale en dehors du contexte de transaction actuel.

Sécurité

Les connexions sont définies au niveau de l'instance SQL Server, mais chaque connexion est mappée à zéro ou plusieurs bases de données en tant qu '«utilisateur de base de données». Les autorisations peuvent être attribuées à la fois aux «connexions» (serveur) et aux «utilisateurs» (base de données), mais dans une base de données, des «rôles» sont normalement utilisés. Les utilisateurs appartiennent à des rôles, des autorisations sont attribuées à des rôles. SQL Server 2012 ajoute des «rôles de serveur».

• SQL Server 2012 introduit un concept appelé «bases de données partiellement contenues», qui permet de conserver les informations sur les utilisateurs et les rôles localement dans cette base de données.

• Dans une base de données, le concept d'utilisateur et le schéma sont séparés. Un utilisateur ou un rôle peut être affecté à un schéma et un schéma possède des objets de base de données.

• L'authentification Windows utilise les informations de connexion en arrière-plan pour authentifier un utilisateur sur une machine ou un domaine auprès d'une connexion SQL Server. Le support IIRC pour cela est un supplément optionnel sur Oracle.

• Un rôle spécial, "dbo" (abréviation de "propriétaire de la base de données"), dispose d'une sorte de privilège de superutilisateur dans une base de données spécifique. Chaque base de données a un rôle "dbo" et les utilisateurs peuvent être affectés au rôle "dbo" sur une base de données donnée.

• Il existe également un schéma "dbo" par défaut. Les objets peuvent appartenir au schéma dbo - Les objets créés par les utilisateurs dotés du rôle 'dbo' (ou d'autorisations d'administrateur à l'échelle du système) appartiendront par défaut au schéma 'dbo' à moins qu'un autre schéma ne soit explicitement fourni.

• Les informations de sécurité ne sont pas conservées avec une sauvegarde d'une base de données unique. Les utilisateurs doivent et les rôles doivent être configurés explicitement sur le serveur sur lequel la sauvegarde est restaurée. SQL Server 2012 permet aux données des utilisateurs et des rôles d'être conservées localement dans une base de données avec une nouvelle fonctionnalité de «bases de données partiellement contenues».

• A partir de SQL Server 2005, les procédures stockées peuvent être exécutées dans le contexte de sécurité de l'appelant, du créateur, du schéma propriétaire ou d'un utilisateur spécifié.

• Dans une vue sur SQL Server, les autorisations sur les tables sous-jacentes sont basées sur les autorisations du schéma propriétaire de la vue. Les autorisations utilisateur sur les tables sous-jacentes ne participent pas à la sécurité, bien qu'une définition de vue puisse inclure des filtres qui extraient des informations de la session. Dans Oracle, les autorisations des utilisateurs sur les tables sous-jacentes peuvent affecter la vue, selon la configuration des autorisations.

Surveillance et réglage

TBA - architecture mémoire vs SGA, etc. dans Oracle

Sauvegarde et récupération

TBA

Outillage

Microsoft regroupe un ensemble d'outils environnants avec SQL Server. Certains des principaux articles fournis sont:

• SQL Server Management Studio (SSMS): Cela ressemble à SQL Developer on Oracle: il fournit un éditeur et une fonction d’exécution de code. Certaines fonctionnalités utiles incluent un navigateur d'objet de base de données et un visualiseur de plan de requête.

• SQL Server Analysis Services (SSAS): il s'agit d'un serveur OLAP distinct du serveur de base de données. Il utilise ses propres langage de requête (MDX) et API (XML / A) pour la communication client-serveur. Il ne peut pas être interrogé avec SQL. SSMS dispose d'une fonction permettant de modifier les requêtes MDX et XMLA brutes et d'afficher les résultats. Un outil de requête en ligne de commande appelé ASCMD.EXE est également fourni.

• SQL Server Reporting Services (SSRS): Il s'agit d'un outil de création de rapports Web permettant de publier des rapports. Les rapports peuvent être créés via BI Development Studio (BIDS) ou Générateur de rapports, puis publiés sur un portail Web. Le serveur SSRS lui-même dispose d'une API de service Web permettant de gérer le serveur par programme. Notez que les rapports SSRS peuvent consommer des données provenant de différentes sources, pas seulement SQL Server. Un outil de ligne de commande appelé RS.EXE est fourni pour la gestion par programme des serveurs SSRS.

• SQL Server Integration Services (SSIS): il s'agit d'un outil ETL fourni avec SQL Server. D'un point de vue architectural, il est assez différent d'OWB ou d'ODI en ce qu'il ne s'agit pas d'un outil de génération de code. Le runtime est assis côté client et peut être sur une machine distincte du serveur de base de données. Les packages SSIS peuvent être développés avec BIDS et exécutés indépendamment avec un outil de ligne de commande appelé DTEXEC.EXE.

• BI Development Studio (BIDS): il s’agit d’un environnement basé sur studio visuel qui permet de développer des rapports, des packages SSIS et des cubes SSAS. Si d'autres outils de développement basés sur VS sont installés (par exemple, VS Professional), ils peuvent être intégrés dans un environnement unique et dans un groupe de projets commun.

• Copie en bloc (BCP): outil d'insertion / d'extraction en bloc de la ligne de commande similaire à SQL * Loader

• SQLCMD: un outil de requête en ligne de commande similaire à SQL * plus

• Profileur SQL: outil de traçage et de profilage permettant de capturer et d'évaluer les informations de traçage à partir de SQL Server, SSAS et d'autres outils de la suite.

• Agent SQL Server: utilitaire de planification de travaux pouvant exécuter des travaux périodiques d'une sorte à l'autre.

Notre produit principal fonctionne à la fois sur SQL Server et Oracle. Voici quelques autres différences sur lesquelles nous devions travailler. Il serait peut-être bon de garder à l'esprit:

• La gestion date-heure est très différente: différentes précisions, différents ensembles de fonctions avec lesquels travailler.

• Les chaînes vides sont des valeurs NULL dans Oracle, pas dans SQL Server

• Le traitement de l'encodage des caractères et de l'Unicode est très différent. Dans SQL Server, vous pouvez varcharcombiner des nvarcharcolonnes normales ( ) ou Unicode ( ) dans la même base de données. Sous Oracle, vous décidez au niveau de la base de données quel type d'encodage utiliser.