Instance et base de données (Oracle vs SQL Server)
J'utilise Oracle jusqu'à présent, où:
- instance -> processus + mémoire
- base de données -> fichiers de données physiques
Normalement, une instance correspond à une base de données. À l'intérieur d'une base de données, il peut y avoir de nombreux espaces de table (système, utilisateurs, etc.).
Cependant, je ne suis pas sûr du serveur SQL. Il me semble que pour SQL Server, une instance = plusieurs bases de données? Ou une instance = plusieurs schémas?
Dans Oracle, une base de données contient le système, sysaux, les espaces de table temporaires et l'espace de table utilisateur. En bref, le système et l'utilisateur sont dans la même base de données.
Dans SQL Server, il semble qu'il existe une seule base de données système et qui puisse desservir plusieurs bases de données utilisateur?
Je suis DBA sur Oracle et SQL Server.
La confusion est due à un décalage de sémantique et à un niveau supplémentaire dans la hiérarchie de SQL Server, mais il y a plus que cela!
Notez que nous ne parlerons que de la base de données à instance unique dans les deux cas (jeu de mots voulu).
Instances
Dans Oracle, une instance aura une quantité de mémoire allouée (SGA/PGA) et des processus générés (smon, pmon dw0X et ainsi de suite). Il existe des vues système pour surveiller toutes les choses qui seront créées et utilisées (vues V $ et dba_).
C'est la structure que nous connaissons dans Oracle.
Et vous l'avez déjà mentionné, la base de données est l'endroit où se trouvent les fichiers physiques. Le passage au RAC fait généralement la différence.
Dans SQL Server, l'instance fonctionne de la même manière: un tas de mémoire est allouée et il existe des vues système (sys.) Pour surveiller tout cela.
L'instance dispose de 4 bases de données système:
- système où les vues du système sont.
- base de données msdb qui contient également des informations relatives au système. C'est généralement là que vous trouverez les données liées à vos sauvegardes. Un peu de maintenance est nécessaire sur celui-ci au moins pour vider les anciens enregistrements de sauvegardes.
- model, la base de données bien nommée qui est utilisée comme modèle pour chaque nouvelle base de données que vous créerez. C'est une bonne idée de modifier les paramètres du fichier de données (extension automatique, taille initiale, mode de sauvegarde) afin que toutes les nouvelles bases de données en bénéficient.
- tempdb développé ci-dessous.
La base de données système contient des informations de métadonnées pour toutes les autres bases de données sur SQL Server.
espace temporaire
Dans Oracle:
Espace de table temporaire (créer un espace de table temporaire). Dans Oracle, l'espace de table temporaire est une zone de déversement pour les opérations qui ne peuvent pas tenir dans le PGA (mémoire de processus, par défaut à 200 Mo (jusqu'à 11 g), votre jointure de hachage par exemple si plus de 200 millions de déversements dans l'espace de table temporaire, généralement c'est une cause de requête à exécution lente).
Dans SQL Server, il existe une base de données tempdb située dans la section "bases de données système" et elle est très activement utilisée, bien plus que dans Oracle. Placez-le sur des disques très rapides (SSD ou fibre vient à l'esprit)
Ainsi vient la 2ème grande différence:
Objets
Dans SQL Server:
Les objets (table, vues), ne sont pas liés à un utilisateur comme dans Oracle, mais plutôt à une "base de données". La "base de données" détient (pas propre), les objets. Au moment de la création de la base de données, un fichier de données est mentionné pour stocker ces objets.
Dans Oracle:
Un utilisateur crée des objets qui atterriront dans un schéma du même nom. Nommer soigneusement les utilisateurs devient important.
Et voici la 3e grande différence:
Sécurité
Dans Oracle:
Les utilisateurs seront créés et ils auront au moins le droit de créer des sessions afin qu'ils puissent accéder aux objets auxquels ils ont été autorisés. Ou, ils auront le droit de créer des objets dans leur propre schéma (rôle de ressource), qui créera ensuite un schéma sous ce nom.
Vous pouvez choisir, et c'est une bonne pratique, de créer un tablespace et d'en faire la valeur par défaut pour chaque utilisateur capable de créer des objets. Si cela n'est pas fait, un espace de table par défaut est utilisé, généralement "USER_DATA".
Dans SQL Server:
Étant donné que les objets n'appartiennent pas à un utilisateur particulier dans un schéma, les utilisateurs doivent d'abord être créés, puis les privilèges attribués. Généralement, celui qui sera l'utilisateur principal pour effectuer la création d'objet se verra accorder le rôle de "propriétaire" sur une base de données donnée.
Cet utilisateur dans SQL Server serait l'équivalent dans Oracle d'un propriétaire de schéma, mais il peut y avoir plusieurs propriétaires.
La sécurité est l'endroit où SQL Server brille sur Oracle: la sécurité de SQL Server peut être liée à Active Directory qui gère les utilisateurs de bureau. Ces utilisateurs de bureau peuvent être liés à un groupe d'utilisateurs disant "lecture seule". Il est possible d'ajouter ce groupe Active Directory à SQL Server et de lui donner un accès en "lecture seule" à votre base de données.
Lorsqu'un utilisateur quitte votre entreprise, l'administrateur Active Directory supprime cet utilisateur et l'accès à la base de données est également perdu.
Oracle peut utiliser LDAP mais avouons-le, ce n'est pas très souvent bien lié aux utilisateurs de bureau Windows.
La 4ème grande différence.
sémantique
SQL Server possède une couche supplémentaire. Dans une base de données SQL Server, les objets peuvent être organisés en schémas. Les schémas peuvent également avoir des propriétaires. Il introduit également une sécurité des grains plus fins, mais bien qu'il soit utilisé, ce n'est pas courant. Je dirais que c'est également une bonne pratique de regrouper vos objets par schéma au début de la phase de développement pour bénéficier plus tard de capacités de sécurité supplémentaires en cas de besoin.
Journaux/Journaux archivés
Enfin, les journaux archivés fonctionnent différemment dans Oracle et SQL Server. SQL Server a un fichier journal créé pour chaque base de données, tandis qu'Oracle a activé le mode journal d'archivage au niveau de l'instance.
C'est là que la ligne s'estompe. Pour certains aspects, les bases de données de SQL Server sont vraiment des bases de données. Dans d'autres cas, ils ressemblent davantage à des schémas.
L'archivage dans SQL Server est défini avec l'option de mode de sauvegarde définie sur Full. Ils sont ensuite archivés en effectuant une sauvegarde du journal. La sauvegarde du journal nécessitera une sauvegarde complète avant de commencer à fonctionner.
Dans Oracle, les journaux archivés sont archivés automatiquement, puis nous les sauvegardons sur un emplacement distant.
Résumé
Oracle:
Instance->User1->Schema1(named User1)->Tablespace1
->Tablespace2
->User2->Schema2(named User2)->Tablespace3
->User3->Granted "read only"->schema2.table1
Serveur SQL:
Instance->Database1->Schema1
->Database2->Schema2
->User1
->User2
->User1->Granted "owner"->Database1
->User2->Granted "read only"->Database2->Schema2
Ce sont les choses qui me viennent à l'esprit lorsque je compare les deux. J'aimerais en savoir plus des autres et ajouter/corriger cette réponse.
Je n'ai pas non plus de préférence particulière pour les deux. Je pense qu'ils font tous les deux un excellent travail et j'aime beaucoup travailler avec les deux.
Je ne connais pas Oracle mais je vais clarifier ce que cela signifie dans SQL Server.
Sur un serveur Windows, il peut y avoir plusieurs instances de SQL Server (installations indépendantes).
Chaque instance a ses propres bases de données (bases de données utilisateur et bases de données système).
Il est important de savoir que chaque instance possède ses propres bases de données système (maître, modèle, msdb, tempdb). Les instances peuvent utiliser différentes éditions et versions de SQL Server et avoir différents produits installés.
Certains composants SQL Server sont partagés entre les instances d'un même serveur (navigateur SQL par exemple).
Pour accéder à l'instance A à partir de l'instance B, vous devez créer un serveur lié sur l'instance B qui correspond à l'instance A. Vous pouvez également connecter SQL Server à Oracle à l'aide de ce mécanisme.
Chaque base de données peut avoir plusieurs schémas. Les schémas regroupent des tables, des procédures, des vues et d'autres objets de base de données.
Parfois, une image vaut mille mots: 
Dans SQL Server, une instance représente une installation unique du produit et s'exécute comme un processus serveur unique. Chaque machine peut héberger plusieurs instances de SQL Server.
Chaque instance a:
- Ses propres fichiers binaires (dans Oracle, vous pouvez exécuter plusieurs bases de données avec les mêmes fichiers binaires). Cela signifie également que chaque instance peut être une version/édition différente de SQL Server.
- Son propre processus serveur
- Un ensemble de bases de données système (master, model, msdb et tempdb)
- Sa propre configuration (services, clés de registre ...)
À mon humble avis, la meilleure comparaison serait avec Oracle 12c. Dans Oracle 12c, la base de données est comme une instance de SQL Server, et chaque conteneur de cette base de données 12c serait comme une base de données SQL Server. Dans Oracle 12c avec conteneurs et SQL Server, vous pouvez détacher un conteneur ou une base de données et le rattacher à une autre instance ou base de données. Une vraie différence est qu'avec SQL Server, vous pouvez créer autant de bases de données dans une instance que vous le souhaitez. Mais si vous souhaitez créer des conteneurs dans Oracle 12c, vous devez payer pour la fonctionnalité de conteneur. Vous devrez peut-être également disposer d'Enterprise.