Les développeurs DB2 ne peuvent pas créer de table dans votre propre schéma, mais SQL et Oracle Devs peuvent. Justifié?
En tant que développeur Nouveau à DB2, j'ai été surpris lorsque j'ai découvert que je ne pouvais pas créer mes propres tables dans l'environnement de la base de données de développement. Donc, j'ai posé une question à la DB2 DBA. Je ne veux pas être une trop grande nuisance en interrogatoire et espérait avoir une meilleure compréhension de savoir si notre politique de prévention des développeurs de créer des tables est justifiée pour DB2.
question : Je comprends que vous devez suivre la politique, mais savez-vous pourquoi notre société pourrait créer une stratégie de DB2 uniquement pour empêcher les développeurs de DB2 de créer des tables dans leur propre schéma tout en permettant simultanément les développeurs SQL Server et Oracle faire cela?
Réponse : Le mainframe est l'environnement d'Amore contrôlé que Oracle et SQL. Toutes les applications de notre société partagent les sous-systèmes DB2. Dans Oracle ou SQL, chaque application a sa propre instance et leurs tests n'auraient pas une incidence sur une autre instance.
[.____] - DB2 Mainframe ne crée pas plusieurs tables dans le même fichier comme Oracle. Donc, sur le mainframe si vous avez pu créer des tables dans le test, vous pouvez potentiellement utiliser tout le DASD si vous avez créé une énorme table et si vous deviez tester contre cette énorme table, il pourrait souffler l'espace de tri du sous-système, EDM piscine, etc. qui est dimensionné pour un environnement de test. --DB2 Applications Mainframe Partager les sous-systèmes et toutes les ressources système. Chaque sous-système Test DB2 est dimensionné en fonction de la fonction de ce sous-système DB2 ... DB2T - Test, DB2F - Test du système, DB2B - Support de production. Ils ont tous une allocation de dimensionnement différente.
question à la question : Re: "Vous pouvez potentiellement utiliser tout le DASD si vous avez créé une énorme table" NON DB2 n'a pas la possibilité de limiter l'utilisation de l'espace par SCHEMA pour empêcher un développeur d'utiliser tout du DASD (que je présume est un périphérique de stockage d'accès disque/un espace disque)? Regardant l'acronyme EDM et trouver le "gestionnaire de descripteur environnemental" Je présume que c'est ce qui contient toutes les définitions de la table, telles qu'une base de données principale. Est-ce une préoccupation valable qui est spécifique à DB2?
De la réponse de la DBA, je comprends généralement que notre architecture est telle que chaque environnement, par exemple, test, UAT, etc., ne fonctionne pas dans une instance séparée et une instance peut affecter l'autre, mais elle sonne comme si ceci est le cas, Ensuite, nous avons déjà ce problème que les développeurs ont la capacité d'insérer des millions de lignes dans des tables créées pour eux. La vraie menace n'est-elle pas la taille des tables que je crée et plutôt que la capacité de créer une table? Je penserais qu'un DB2 DBA devrait être en mesure de limiter les développeurs à un niveau de sécurité.
Ils le font probablement parce que l'allocation de stockage sur le mainframe est beaucoup plus complexe que pour les plates-formes UNIX ou Windows.
zos est fondamentalement un élément de harning et d'exploitation sophistiqué très moderne qui immettent une image centrale de 1960s. Beaucoup de même manière que les derniers puces Intel imbriquent une puce de 386 années 1980.
Le problème est que le niveau très bas proches des E/S Wire Disk, nécessaire pour obtenir une bande passante élevée et et des heures d'accès rapides sur le matériel d'origine sont "cuites au four" au système d'exploitation et de nombreuses applications. Donc, tous les stockages de disque pour les applications Legacy traitent des canaux et des volumes. Un volume est un "prétendre" 3330 disque avec 8 Go ou 32 Go de stockage généralement attribué en tant que morceau d'un véritable système de raid de ntérabyte.
Pour définir correctement les tableaux dans ZOS DB2, vous devez créer des espaces de tableaux qui nécessitent à son tour que vous allouez allouer de stockage sur des volumes spécifiques, cela est assez désordonné que quatre ou cinq entités doivent être liées ensemble de table -> Tablepace -> Groupe de volume -> Volumes de disque + Index -> Indextablespace -> Groupe de volume -> Volumes de disque.
Fondamentalement, vos dabas vous permettent beaucoup de chagrin en vous laissant jouer avec les matchs.
P.s. Si vous utilisez la moitié moderne de Zos (Systèmes Unix Systems), tout cela devient sans importance, mais cela sera une longue migration lente!