Δουλειά του dba είναι (the sequel)...

"επανάληψη, μήτηρ μαθήσεως" μαθαίναμε παλιά στο σχολείο. Αλλά δυστυχώς κάποιοι δεν πρόσεχαν στο μάθημα και τώρα κόβονται μετεξετασταίοι. Και επειδή ο οποιοσδήποτε στη δουλειά του μία φορά μπορεί να εξηγήσει κάτι στο συνάδελφο, δεύτερη φορά θα κάνει την καρδιά του πέτρα και θα το επαναλάβει, άντε και μια τρίτη, αλλά από κει και πέρα θα σιχτιριστεί, καλό θα είναι να επαναλάβω ποια είναι η δουλειά και οι αρμοδιότητες ενός dba (database administrator). Πάμε λοιπόν: δουλειά του dba είναι

• να παρακολουθεί και να φροντίζει για την απρόσκοπτη λειτουργία των βάσεων δεδομένων (tuning, error handling, debugging, patching, updating, monitoring),
• επεκτείνοντας στο monitoring, να συμβουλεύει τους χρήστες της βάσης για διορθωτικές κινήσεις που αποσκοπούν στη βελτίωση του performance, όταν παρατηρεί αδικαιολόγητο resource consumption οφειλόμενο στα προγράμματα των χρηστών,
• να φροντίζει για την ακεραιότητα των δεδομένων (διαδικασίες backup, διαδικασίες ανάκτησης σε περίπτωση απώλειας της βάσης, σχεδιασμός disaster recovery site ή/και standby database),
  
• να φροντίζει για την ασφάλεια των δεδομένων (διαδικασίες authorization, authentication, auditing),
• να βοηθά τους χρήστες στη σωστή λειτουργία των εφαρμογών τους, συμμετέχοντας ενεργά (και ίσως έχοντας τον πρώτο λόγο) στο σχεδιασμό του σχεσιακού μοντέλου για τα δεδομένα τους, και παρέχοντας συμβουλευτικές υπηρεσίες για τη σωστή και αποδοτική συγγραφή του κώδικα των εφαρμογών τους, και
  
• να κόβει κώλους κάθε φορά που κάποιος κάνει μαλακίες που θέτουν σε κίνδυνο όλα τα παραπάνω.
  

Ωστόσο (και αυτό πρέπει όλοι να το καταλάβουν καλά):

• o dba δεν είναι ο owner των δεδομένων των χρηστών,
• άρα ο dba δεν μπορεί να γνωρίζει ποια ακριβώς είναι τα δεδομένα των χρηστών, ούτε αν είναι σωστά. Και προφανώς δεν έχει την ευθύνη για το αν τα δεδομένα είναι τα σωστά, μετά από κάποια updates που έτρεξαν οι owners των δεδομένων.

Αν δεν το καταλάβουν κάποιοι αυτό, καλό θα είναι να διαβάσουν αυτό.

Ένα backup δεν είναι ποτέ αρκετό, δύο θα σε σώσουν

η εβδομαδιαία διαδικασία: η reporting database ενημερώνεται (με rman duplicate) από τη central database και ένα έξτρα tablespace (όπου δουλεύουν οι χρήστες μας - το μόνο read-write btw) γίνεται στη συνέχεια plugged in (με transportable tablespaces). To έξτρα tablespace κάθε βράδυ το παίρνουμε hot backup.

το πονηρό μυαλό: δεν παίρνουμε και ένα full export το έξτρα tablespace κάθε βράδυ, έτσι για να μας βρίσκεται;

η κακιά η ώρα: ως δια μαγείας (oracle for ever), και αφού η εβδομαδιαία διαδικασία τρέχει χωρίς πρόβλημα μισό χρόνο τώρα, την τελευταία φορά τα datafiles του παραπάνω tablespace αποκτούν διαφορετικό SCN (system change number) από αυτό που υπάρχει στο expdp dump file του transportable tablespace. Φυσικά, το ίδιο συμβαίνει και με τα datafiles που υπάρχουν στα backup tapes. Τώρα πώς γίνεται αυτό, αφού για να γίνει το trasportable export στο tablespace πρέπει πρώτα να το γυρίσουμε σε read-only, ένας θεός ξέρει.

η απάντηση της Oracle: "Datafiles are not corrupted, as block checksum and head_tail are ok. Based on SCN's DBID, it appears the datafiles are newer than the expdp dump (σ.τ.μ. !!!!!!). The datafiles cannot be used with the expdp dump file -- as such TBS has become an orphaned tablespace (along with the datafiles) and cannot be plugged in."

η λύση: recreate tablespace and import from full datapump export το έξτρα tablespace

το ηθικό δίδαγμα: οι παλιές καλές δοκιμασμένες (και ωριμασμένες με το πέρασμα του χρόνου) λύσεις είναι πάντα οι καλύτερες. Το απλό full export του tablespace έσωσε τα data των χρηστών και την ψυχική μου ηρεμία.

Being politically correct

Ίσως είναι η καλύτερη απάντηση που έχω δει από μία μεγάλη εταιρία, η οποία θέλει με ευγενικό τρόπο να σου πει: "Βασικά τους έχω χεσμένους όλους" αλλά δε θέλει και να εκτεθεί :-) Πραγματικά αξίζει να το διαβάσει κανείς... ειδικά την τελευταία απάντηση...


question
Is Oracle Forms certified on Vista ?

answer
Let me first explain you the certification process of Oracle Corporation. When a new platform is available on the market, Oracle immediately begins to certification test of products whose support period continues on this platform and addresses any problematic areas in the next patchset and completes the certification in the next patchset.

In your specific situation, when Vista came to market, patchset 10.1.2.2 was available and the certification is planned and completed for patchset 10.1.2.3.

You have already found this information in "Client Platform Support" document in following address: http://www.oracle.com/technology/products/forms/htdocs/10gR2/clientsod_forms10gR2.html



question
When will patchset 10.1.2.3 be available?

answer
Well, I can not officially promise on a fixed date, but it is expected very soon. It was planned for this week, but I heard there is a slight delay. I would not surprise to see it is released the nextweek, but as I said, please don't take this as a promise and be a little bit patient, it is very close.


question
Will Jinitiator not gonna be certified to work with Vista ?

answer
There will be no JInitiator on Vista, because JInitiator is based on Sun JRE 1.3.X and Sun does not have any plans to certify JRE 1.3.X on Vista, that's why it is not possible for Oracle to certify JInit on Vista. This is explained in "Note 9" in "Client Platform Support" documentas follows :

"JInitiator is known to not work with Vista and Sun is not planning to support 1.3 on Vista. Oracle therefore have no plans to certify JInitiatorwith Vista.Vista users should consider Sun's plug-in 1.5 once it is certified for Vista. That is planned for 10.1.2.3."


question
The fact that Microsoft Windows Vista desktops with Internet Explorer 7 are certified with Oracle E-Business Suite Release 11i and 12 means that the patchset is ready ?

answer
Unfortunately I will not be able to comment on EBS certifications. It is totally out of my expertise area. You asked "the patchset is ready?" If you are talking about 10.1.2.3 patchset, no it is not yet ready but as I explained in Question #1 above, it is very close

Oracle για πάντα (part III)

Με τα πολλά, και αφού είδαμε και φρικάραμε (βλ. part I και part II), πατσάραμε τις βάσεις μας το Σαββατοκύριακο στο τελευταίο patch set 10.2.0.3 της Oracle (σε Solaris 9). Δευτέρα (πουρνό-πουρνό) με το που μπαίνουν οι πρώτοι χρήστες παίρνουμε (και ξανά-ξανά) τα πρώτα core dumps (ή dumbs, μιας και οι λόγοι που οδηγούν σε αυτά είναι το λιγότερο αστείοι):

Bug# 5648872 * See Note 5648872.8
This bug is alerted in Note 418531.1 Dump (opidsa) from DESCRIBE of a cursor
Fixed: 11

After having applied the 10.2.0.3 patch set, processes from user sessions can core dump (ORA-7445) in opidsa(). It is also known to affect Windows 10.2.0.2 Patch 6 upwards.

Workaround or Resolution
No real workaround exists for the problem, but flushing the shared pool after receiving the error may clear the situation to prevent further occurrences for a while. (!!!!!!!!!!!)

Patches
Patches for various platforms are available via Patch 5648872.

Μάλλον "κάτι σάπιο υπάρχει στο βασίλειο της Δανιμαρκίας".
Αδέρφια DBAs, κουράγιο...


Υ.Γ.: τελικά, και αφού βάλαμε και το παραπάνω patch, φαίνεται ότι όλα δουλεύουν καλά (μέχρι την επόμενη φορά)

Τον ήπιαμε... (Oracle για πάντα! - part II)

Σε συνέχεια του προηγούμενου post (Oracle για πάντα), εγκαθιστούμε το patch 4960265 για την Oracle Database 10.2.0.2 για να διορθώσουμε το bug 4960265 και είμαστε σίγουροι ότι όλα πήγαν καλά (ώρα 16:00), τόσο στην primary rac database όσο και στη standby (όλες με ASM, άρα συνολικά 6 διαδοχικές εγκαταστάσεις του patch - 3 servers επί 2 oracle instances ανά server, ένα για το ASM και ένα για την Database), καθώς σε όλες τις περιπτώσεις το opatch utility μας επέστρεψε: completed successfully.

Αποφασίζουμε να τρέξουμε το query που μας έκανε να αντιληφθούμε το πρόβλημα και παίρνουμε error messages της μορφής:

parallel servers died unexpectedly.

Και κάθε φορά που τρέχουμε το query, νά'σου και ένα ξεγυρισμένο core dump με το παρακάτω error:

ORA-07445: exception encountered: core dump [qesblMerge()+580] [SIGBUS] [Invalid address alignment].

Άρα, αντί να λύσουμε το πρόβλημα, πήραμε κι ένα νέο! Άντε μετά να κάνουμε rollback το patch, και να φτάνουμε στο σημείο να πανηγυρίζουμε που τουλάχιστον καταφέραμε με το rollback να γυρίσουμε αισίως στην προηγούμενη προβληματική κατάσταση, με τα λανθασμένα μεν αποτελέσματα (βλ. προηγούμενο post) αλλά χωρίς 7445 errors και χωρίς core dumbs... (ώρα 18:30)

To αποκορύφωμα: η λύση που μας προτείνει η Oracle είναι εγκατάσταση του patchset 10.2.0.3 και μετά εγκατάσταση του one-off patch 4960265 on top of it !!!! Αφού βεβαίως προηγούμενα στη λίστα των fixed bugs του patchset 10.2.0.3 περιέχεται και το δικό μας !!!!

Τα παρατάω και φεύγω για διήμερη εκδρομούλα το ΠΣΚ.

Oracle για πάντα!

Αφού μας ταλαιπώρισε η Oracle εμάς, τουλάχιστον ας μην ταλαιπωρεί κι άλλους DBAs εκεί έξω:

περίπτωση 1η, Bug 4960265:
όταν τρέχεις ένα απλό

select count(*) from table_name;

περιμένεις πάντοτε το ίδιο αποτέλεσμα (όταν φυσικά ενδιάμεσα δεν υπάρχουν DML statements)... εκτός και αν έχεις RAC Database, οπότε μπορεί να συμβεί το ανεπανάληπτο:

In some cases when using a join filter in a RAC configuration
(parallel hash-join) wrong results can be produced.
Workaround: Turn off bloom filters by setting _bloom_filter_enabled
to FALSE.

Το θέμα είναι τι γίνεται αν έχεις παράξει ήδη εδώ και 2 χρόνια reports με στατιστικά από διασταύρωση στοιχείων στη βάση σου μέχρι να εντοπίσεις τυχαία το bug αυτό (να'ναι καλά η συνάδελφος που πρόσεξε κάτι που δεν της άρεσε στα αποτελέσματα του query της και άρχισε να ψάχνεται)


περίπτωση 2η, Bug 4612267:
κάντε πού και πού reboot τα Linux μηχανάκια σας με εγκατεστημένη Oracle 10.2.0.1, γιατί μετά από 248(!!!) ημέρες uptime η SQL*Plus ... κολλάει:

SQL*Plus With Instant Client 10.2.0.1 Hangs, When System Uptime
Is More Than 248 Days

Bill Gates ακούς;

Η αβάσταχτη ελαφρότητα του ωχαδερφισμού

Είναι στιγμές που απογοητεύεσαι και έρχεσαι αντιμέτωπος (για πολλοστή φορά) με την πραγματικότητα της παθογένειας του δημόσιου φορέα στην Ελλάδα και τη διαπίστωση ότι αυτή πηγάζει από τη νοοτροπία σημαντικού ποσοστού των εργαζομένων σε αυτό. Και όταν αυτή η νοοτροπία προέρχεται από την "παλιά φρουρά" των εργαζομένων (των 50 και πάνω δηλαδή), τότε κάπου μέσα σου λες ότι "εντάξει, έχουν μεγαλώσει αλλιώς και έχουν μάθει αλλιώς" (κάκιστα βέβαια, αλλά δεν είναι αυτό το θέμα μας). Όταν όμως αυτή η νοοτροπία, ο ωχαδερφισμός, βγαίνει μέσα από νέους ανθρώπους, τότε πραγματικά θες να πάρεις ένα ρόπαλο και ν' αρχίσεις να βαράς μέχρι να στρώσουν (βλ. και προηγούμενο post: "Αγαπητέ θεούλη, σε παρακαλώ...").


Related:
[1] "Ορισμός του Zamanfou" (πηγή: Wikipedia): "Zamanfou, also known as 'ohaderfismos' (Greek "Ωχαδερφισμός") is a minor counterculture phenomenon in Greece which involves social loafing as its principle characteristic". Και στη λεζάντα κάτω από τη φωτογραφία του φραπέ: "Frape coffee is often a symbol of cynical attitude".
[2] "Social loafing ή ωχαδερφισμός ή σταρχιδισμός ή… zamanfou" (πηγή: www.akyro.net)

Αγαπητέ θεούλη, σε παρακαλώ...

Δώσε μου γνώση να καταλάβω το αφεντικό μου και (κάποιους από) τους συνεργάτες μου,

Δώσε μου αγάπη να τους συγχωρήσω,

Δώσε μου υπομονή να καταλάβω τις πράξεις τους,

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

Όσα UPS κι αν έχεις...

Νόμος του Μέρφυ: "αν είναι να πάει κάτι στραβά, θα πάει..."

Εσύ έχεις δώσει ένα σκασμό λεφτά για να αγοράσεις UPS, servers με τα πάντα διπλά και τρίδιπλα (για full redundancy), έχεις στήσει τη βάση σου σε Oracle 10g RAC με δύο nodes (ώστε άμα κάτσει ο ένας να μη χάσεις τη βάση σου), παίρνεις hot backup τη βάση κάθε 12 ώρες και κάθε ώρα παίρνεις backup και τα archives, έχεις και standby database (έτσι, για να βρίσκεται όταν συμβεί η κακιά η ώρα), και αισθάνεσαι ήσυχος.

Αμ δε! (@#$!76%*(&^%$|{ ααααααργκ)

Καίγεται το ένα τροφοδοτικό στο standby server και σου κατεβάζει και τις δύο ασφάλειες στο πολύπριζο του Rack και τσααακ, παίρνεις τα πάντα στο χέρι (και RAC βάση, και standby server, και backup server, και expansion cabinet).

Και μετά, τρέχεις Παρασκευή μεσημέρι να σώσεις την κατάσταση, γιατί εν τω μεταξύ, έχεις και μερικά corrupted blocks στους τοπικούς δίσκους (λόγω της διακοπής παροχής ρεύματος) και δε σηκώνονται οι δύο από τους servers και πρέπει να γίνουν restore τα filesystems. Και πρέπει να περιμένεις και την εταιρία να έρθει να σου αλλάξει τροφοδοτικό.

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

Αμ δε! (@#$!76%*(&^%$|{ ααααααργκ)

Κάνε Reboot και ξαναμπές

Το πρόβλημα: ο client agent του grid control στους host servers που παρακολουθούνται από τον Enterprise Manager της Oracle εμφανίζει (μετά από restart με emctl agent stop/start) μεγάλη κατανάλωση μνήμης με συνεχώς αυξητικές τάσεις. Τελικά φτάνει στο critical warning threshold, οπότε... ξανά-μανά restart. Ώρα για service request στην εταιρία-"προφήτη".

Η (επίσημη) απάντηση: "In fact the agent has an internal mechanism that will restart the emagent process when it reaches 350M, in order to clear this "garbage" allocated memory."

Τα συμπεράσματα:
1. it's a feature, not a bug, ή αλλιώς "ναι, το ξέρουμε, εργαζόμαστε εντατικά πάνω σε αυτό, προς το παρών κάνε restart συχνά και σύντομα θα έχουμε τη λύση".
2. το παλιό καλό ρητό "βγες και ξαναμπές" είναι πάντα εδώ, αθάνατο, μέχρι να έρθει η επόμενη έκδοση του grid control, όπου ελπίζουμε να το έχουν λύσει, για να μη σπαταλάμε άδικα τα resources των συστημάτων μας.

Δουλειά του dba είναι...

• να παρακολουθεί και να φροντίζει για την απρόσκοπτη λειτουργία των βάσεων δεδομένων (error handling, debugging, patching, updating, monitoring),
• επεκτείνοντας στο monitoring, να συμβουλεύει τους χρήστες της βάσης για διορθωτικές κινήσεις που αποσκοπούν στη βελτίωση του performance, όταν παρατηρεί αδικαιολόγητο resource consumption οφειλόμενο στα προγράμματα των χρηστών,
• να φροντίζει για την ακεραιότητα των δεδομένων (διαδικασίες backup, διαδικασίες ανάκτησης σε περίπτωση απώλειας της βάσης, σχεδιασμός disaster recovery site ή/και standby database),
  
• να φροντίζει για την ασφάλεια των δεδομένων (διαδικασίες authorization, authentication, auditing),
• να βοηθά τους χρήστες στη σωστή λειτουργία των εφαρμογών τους, συμμετέχοντας ενεργά (και ίσως έχοντας τον πρώτο λόγο) στο σχεδιασμό του σχεσιακού μοντέλου για τα δεδομένα τους, και παρέχοντας συμβουλευτικές υπηρεσίες για τη σωστή και αποδοτική συγγραφή του κώδικα των εφαρμογών τους, και
  
• να κόβει κώλους κάθε φορά που κάποιος κάνει μαλακίες που θέτουν σε κίνδυνο όλα τα παραπάνω.
  

ΩΣΤΟΣΟ:

• o dba δεν είναι ο owner των δεδομένων των χρηστών,
• o dba δεν τρέχει dml queries στα data των χρηστών, ακριβώς επειδή δεν είναι ο owner αυτών των data,
• O dba δεν είναι υποχρεωμένος να αλλάζει διαδικασίες που είναι οι προτεινόμενες και οι ενδεδειγμένες και τρέχουν σωστά, επειδή η X εταιρία που ανέλαβε κάποιο έργο δεν μπήκε ποτέ στον κόπο να έρθει και να ενημερωθεί για αυτές τις διαδικασίες, και ακόμα χειρότερα έρχεται μία μέρα πριν και σου λέει "πρέπει να τρέξεις αυτό αύριο!"... Τον πούλο φίλε μου.

Καταλάβατε, ή θέλετε να κάνω και κακά μου;

Updated
όταν κάποιος μαθαίνει από το λάθος του (κατάλαβαν χωρίς να χρειαστεί να κάνω κακά μου), πολύ συχνά κάνει νέο λάθος. Τώρα ήρθαν και ρωτήσανε σχετικά με το πώς να τρέξει μία νέα διαδικασία, αλλά το επέκτειναν κιόλας. "Μήπως μπορείς να το γράψεις αυτό;!!!!". Εκεί τότε ξεκίνησε εντατικό μάθημα σχετικά με το ποια είναι και ποια δεν είναι η δουλειά του dba. Με μια μικρή αναγκαία προσθήκη σε όλα τα παραπάνω:

δουλειά του dba δεν είναι:

• να γράφει τις (PL/SQL) εφαρμογές των χρηστών, επειδή απλά και μόνο "πειράζουν" τα δεδομένα τους ("μα τα δεδομένα δεν είναι 'κομμάτι' της βάσης;" - πού πας ρε Καραμήτρο;)
  

Πότε είπε ότι το θέλει;

Ντριιιν (το τηλέφωνο, ώρα 12:15 μεσημβρινή)...
- (αυτός) "Γεια. Από την Χ Ομάδα σας τηλεφωνώ, θέλουμε να εκπαιδεύσουμε κάποιους συναδέλφους σε μία εφαρμογή και θέλουμε να φτιάξετε τη βάση για την εκπαίδευση."
- (εγώ) "ΟΚ, πού και πότε;"
- (αυτός) "Στον τάδε server. Λέμε να ξεκινήσουμε την εκπαίδευση αύριο το πρωί."
- (εγώ) "Ου χα χα χα χα χα χα χα, ρο χα χα χα χα χα χα."

Μπα σε καλό μου, γελάσαμε και πάλι σήμερα. Στη σειρά καλέ μου κύριε, στη σειρά πίσω από τους άλλους.

Υ.Γ. καιρό είχα να προσθέσω κάποιον στην επίσημη βλακ-list μου.

Οι περιπέτειες ενός dba... part II

• Τρίτη 5 Δεκ., ώρα 16:45. Μία από τις "αγαπημένες" μου ομάδες ανάπτυξης εφαρμογών μου ζητάει επίσημα να έχω έτοιμη το αργότερο μέχρι Τετάρτη 6/12 μια βάση με συγκεκριμένες προδιαγραφές, σχήματα και data. Το γεγονός ότι στην ομάδα τρέχουμε σα τρελλοί γιατί κάποιοι άνθρωποι (μερικές εκατοντάδες χιλιάδες) μπορεί να αντιμετωπίσουν πρόβλημα πληρωμών πριν τις γιορτές τους είναι αδιάφορο ("η σημαντικότερη δουλειά εδώ μέσα δεν είναι η δική μου;", "εσύ δηλ. τώρα ασχολείσαι με κάτι;")
  
• Τετάρτη 6 Δεκ., ώρα 14:00. Δε σφάξανε που θα σου έχω έτοιμο ό,τι εσύ θες όταν το θες (δηλ. χθες) αδιαφορώντας για το τι κάνω εγώ και αν έχω προτεραιότητες (σημαντικότερες)
• Πέμπτη 7 Δεκ., ώρα 12:30. Τηλεφωνώ για να ενημερώσω ότι "έλαβα την επιστολή και θα ασχοληθώ τη Δευτέρα 11/12". Με ενημερώνουν (πολύ ευγενικά, μιας και έλαβαν το μήνυμα της μη απάντησής μου στην επιστολή τους με τις προθεσμίες που είχαν "αποφασίσει και διατάξει") ότι "μήπως να χρησιμοποιήσουμε εκείνο το export που είχαμε πάρει τότε (την X ημερομηνία), γιατί μάλλον έχει τα data που χρειαζόμαστε για το τεστ μας;" Be my guest, μιας και θα κάνω μόνο ένα απλό full import (αλλά από Δευτέρα, για να μην ξεχνιόμαστε).
• Παρασκευή 8 Δεκ., ώρα 11:45. Με καλούν από την παραπάνω "αγαπημένη" ομάδα (μέλος του επίσημου βλακ-list μου). "Ξέρεις, τελικά δε χρειάζεται να κάνεις τίποτα από τα όσα είχαμε πει (βλ. παραπάνω bullets) μιας και η "βασούλα" (όπως λέμε Παπανδρέου) που έχουμε στο Y server είναι μια χαρά".

Να'στε καλά που φροντίζετε για την ψυχική μου ηρεμία, ειδικά στη διάρκεια μιας πολύ δύσκολης εβδομάδας που είχε προηγηθεί. Θυμήστε μου μόνο μια μέρα να σας συστήσω στον Ran-tan-plan. Θα κάνετε μια χαρά παρέα...

σχετικά posts:
[1] "alt.sysadmin.recovery" (adamo@http://adamo.wordpress.com)

Ο καλός dba-Νοστράδαμος ...

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

Ας υποθέσουμε λοιπόν ότι ο παραπάνω dba μόλις έχεις στήσει μια Oracle 10g και έχει κάνει full import μια βάση. Εχει δε ελέγξει (πέρα από τα logs του import) ότι οι δύο βάσεις (η αρχική βάση που έγινε export και η νέα) έχουν ταυτοτικά σχήματα. Οταν λοιπόν παίρνει τηλέφωνο ένα τέτοιο καλό παράδειγμα χρήστη και ρωτάει τον dba:

- γιατί δεν έχει ο Χ user της Oracle δικαιώματα στον Y πίνακα του Z user; Αφού εσύ έκανες ένα απλό full import (!!!)

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

1. ο χρήστης να είναι ήδη καταγεγραμμένος στη βλακ-list (από το black-list), οπότε πρέπει να αρχίσει να ερευνά διάφορα ενδεχόμενα, όπως:

• να μην υπάρχει ο πίνακας Y ή ο user Ζ (-Μα "μου είπαν" ή "νόμιζα" ότι υπήρχε. Είμαι σίγουρος ότι υπήρχε. Μήπως τον έσβησε κανένας; Μήπως διαγράφονται -!!!- αυτόματα από τη βάση κάποια αντικείμενα κατά λάθος;).
• να υπάρχει ο πίνακας Υ αλλά να δημιουργήθηκε μετά το import και να μην έχουν δοθεί τα απαραίτητα δικαιώματα (-Δεν το είδες ότι είχα δημιουργήσει νέο αντικείμενο; Και την άλλη φορά το ίδιο πρόβλημα είχα. Τελικά όλο προβλήματα δημιουργούνται στη δουλειά μας και μετά εμείς τα ακούμε και όχι "όσοι ευθύνονται"...)
• να συνδέεται σε λάθος βάση (-Μα πώς έγινε αυτό; Είμαι σίγουρος ότι έβαλα το σωστό connect string...)
• Δ.Ξ./Δ.Α. (αλλά και πάλι οι απαντήσεις του "πονηρού" χρήστη είναι ευρηματικές).

2. ο χρήστης να μην είναι σεσημασμένος, οπότε θέτει άμεση υποψηφιότητα για εγγραφή στη βλακ-list (αφού πρώτα χαθούν πολύτιμα λεπτά από το χρόνο του dba, που ανεβάζει ταυτόχρονα αδρεναλίνη και πίεση κατακόρυφα).

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