Ο πρώτος και το δεύτερο Μέρη αυτής της σειράς συζήτησαν τις διαφορές μεταξύ της βάσης δεδομένων Oracle και του Microsoft SQL Server στην υλοποίηση των συναλλαγών τους, και τις προκύπτουσες παγίδες μετατροπής, καθώς και ορισμένα στοιχεία σύνταξης που χρησιμοποιούνται συνήθως.

Αυτή η τελευταία δόση θα καλύψει την έννοια του Μαντείο διαβάστε τη συνέπεια και πώς να μετατρέψετε την αρχιτεκτονική, βάσει αυτής της έννοιας, σε α Διακομιστής Microsoft SQL εκδοχή. Θα εξετάσει επίσης τη χρήση συνωνύμων (και πώς ΔΕΝ να τα χρησιμοποιήσετε) και τον ρόλο της διαδικασίας ελέγχου αλλαγών στη διαχείριση του περιβάλλοντος της βάσης δεδομένων σας.

Το Oracle Read Consistency και το ισοδύναμο του στον SQL Server

Η συνέπεια ανάγνωσης της Oracle είναι μια εγγύηση ότι όλα τα δεδομένα που επιστρέφονται από μία μόνο δήλωση SQL προέρχονται από την ίδια μοναδική χρονική στιγμή.

Αυτό σημαίνει ότι εάν εκδώσατε ένα SELECT δήλωση στις 12: 01: 02.345 και έτρεξε για 5 λεπτά πριν επιστρέψει το σύνολο αποτελεσμάτων, όλα τα δεδομένα (και μόνο τα δεδομένα) που έχουν δεσμευτεί στη βάση δεδομένων από τις 12: 01: 02.345 θα τα καταστήσουν στο σύνολο επιστροφής σας. Το σύνολο επιστροφής σας δεν θα έχει προσθέσει νέα δεδομένα κατά τη διάρκεια αυτών των 5 λεπτών που χρειάστηκε η βάση δεδομένων για την επεξεργασία της δήλωσής σας, ούτε ενημερώσεις και καμία διαγραφή δεν θα είναι ορατή.

Η αρχιτεκτονική της Oracle επιτυγχάνει συνοχή ανάγνωσης με χρονική σήμανση κάθε αλλαγής στα δεδομένα και δημιουργώντας ένα σύνολο αποτελεσμάτων από δύο πηγές: μόνιμα αρχεία δεδομένων και ένα τμήμα αναίρεσης (ή 'τμήμα επαναφοράς' όπως ήταν γνωστό μέχρι την έκδοση 10g ).

Για να το υποστηρίξετε, οι πληροφορίες αναίρεσης πρέπει να διατηρηθεί . Αν αντικατασταθεί, έχει ως αποτέλεσμα την περιβόητη ORA-01555: snapshot too old λάθος.

Αφήνοντας την αναίρεση της διαχείρισης τμημάτων - και πώς μπορείτε να πλοηγηθείτε στο ORA-01555: snapshot too old σφάλμα — ας δούμε τις συνέπειες της συνοχής ανάγνωσης σε οποιαδήποτε πρακτική εφαρμογή στο Oracle. Επίσης, πώς πρέπει να αντικατοπτρίζεται στον SQL Server, ο οποίος - όπως συμβαίνει με άλλες εφαρμογές RDBMS, με την πιθανή και ειδική εξαίρεση της PostgreSQL - δεν το υποστηρίζει;

Το κλειδί είναι ότι το Oracle διαβάζει και γράφει δεν εμποδίζει το ένα το άλλο. Σημαίνει επίσης ότι το μακροπρόθεσμο σύνολο επιστροφής ερωτημάτων ενδέχεται να μην έχει τα πιο πρόσφατα δεδομένα.

Η απαγόρευση της ανάγνωσης και της γραφής είναι ένα πλεονέκτημα που έχει η Oracle και επηρεάζει το πεδίο συναλλαγών .

Ωστόσο, η συνέπεια ανάγνωσης σημαίνει επίσης ότι δεν έχετε την τελευταία κατάσταση των δεδομένων. Όταν σε ορισμένα σενάρια είναι απολύτως καλό (όπως η δημιουργία μιας αναφοράς για ένα συγκεκριμένο χρονικό διάστημα), θα μπορούσε να δημιουργήσει σημαντικά ζητήματα σε άλλα.

Το να μην έχετε τα πιο πρόσφατα - ακόμη και 'βρώμικα' ή μη δεσμευμένα - δεδομένα θα μπορούσαν να είναι κρίσιμα: Το κλασικό σενάριο είναι ένα σύστημα κρατήσεων δωματίων ξενοδοχείου.

Εξετάστε την ακόλουθη περίπτωση χρήσης: Έχετε δύο αντιπροσώπους εξυπηρέτησης πελατών που αποδέχονται ταυτόχρονα παραγγελίες κράτησης δωματίου. Πώς μπορείτε να διασφαλίσετε ότι τα δωμάτια δεν θα είναι υπερβολικά κρατημένα;

Στον διακομιστή SQL, μπορείτε να ξεκινήσετε μια ρητή συναλλαγή και SELECT μια εγγραφή από τη λίστα (που θα μπορούσε να είναι ένας πίνακας ή μια προβολή) των διαθέσιμων δωματίων. Εφόσον αυτή η συναλλαγή δεν είναι κλειστή (είτε από COMMIT ή ROLLBACK), κανείς δεν μπορεί να λάβει την ίδια εγγραφή δωματίου που έχετε επιλέξει. Αυτό αποτρέπει τη διπλή κράτηση, αλλά επίσης κάνει κάθε άλλο πράκτορα να περιμένει ο ένας τον άλλον για να συμπληρώσει τα αιτήματα κράτησης ένα κάθε φορά, διαδοχικά.

Στο Oracle, μπορείτε να επιτύχετε το ίδιο αποτέλεσμα εκδίδοντας ένα SELECT ... FOR UPDATE δήλωση έναντι εγγραφών που ταιριάζουν με τα κριτήρια αναζήτησής σας.

Σημείωση: Υπάρχουν καλύτερες λύσεις, όπως ο ορισμός μιας προσωρινής σημαίας που σηματοδοτεί ένα δωμάτιο «υπό εξέταση» αντί να κλειδώνει τυφλά την πρόσβαση σε αυτό. Αλλά αυτές είναι αρχιτεκτονικές λύσεις, όχι επιλογές γλώσσας.

συμπέρασμα : Η συνέπεια ανάγνωσης της Oracle δεν είναι «όλα καλά» ή «όλα άσχημα», αλλά μια σημαντική ιδιότητα της πλατφόρμας που πρέπει να κατανοηθεί καλά και είναι κρίσιμη για τη μετεγκατάσταση κώδικα μεταξύ πλατφορμών.

Δημόσια (και ιδιωτικά) Συνώνυμα στον Oracle και τον Microsoft SQL Server

'Τα δημόσια συνώνυμα είναι κακά.' Του όχι ακριβώς η προσωπική μου ανακάλυψη , αλλά το είχα αποδεχτεί ως ευαγγέλιο μέχρι την ημέρα, την εβδομάδα και το έτος μου να σωθούν από δημόσια συνώνυμα.

Σε πολλά περιβάλλοντα βάσεων δεδομένων — θα έλεγα όλα τα περιβάλλοντα της Oracle με τα οποία είχα την ευκαιρία να εργαστώ, αλλά κανένα από αυτά που σχεδίασα — χρησιμοποιώντας CREATE PUBLIC SYNONYM για κάθε αντικείμενο ήταν ρουτίνα γιατί 'το κάναμε πάντα έτσι.'

Σε αυτά τα περιβάλλοντα, τα δημόσια συνώνυμα είχαν μόνο μία λειτουργία: να επιτρέπουν την αναφορά σε ένα αντικείμενο χωρίς να καθορίζουν τον κάτοχό του. Και αυτό είναι ένα κακώς μελετημένος λόγος να κάνουν δημόσια συνώνυμα.

Ωστόσο, τα δημόσια συνώνυμα της Oracle μπορεί να είναι εξαιρετικά χρήσιμα και να παρέχουν οφέλη στην παραγωγικότητα της ομάδας που υπερβαίνουν σημαντικά όλα τα μειονεκτήματά τους, εάν εφαρμοστούν και διαχειριστούν σωστά και με κάποιο λόγο. Ναι, είπα «παραγωγικότητα ομάδας». Αλλά πως? Για αυτό, πρέπει να καταλάβουμε πώς λειτουργεί η ανάλυση ονομάτων στο Oracle.

Όταν το πρόγραμμα ανάλυσης του Oracle βρίσκει ένα όνομα (μια μη δεσμευμένη λέξη-κλειδί), προσπαθεί να το αντιστοιχίσει με ένα υπάρχον αντικείμενο βάσης δεδομένων με την ακόλουθη σειρά:

έλεγχος ταυτότητας ανάπαυσης ασφάλειας ελατηρίου εκκίνησης

Σημείωση: Το σφάλμα που προέκυψε θα είναι ORA-00942: table or view does not exist για δηλώσεις DML, ή PLS-00201: identifier 'my_object' must be declared για αποθηκευμένες διαδικασίες ή κλήσεις λειτουργίας.

Σε αυτήν τη σειρά ανάλυσης ονόματος, είναι εύκολο να δούμε ότι όταν ένας προγραμματιστής εργάζεται στο δικό του σχήμα, οποιοδήποτε τοπικό αντικείμενο με το ίδιο όνομα με ένα δημόσιο συνώνυμο θα κρύβω αυτό το δημόσιο συνώνυμο. (Σημείωση: Το Oracle 18c εφάρμοσε τον τύπο σχήματος 'μόνο για σύνδεση' και αυτή η συζήτηση δεν ισχύει για αυτό.)

Δημόσια συνώνυμα για κλιμάκωση ομάδων: Oracle Change Control

Ας δούμε τώρα μια υποθετική ομάδα 100 προγραμματιστών που εργάζονται στην ίδια βάση δεδομένων (κάτι που έχω βιώσει). Επιπλέον, ας υποθέσουμε ότι όλοι εργάζονται τοπικά στους προσωπικούς τους σταθμούς εργασίας και κάνουν ανεξάρτητες εκδόσεις βάσεων δεδομένων, όλα συνδεδεμένα με το ίδιο περιβάλλον ανάπτυξης βάσεων δεδομένων. Η επίλυση συγχώνευσης κώδικα σε κώδικα εκτός βάσης δεδομένων (είτε πρόκειται για C #, Java, C ++, Python ή οτιδήποτε άλλο) θα πραγματοποιηθεί κατά την ώρα του check-in του ελέγχου αλλαγής και θα τεθεί σε ισχύ με την επόμενη έκδοση κώδικα. Ωστόσο, οι πίνακες βάσεων δεδομένων, ο κώδικας και τα δεδομένα πρέπει να αλλάξουν πολλές φορές κατά τη διάρκεια της συνεχιζόμενης ανάπτυξης. Κάθε προγραμματιστής το κάνει αυτόνομα και τίθεται σε ισχύ αμέσως.

Για αυτό, όλα τα αντικείμενα βάσης δεδομένων δημιουργούνται σε ένα κοινό σχήμα εφαρμογής. Αυτό είναι ο σχήμα που αναφέρεται η εφαρμογή. Κάθε προγραμματιστής:

• Συνδέεται στη βάση δεδομένων με τον προσωπικό λογαριασμό χρήστη / σχήμα τους
• Ξεκινά πάντα με ένα κενό προσωπικό σχήμα
• Αναφέρει το κοινό σχήμα μόνο μέσω ανάλυσης ονομάτων σε δημόσιο συνώνυμο, όπως περιγράφεται παραπάνω

Όταν ένας προγραμματιστής πρέπει να κάνει όποιος αλλαγές στη βάση δεδομένων - δημιουργία ή αλλαγή πίνακα, αλλαγή κωδικού διαδικασίας ή ακόμη και τροποποίηση ενός συνόλου δεδομένων για την υποστήριξη κάποιου δοκιμαστικού σεναρίου - δημιουργούν ένα αντίγραφο του αντικειμένου στο προσωπικό τους σχήμα. Το κάνουν αυτό λαμβάνοντας τον κωδικό DDL χρησιμοποιώντας το DESCRIBE εντολή και εκτέλεση του τοπικά.

Από αυτήν τη στιγμή, ο κώδικας αυτού του προγραμματιστή θα βλέπει την τοπική έκδοση του αντικειμένου και των δεδομένων, τα οποία δεν θα είναι ορατά (ούτε θα επηρεάσουν) κανέναν άλλο. Μετά την ολοκλήρωση της ανάπτυξης, ο τροποποιημένος κώδικας βάσης δεδομένων ελέγχεται στον έλεγχο προέλευσης και επιλύονται οι διενέξεις. Στη συνέχεια, ο τελικός κώδικας (και τα δεδομένα, εάν χρειάζεται) εφαρμόζεται στο κοινό σχήμα.

Μετά από αυτό, ολόκληρη η ομάδα ανάπτυξης μπορεί να δει ξανά την ίδια βάση δεδομένων. Ο προγραμματιστής που μόλις έδωσε τον κωδικό απορρίπτει όλα τα αντικείμενα από το προσωπικό του σχήμα και είναι έτοιμος για μια νέα ανάθεση.

Αυτή η ικανότητα να διευκολύνεται η ανεξάρτητη παράλληλη εργασία για πολλούς προγραμματιστές είναι το κύριο όφελος των δημόσιων συνωνύμων - μια σημασία που είναι δύσκολο να υπερεκτιμηθεί. Ωστόσο, στην πράξη, συνεχίζω να βλέπω ομάδες να δημιουργούν δημόσια συνώνυμα στις υλοποιήσεις της Oracle «μόνο και μόνο επειδή το κάνουμε πάντα». Αντίθετα, σε ομάδες που χρησιμοποιούν SQL Server, δεν βλέπω τη δημιουργία δημόσιων συνωνύμων ως κοινή πρακτική. Η λειτουργικότητα υπάρχει αλλά δεν χρησιμοποιείται συχνά.

Στον διακομιστή SQL, το τρέχον προεπιλεγμένο σχήμα για έναν χρήστη ορίζεται στη διαμόρφωση του χρήστη και μπορεί να αλλάξει ανά πάσα στιγμή, εάν έχετε δικαιώματα 'αλλαγής χρήστη'. Μπορεί να εφαρμοστεί η ίδια ακριβής μεθοδολογία όπως περιγράφεται παραπάνω για το Oracle. Ωστόσο, εάν αυτή η μέθοδος δεν χρησιμοποιείται, τα δημόσια συνώνυμα δεν πρέπει να αντιγραφούν.

Καθώς ο Microsoft SQL Server δεν συσχετίζει έναν νέο λογαριασμό χρήστη με το δικό του σχήμα από προεπιλογή (όπως συμβαίνει με την Oracle), ο συσχετισμός θα πρέπει να αποτελεί μέρος του τυπικού σεναρίου 'δημιουργία χρήστη'.

Ακολουθεί ένα παράδειγμα σεναρίου που δημιουργεί ειδικά σχήματα χρήστη και εκχωρεί ένα σε έναν χρήστη.

Αρχικά, δημιουργήστε σχήματα για νέους χρήστες που πρέπει να ενσωματωθούν στη βάση δεδομένων με την ονομασία DevelopmentDatabase (κάθε σχήμα πρέπει να δημιουργηθεί στη δική του παρτίδα):

use DevelopmentDatabase; GO CREATE SCHEMA Dev1; GO CREATE SCHEMA Dev2; GO

Δεύτερον, δημιουργήστε τον πρώτο χρήστη με το εκχωρημένο προεπιλεγμένο σχήμα:

CREATE LOGIN DevLogin123 WITH PASSWORD = 'first_pass123'; CREATE USER Dev1 FOR LOGIN DevLogin123 WITH DEFAULT_SCHEMA = Dev1; GO

Σε αυτό το σημείο, το προεπιλεγμένο σχήμα για τον χρήστη Dev1 θα ήταν Dev1.

Στη συνέχεια, δημιουργήστε τον άλλο χρήστη χωρίς προεπιλεγμένο σχήμα:

CREATE LOGIN DevLogin321 WITH PASSWORD = 'second_pass321'; CREATE USER Dev2 FOR LOGIN DevLogin321; GO

Το προεπιλεγμένο σχήμα για τον χρήστη Dev2 είναι dbo.

Τώρα αλλαγή χρήστη Dev2 για να αλλάξετε το προεπιλεγμένο σχήμα σε Dev2:

ALTER USER Dev2 WITH DEFAULT_SCHEMA = Dev2; GO

Τώρα το προεπιλεγμένο σχήμα για τον χρήστη Dev2 είναι Dev2.

Αυτό το σενάριο δείχνει δύο τρόπους για την εκχώρηση και αλλαγή ενός προεπιλεγμένου σχήματος για έναν χρήστη σε βάσεις δεδομένων Microsoft SQL Server. Καθώς ο SQL Server υποστηρίζει πολλαπλές μεθόδους ελέγχου ταυτότητας χρήστη (η πιο συνηθισμένη είναι ο έλεγχος ταυτότητας των Windows) και η ενσωμάτωση των χρηστών μπορεί να γίνεται από διαχειριστές συστήματος και όχι από DBA, το ALTER USER Η μέθοδος εκχώρησης / αλλαγής προεπιλεγμένου σχήματος θα είναι πιο χρησιμοποιήσιμη.

Σημείωση: Έκανα το όνομα του σχήματος ίδιο με το όνομα ενός χρήστη. Δεν πρέπει να είναι έτσι στον SQL Server, αλλά είναι η προτίμησή μου επειδή (1) ταιριάζει με τον τρόπο που γίνεται στο Oracle και (2) απλοποιεί τη διαχείριση των χρηστών (αντιμετωπίζοντας τη μεγαλύτερη αντίρρηση από την πλευρά του DBA να το κάνει σωστά στην πρώτη θέση) - γνωρίζετε το όνομα ενός χρήστη και γνωρίζετε αυτόματα το προεπιλεγμένο σχήμα του χρήστη.

συμπέρασμα : Τα δημόσια συνώνυμα είναι ένα σημαντικό εργαλείο για τη δημιουργία ενός σταθερού και καλά προστατευμένου περιβάλλοντος ανάπτυξης πολλαπλών χρηστών. Δυστυχώς, κατά την παρατήρησή μου στον κλάδο, χρησιμοποιείται συχνότερα για λάθος λόγους - αφήνοντας τις ομάδες να υποφέρουν από σύγχυση και άλλα μειονεκτήματα των δημόσιων συνωνύμων χωρίς να συνειδητοποιήσουν τα οφέλη τους. Η αλλαγή αυτής της πρακτικής για την απόκτηση πραγματικών οφελών από τα δημόσια συνώνυμα μπορεί να αποφέρει πραγματικά οφέλη στη ροή εργασιών ανάπτυξης μιας ομάδας.

ταμείο ακίνητης περιουσίας

Διαδικασίες πρόσβασης στη βάση δεδομένων και διαδικασίες αλλαγής

Καθώς μόλις μιλήσαμε για την υποστήριξη για παράλληλη ανάπτυξη από μεγάλες ομάδες, αξίζει να αντιμετωπίσετε ένα ξεχωριστό και συχνά παρεξηγημένο θέμα: διαδικασίες ελέγχου αλλαγών.

Η διαχείριση αλλαγών γίνεται συχνά μια μορφή γραφειοκρατίας που ελέγχεται από επικεφαλής ομάδων και DBA, περιφρονημένη από επαναστατικούς προγραμματιστές που θέλουν να παραδώσουν τα πάντα, αν όχι «χθες», τότε «τώρα».

Ως DBA, έβαλα πάντα προστατευτικά εμπόδια στο δρόμο στη βάση δεδομένων «μου». Και έχω έναν πολύ καλό λόγο για αυτό: Μια βάση δεδομένων είναι ένας κοινός πόρος.

Τιτίβισμα

Σε ένα πλαίσιο ελέγχου πηγής, η διαχείριση αλλαγών είναι γενικά αποδεκτή, δεδομένου ότι επιτρέπει σε μια ομάδα να επιστρέψει από νέο αλλά σπασμένο κώδικα σε παλιό αλλά λειτουργικό κώδικα. Αλλά σε ένα πλαίσιο βάσης δεδομένων, η διαχείριση αλλαγών μπορεί να μοιάζει με ένα σύνολο παράλογων φραγμών και περιορισμών που θέτουν οι DBA: Είναι καθαρή τρέλα που επιβραδύνει άσκοπα την ανάπτυξη!

Ας αφήσουμε το άγχος αυτού του προγραμματιστή: Είμαι DBA και δεν θα ρίξω πέτρες στον εαυτό μου! Ως DBA, βάζω πάντα προστατευτικά εμπόδια στο δρόμο στη βάση δεδομένων «μου». Και έχω έναν πολύ καλό λόγο για αυτό: Μια βάση δεδομένων είναι ένας κοινός πόρος.

Κάθε ομάδα ανάπτυξης - και κάθε προγραμματιστής τους - έχει έναν πολύ συγκεκριμένα καθορισμένο στόχο και πολύ συγκεκριμένο παραδοτέο. Ο μόνος στόχος που υπάρχει στο γραφείο της DBA κάθε μέρα είναι η σταθερότητα της βάσης δεδομένων ως κοινόχρηστου πόρου. Το DBA έχει τον μοναδικό ρόλο σε έναν οργανισμό να επιβλέπει όλες τις προσπάθειες ανάπτυξης σε όλες τις ομάδες και να ελέγχει μια βάση δεδομένων στην οποία έχουν πρόσβαση όλοι οι προγραμματιστές. Είναι το DBA που διασφαλίζει ότι όλα τα έργα και όλες οι διαδικασίες εκτελούνται χωρίς να παρεμβαίνουν μεταξύ τους και ότι ο καθένας έχει τους πόρους που απαιτούνται για να λειτουργήσει.

Το πρόβλημα είναι όταν τόσο οι ομάδες ανάπτυξης όσο και οι ομάδες DBA κάθονται κλειδωμένοι στους αντίστοιχους πύργους ελεφαντόδοντου.

Οι προγραμματιστές δεν γνωρίζουν, δεν έχουν πρόσβαση και δεν νοιάζονται καν για το τι συμβαίνει στη βάση δεδομένων, αρκεί να λειτουργεί καλά. (Δεν είναι παραδοτέο τους, ούτε θα επηρεάσει την αξιολόγηση της απόδοσής τους.)

Η ομάδα DBA διατηρεί τη βάση δεδομένων κοντά στο στήθος, προστατεύοντάς την από προγραμματιστές που «δεν γνωρίζουν τίποτα» γι 'αυτό, επειδή ο στόχος της ομάδας τους είναι η σταθερότητα της βάσης δεδομένων. Και ο καλύτερος τρόπος για να διασφαλιστεί η σταθερότητα είναι να αποφευχθούν καταστροφικές αλλαγές - που συχνά οδηγούν σε μια στάση προστασίας της βάσης δεδομένων από τυχόν αλλαγές όσο το δυνατόν περισσότερο.

Αυτά τα αντικρουόμενες στάσεις απέναντι σε μια βάση δεδομένων μπορεί, όπως έχω δει, να οδηγήσει σε εχθρότητα μεταξύ των ομάδων ανάπτυξης και DBA και να οδηγήσει σε ένα ανεφάρμοστο περιβάλλον. Όμως, οι DBA και η ομάδα ανάπτυξης πρέπει να συνεργαστούν για να επιτύχουν έναν κοινό στόχο: να παράσχουν μια επιχειρηματική λύση, κάτι που τα έφερε μαζί.

Έχοντας και τις δύο πλευρές της διαίρεσης προγραμματιστή-DBA, ξέρω ότι το πρόβλημα είναι εύκολο να επιλυθεί όταν οι DBA κατανοούν καλύτερα τις κοινές εργασίες και τους στόχους των ομάδων ανάπτυξης. Από την πλευρά τους, οι προγραμματιστές πρέπει να δουν μια βάση δεδομένων όχι ως αφηρημένη έννοια αλλά ως κοινόχρηστο πόρο - και εκεί, ένα DBA πρέπει να αναλάβει το ρόλο ενός εκπαιδευτικού.

Το πιο συνηθισμένο σφάλμα που κάνουν οι μη προγραμματιστές DBA είναι ο περιορισμός της πρόσβασης προγραμματιστή στο λεξικό δεδομένων και στα εργαλεία βελτιστοποίησης κώδικα. Πρόσβαση στο Oracle DBA_ προβολές καταλόγου, δυναμική V$ προβολές και SYS πίνακες φαίνεται σε πολλά DBA ως 'προνομιακά DBA' όταν, στην πραγματικότητα, αυτά είναι κρίσιμα εργαλεία ανάπτυξης.

Το ίδιο ισχύει και για τον SQL Server, με μία επιπλοκή: Δεν είναι δυνατή η απευθείας πρόσβαση σε ορισμένες προβολές συστήματος, αλλά είναι μόνο μέρος του SYSADMIN ο ρόλος της βάσης δεδομένων και αυτός ο ρόλος δεν πρέπει ποτέ να παραχωρείται εκτός της ομάδας DBA. Αυτό μπορεί να επιλυθεί (και θα πρέπει να επιλυθεί σε περίπτωση μετεγκατάστασης ενός έργου από το Oracle στον SQL Server) δημιουργώντας προβολές και αποθηκευμένες διαδικασίες που εκτελούνται στο SYSADMIN προνόμια αλλά είναι προσβάσιμα από χρήστες εκτός DBA. Αυτό είναι ανάπτυξη DBA's έχει διαμορφωθεί μια νέα εργασία ανάπτυξης SQL Server.

Η προστασία δεδομένων είναι μία από τις κύριες ευθύνες του DBA. Παρ 'όλα αυτά, είναι πολύ κοινό για τις ομάδες ανάπτυξης να έχουν πλήρη πρόσβαση σε μη φιλτραρισμένα δεδομένα παραγωγής για να επιτρέπουν την αντιμετώπιση προβλημάτων εισιτηρίων που σχετίζονται με δεδομένα. Αυτοί είναι οι ίδιοι προγραμματιστές που έχουν περιορισμένη πρόσβαση στη δομή δεδομένων - δομή που έχει δημιουργηθεί από αυτούς ή για πρώτη φορά.

Όταν δημιουργούνται σωστές εργασιακές σχέσεις μεταξύ ομάδων ανάπτυξης και DBA, η δημιουργία μιας καλής διαδικασίας ελέγχου αλλαγών γίνεται διαισθητική. Οι ιδιαιτερότητες και η πρόκληση της διαχείρισης αλλαγών στην πλευρά της βάσης δεδομένων είναι η ακαμψία και η ρευστότητα μιας βάσης δεδομένων ταυτόχρονα - η δομή είναι άκαμπτη, τα δεδομένα είναι ρευστά.

Συχνά συμβαίνει ότι η διαχείριση αλλαγών στην τροποποίηση δομής - δηλαδή, στη γλώσσα ορισμού δεδομένων ή στο DDL - είναι καλά εδραιωμένη, ενώ οι αλλαγές δεδομένων δεν έχουν καθόλου καθόλου στον τρόπο διαχείρισης αλλαγών. Η αιτιολόγηση είναι απλή - τα δεδομένα αλλάζουν συνεχώς.

Αλλά αν το εξετάσουμε πιο προσεκτικά, θα δούμε ότι σε οποιοδήποτε σύστημα, όλα τα δεδομένα εμπίπτουν σε μία από τις δύο κατηγορίες: δεδομένα εφαρμογών και δεδομένα χρήστη.

Δεδομένα εφαρμογής είναι ένα λεξικό δεδομένων που καθορίζει τη συμπεριφορά μιας εφαρμογής και είναι εξίσου κρίσιμο για τις διαδικασίες της με οποιονδήποτε κωδικό εφαρμογής. Οι αλλαγές σε αυτά τα δεδομένα πρέπει να βρίσκονται υπό αυστηρές διαδικασίες ελέγχου αλλαγών, όπως και με οποιαδήποτε άλλη αλλαγή εφαρμογής. Προκειμένου να δημιουργηθεί διαφάνεια στη διαδικασία ελέγχου αλλαγών για αλλαγές δεδομένων εφαρμογής, τα δεδομένα εφαρμογής και τα δεδομένα χρήστη πρέπει να διαχωρίζονται ρητά.

Στο Oracle, πρέπει να γίνει τοποθετώντας το καθένα από τα δεδομένα εφαρμογών και χρηστών στο δικό του σχήμα. Στον Microsoft SQL Server, πρέπει να γίνει τοποθετώντας το καθένα σε ξεχωριστό σχήμα ή - πολύ καλύτερα - σε ξεχωριστή βάση δεδομένων. Η πραγματοποίηση αυτών των επιλογών πρέπει να αποτελεί μέρος του σχεδιασμού μετεγκατάστασης: Η Oracle έχει ανάλυση ονόματος δύο επιπέδων (σχήμα / κάτοχος - όνομα αντικειμένου), ενώ ο διακομιστής SQL έχει ανάλυση ονόματος τριών επιπέδων (βάση δεδομένων - σχήμα / κάτοχος - όνομα αντικειμένου).

Μια κοινή πηγή σύγχυσης μεταξύ των κόσμων της Oracle και του SQL Server είναι - ίσως εκπληκτικά - οι όροι βάση δεδομένων και υπηρέτης :

Όρος διακομιστή SQL	Όρος της Oracle	Ορισμός
υπηρέτης	βάση δεδομένων (χρησιμοποιείται εναλλακτικά με υπηρέτης σε κοινή γλώσσα, εκτός εάν αναφέρεται συγκεκριμένα σε υλικό διακομιστή, λειτουργικό σύστημα ή στοιχεία δικτύου · μπορεί να υπάρχουν μία ή περισσότερες βάσεις δεδομένων σε έναν φυσικό / εικονικό διακομιστή)	Ένα στιγμιότυπο που μπορεί να 'μιλήσει' με άλλες παρουσίες μέσω θύρας δικτύου
βάση δεδομένων (μέρος ενός διακομιστή, περιέχει πολλά σχήματα / ιδιοκτήτες)	σχήμα / κάτοχος	Η ομαδοποίηση ανώτατου επιπέδου

Αυτός ο συνδυασμός ορολογίας θα πρέπει να γίνει κατανοητός με σαφήνεια σε έργα μετεγκατάστασης μεταξύ πλατφορμών, επειδή η παρερμηνεία όρου μπορεί να οδηγήσει σε λανθασμένες αποφάσεις διαμόρφωσης που είναι δύσκολο να αντιμετωπιστούν αναδρομικά.

Ο σωστός διαχωρισμός της εφαρμογής και των δεδομένων χρήστη επιτρέπει σε μια ομάδα DBA να αντιμετωπίσει τη δεύτερη πιο σημαντική ανησυχία της: την ασφάλεια δεδομένων χρήστη. Καθώς τα δεδομένα χρήστη διαμένουν ξεχωριστά, θα είναι πολύ απλό να εφαρμοστεί ένα διαδικασία σπασίματος γυαλιού για πρόσβαση στα δεδομένα των χρηστών ανάλογα με τις ανάγκες.

συμπέρασμα : Οι διαδικασίες ελέγχου-αλλαγής είναι κρίσιμες σε οποιοδήποτε έργο. Στη μηχανική λογισμικού, η διαχείριση αλλαγών από την πλευρά της βάσης δεδομένων συχνά παραμελείται επειδή τα δεδομένα θεωρούνται «πολύ ρευστά». Αλλά είναι ακριβώς επειδή τα δεδομένα είναι «ρευστά» και «ανθεκτικά» ταυτόχρονα ότι μια καλά σχεδιασμένη διαδικασία ελέγχου αλλαγών θα πρέπει να είναι ο ακρογωνιαίος λίθος της σωστής αρχιτεκτονικής περιβάλλοντος βάσης δεδομένων.

Σχετικά με τη χρήση εργαλείων μετεγκατάστασης κώδικα

Τα τυπικά εργαλεία πρώτου μέρους, Πάγκος εργασίας της Oracle Migration και Βοηθός μετεγκατάστασης διακομιστή SQL , μπορεί να είναι χρήσιμο στις μετακινήσεις κώδικα. Αλλά αυτό που πρέπει να ληφθεί υπόψη είναι ο κανόνας 80/20 : Όταν ο κώδικας μετεγκατασταθεί 80% σωστά, η επίλυση του υπόλοιπου 20% θα πάρει το 80% της προσπάθειας μετανάστευσης.

Ο μεγαλύτερος κίνδυνος στη χρήση εργαλείων μετανάστευσης είναι μακράν η αντίληψη «ασημένια σφαίρα». Κάποιος μπορεί να πειρασθεί να σκεφτεί, 'Θα κάνει τη δουλειά, και θα πρέπει απλώς να κάνω λίγο καθαρισμό και τακτοποίηση.' Παρατήρησα ένα έργο που απέτυχε λόγω τέτοιας στάσης από την ομάδα μετατροπής και την τεχνική της ηγεσία.

Από την άλλη πλευρά, μου πήρε τέσσερις εργάσιμες ημέρες για να ολοκληρώσω τη βασική μετατροπή ενός μεσαίου μεγέθους συστήματος Microsoft SQL Server 2008 (περίπου 200 αντικείμενα) χρησιμοποιώντας τη λειτουργία μαζικής αντικατάστασης του Notepad ++ ως το κύριο εργαλείο επεξεργασίας.

Κανένα από τα κρίσιμα στοιχεία μετεγκατάστασης που έχω αντιμετωπίσει μέχρι τώρα δεν μπορεί να επιλυθεί με εργαλεία μετεγκατάστασης.

Σίγουρα, χρησιμοποιήστε εργαλεία βοήθειας μετεγκατάστασης, αλλά θυμηθείτε ότι αυτά παρέχουν μόνο βοήθεια επεξεργασίας. Το προκύπτον κείμενο εξόδου πρέπει να έχει επανεξέταση, τροποποίηση και - σε ορισμένες περιπτώσεις - επανεγγραφή για να γίνει κώδικας που να αξίζει την παραγωγή.

Η ανάπτυξη εργαλείων τεχνητής νοημοσύνης μπορεί να αντιμετωπίσει αυτές τις ελλείψεις εργαλείων μετανάστευσης στο μέλλον, αλλά θα περίμενα ότι οι διαφορές μεταξύ των βάσεων δεδομένων θα ξεθωριάσουν πριν από τότε και οποιαδήποτε ίδια η διαδικασία μετανάστευσης θα γίνει περιττή. Έτσι, όσο απαιτούνται αυτά τα είδη έργων, θα πρέπει να το κάνουμε με τον παλιό τρόπο, χρησιμοποιώντας την ντεμοντέ ανθρώπινη νοημοσύνη.

συμπέρασμα : Η χρήση εργαλείων βοήθειας μετανάστευσης είναι χρήσιμη, αλλά δεν είναι 'ασημένια σφαίρα' και οποιοδήποτε έργο μετατροπής απαιτεί ακόμη λεπτομερή αναθεώρηση των παραπάνω σημείων.

Μετεγκαταστάσεις διακομιστή Oracle / SQL: Να έχετε πάντα μια πιο προσεκτική ματιά

Ο Oracle και ο Microsoft SQL Server είναι οι δύο πιο διαδεδομένες πλατφόρμες RDBMS στο επιχειρηματικό περιβάλλον. Και οι δύο έχουν βασική συμμόρφωση με το πρότυπο ANSI SQL και μικρά τμήματα κώδικα μπορούν να μετακινηθούν με πολύ μικρή τροποποίηση ή ακόμα και ως έχει.

Αυτή η ομοιότητα δημιουργεί μια παραπλανητική εντύπωση ότι η μετεγκατάσταση στις δύο πλατφόρμες είναι μια απλή, απλή εργασία και ότι η ίδια εφαρμογή μπορεί εύκολα να υιοθετηθεί από τη χρήση ενός RDBMS back-end σε άλλο.

Στην πράξη, αυτές οι μεταναστεύσεις πλατφόρμας δεν είναι καθόλου ασήμαντες και πρέπει να λάβουν υπόψη τα ωραία στοιχεία της εσωτερικής λειτουργίας κάθε πλατφόρμας και, κυρίως, τον τρόπο εφαρμογής της υποστήριξης για το πιο κρίσιμο στοιχείο της διαχείρισης δεδομένων: συναλλαγές.

Ενώ κάλυψα δύο πλατφόρμες RDBMS που αποτελούν τον πυρήνα της εμπειρογνωμοσύνης μου, η ίδια προειδοποίηση - 'μοιάζει να μην σημαίνει ότι λειτουργεί όμοια' - θα πρέπει να εφαρμοστεί στη μετακίνηση κώδικα μεταξύ οποιωνδήποτε άλλων συστημάτων διαχείρισης βάσεων δεδομένων συμβατών με SQL. Και σε όλες τις περιπτώσεις, το πρώτο σημείο προσοχής θα πρέπει να είναι ο τρόπος με τον οποίο η εφαρμογή της διαχείρισης συναλλαγών διαφέρει μεταξύ των πλατφορμών προέλευσης και στόχου.

Κατανόηση των βασικών

Τι είναι η συνέπεια δεδομένων στο Oracle;

Στο Oracle, η συνέπεια των δεδομένων βασίζεται σε πολλαπλές εκδόσεις: Οποιαδήποτε έκδοση δεδομένων που αναφέρεται σε ένα μόνο χρονικό σημείο θα πρέπει να είναι σε κατάσταση τέτοια ώστε να μην έχει παραβιάσεις των ενεργών περιορισμών της βάσης δεδομένων.

Τι είναι η συνέπεια ανάγνωσης στο Oracle;

Η συνέπεια ανάγνωσης της Oracle είναι μια εγγύηση σε επίπεδο SQL που εγγυάται ότι όλα τα δεδομένα θα επιστραφούν σε σταθερή κατάσταση - όπως ήταν στο σημείο κατά το οποίο υποβλήθηκε η δήλωση για εκτέλεση. Για να το υποστηρίξει αυτό, η Oracle διαχειρίζεται πολλές εκδόσεις δεδομένων που αντιστοιχούν σε πολλά σημεία στο χρόνο.

Τι είναι ο έλεγχος συνέπειας βάσης δεδομένων;

Ο έλεγχος συνέπειας βάσης δεδομένων είναι μια διαδικασία για την επικύρωση ότι η βάση δεδομένων βρίσκεται σε σταθερή κατάσταση και δεν έχει μπλοκ δεδομένων που λείπουν ή είναι κατεστραμμένα. Θα πρέπει να εκτελείται σε αντίγραφα ασφαλείας και σε βάσεις δεδομένων των οποίων η λειτουργικότητα αποκαθίσταται μετά από αποτυχία υλικού.

Τι είναι η συνέπεια δεδομένων στο SQL;

Σε βάσεις δεδομένων συμβατές με SQL, η συνέπεια δεδομένων αναφέρεται σε μια κατάσταση των δεδομένων όπου δεν έχει παραβίαση οποιωνδήποτε ενεργών περιορισμών βάσης δεδομένων. Αυτή είναι η βασική απαίτηση που πρέπει να πληρούται στο τέλος κάθε συναλλαγής.

Τι είναι τα ιδιωτικά συνώνυμα και τα δημόσια συνώνυμα στο Oracle;

Τα ιδιωτικά συνώνυμα της Oracle δημιουργούνται σε ένα συγκεκριμένο σχήμα και είναι προσβάσιμα μέσω αναφορών σχήματος με τον ίδιο τρόπο όπως οποιοδήποτε άλλο αντικείμενο σχήματος. Από την άλλη πλευρά, τα δημόσια συνώνυμα δημιουργούνται στην ομάδα PUBLIC και είναι προσβάσιμα χωρίς καμία αναφορά σχήματος.

Πώς αλλάζετε τα συνώνυμα στο Oracle;

Στο Oracle, για να αλλάξετε σε ποιο αντικείμενο αναφέρεται ένα συνώνυμο, το συνώνυμο πρέπει να απορριφθεί και να αναδημιουργηθεί.

επιπτώσεις του χρώματος στον τρόπο σκέψης και αίσθησης

Τι είναι η παρουσία της Oracle;

Ένα στιγμιότυπο Oracle είναι ολόκληρη η συλλογή της διαδικασίας παρασκηνίου και της εκχωρημένης μνήμης που αποτελεί τη βάση δεδομένων Oracle ως εφαρμογή που αποθηκεύει και χειρίζεται δεδομένα.