Αγαπητοί SQL experts, υπάρχει τρόπος να αναγκάσω μια stored procedure η οποία εκτελείται σε ένα linked server να σταματήσει να εκτελείται μετά την παρέλευση ενός χρονικού διαστήματος πχ 10 λεπτών, εαν σε αυτό το διάστημα δεν έχει ήδη εκτελεστεί; Κάτι έχω βρεί εδώ πέρα αλλά δεν είμαι βέβαιος αν μου κάνει γιατί είναι λιγάκι ασαφές...

---

Coding at Mediterranean Acoustics

Γιατί ασαφές; Το δοκίμασες; Μπορείς να το δοκιμάσεις εύκολα αν φτιάξεις μια remote SP με ένα WAITFOR statement.

---

Vir prudens non contra ventum mingit

Αυτό που μου είναι ασαφές είναι το πού πρέπει να γίνει configure αυτός ο αριθμός. Στον δικό μου Server ή στον linked Server; Άν είναι στον linked Server δεν μου κάνει γιατί δεν έχω έλεγχο επ αυτού(δεν είναι ούτε SQL Server). Αν είναι στον δικό μου τότε δεν δουλεύει γιατί το έχω στα 600 δευτερόλεπτα ενώ το query τρέχει για... μέρες!  

---

Coding at Mediterranean Acoustics

Στον δικό σου server πρέπει να γίνει configure. Για την ακρίβεια πρέπει να setάρεις το Query Timeout property στα settings του linked server.

---

Vir prudens non contra ventum mingit

To setαρα και αυτό, αν και το documentation λέει ότι αν είναι 0 τότε χρησιμοποιεί το Remote Query Timeout του Server. Για να δούμε...

---

Coding at Mediterranean Acoustics

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

Υποψιάζομαι ότι το query που περιγράφεις δημιουργεί κάποιο report. Αν το query όπως λες παίρνει μέρες θα πρέπει να ξαναγραφτεί επειγόντως. Όλα τα άλλα μέτρα είναι απλά "ασπιρίνες" οι οποίες μπορεί να ελαφρύνουν στιγμιαία το πρόβλημα. Το πρόβλημα θα επιστρέψει όμως, πολύ συντομότερα απ' ότι νομίζεις και σε πολύ χειρότερη μορφή. Έχω αντιμετωπίσει κι εγώ queries τα οποία ήθελαν 4 μέρες να τελειώσουν και οι προηγούμενοι προγραμματιστές είχαν προσπαθήσει να τα αντιμετωπίσουν με "ασπιρίνες". Το αποτέλεσμα ήταν ότι στο τέλος κανείς δεν ήξερε όχι πως συμπεριφερόταν το query, αλλά ούτε καν αν τα αποτελέσματα του ήταν αξιόπιστα (δεν ήταν). Και το query αυτό επέστρεφε χρηματικά ποσά αξίας πολλών χιλιάδων ευρώ. Τα οποία στέλνονταν ως statement στους πελάτες χρηματιστιριακής. Και ήταν σχεδόν πάντα λάθος.

Πρόβλημα. Ασπιρίνη. Όοοοοοοχιιιιιι.

Μετά υπήρχε και το άλλο πρόβλημα. Τελικά το query, λόγω ενός κακώς (ή μάλλον τυχαία) σχεδιασμένου loop ανά πελάτη, ανά μήνα, ανά μετοχή, έπρεπε να τρέξει μέχρι τέλους για να φέρει σωστά αποτελέσματα. Το αποτέλεσμα ήταν ότι όταν το query σταμάταγε είτε λόγω timeout είτε επειδή ο χρήστης πάταγε το Cancel, τα αποτελέσματα που επέστρεφε ήταν λάθος, όχι όμως με τον ίδιο τρόπο. Για άλλους πελάτες μπορεί να ήταν σωστά, για άλλους λάθος.

Long Query. Timeout. Noooooooooooo.

Από εκεί και πέρα, αντί να καλείς ένα μεγάλο query μέσω του server σου και να βασίζεσαι στα timeouts υπάρχουν άλλοι, πολύ καλύτεροι τρόποι να το κάνεις και να ελέγξεις τη συμπεριφορά του. Μπορείς καταρχήν να συνδεθείς απευθείας από τον κώδικα σου με το remote server και να εκτελέσεις το περίεργο query ασύγχρονα και να γράψεις τα αποτελέσματα σε temporary πίνακες στη δική σου βάση. Ακόμη καλύτερη λύση είναι να περιορίσεις την ανάγκη για τέτοια πολύ μεγάλα queries. Αν μπορείς, καλό είναι να αποθηκεύεις παλαιότερα αποτελέσματα σε ένα ειδικό πίνακα για να μην χρειάζεται να τα ξαναϋπολογίσεις. Μπορείς να αντιγράψεις κάποια δεδομένα από τον άλλο server στο δικό σου και έτσι να περιορίσεις την ανάγκη να μιλάς με τον άλλο server. Μπορείς να φτιάξεις ένα κύβο στα Analysis services που θα σου δώσει τα ίδια αποτελέσματα σε χρόνο δευτερολέπτων όμως αντί για μέρες ή ώρες.

Από την άλλη, αν το query δεν έχει να κάνει με reporting αλλά π.χ. με update δεδομένων, πάλι θα πρέπει να βελτιώσεις το query αλλά αυτή τη φορά τα επόμενα βήματα είναι διαφορετικά. Η μία λύση είναι πάντα να καλέσεις το query ασύγχρονα από τον κώδικα σου. Μία καλύτερη λύση είναι να χρησιμοποιήσεις το Service Broker του SQL Server για να εκτελέσει αυτός το query για σένα ασύγχρονα στον άλλο server. Έτσι δεν χρειάζεται να γράψεις επιπλέον κώδικα για την ασύγχρονη εκτέλεση και την αντιμετώπιση σφαλμάτων.

Τελικά μάζεψα εκείνο το query που ήθελε 4 ημέρες και το έκανα να τρέχει σε 2 ώρες. Αν είχα χρησιμοποιήσει Analysis Services θα το είχα κάνει να τρέχει σε 15 λεπτά, αλλά η εταιρεία ήθελε να τρέχει λέει η χρηματιστηριακή εφαρμογή και σε ... Windows XP με SQL Server 2000.

Μεγάλα Queries. Ασπιρίνες. Όχι άλλο κάρβουνο!

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Βρε Παναγιώτη, ποιος είπε ότι το query είναι μεγάλο(άδικος κοπος τα γραφόμενα); Το πρόβλημα είναι άλλο αλλά δεν ξέρω που.  Για να το ξεκαθαρίσουμε λοιπόν. Έχουμε το εξής σενάριο. Έχουμε μιά Βάση Δεδομένων η οποία έχει κάποια δεδομένα. Αυτή η βάση πρέπει ανά τακτά χρονικά διαστήματα να μεταφέρει κάποια από τα δεδομένα(δυο τρείς εγγραφές) σε μιά άλλη βάση, άλλης εφαρμογής, άλλης εταιρίας. Ο τρόπος που επιθυμεί η άλλη εταιρία να γίνεται αυτή η μεταφορά είναι να προσθέtουμε ώς linked server στον δικό μας server τον δικό τους και να εκτελούμε συγκεκριμένες SP ανα τακτά χρονικά διαστήματα(jobs). To ξέρω, δεν είναι ο καλύτερος τρόπος, το έχω πεί και έχω προτείνει άλλες λύσεις. Ομως για τώρα αυτός είναι και δεν είναι θέμα συζήτησης. Τώρα το πρόβλημα είναι το εξής. Ανά τακτά χρονικά διαστήματα το job κολλάει χωρίς μάλιστα να δίνει κάποιο σημάδι ότι κάτι συμβαίνει. Ο agent δείχνει ότι το job γίνεται executed.. για μέρες. Ο activitiy monitor δεν δείχνει τίποτα ούτε locks ούτε blocked by ούτε τίποτα. Την ίδια στιγμή οι τεχνικοί από απέναντι δηλώνουν ότι ούτε καν έχει ανοίξει connection με την απέναντι βάση. Η κατάσταση επιλύεται μόνο με την επανεκκίνηση του job η του agent είτε και κάποτε ολόκληρου του sql Server. Αυτό που ψάχνω τώρα είναι κάποιος τρόπος να κάνω detect ότι έπεσε κόλλημα και να σταματάω είτε το query είτε το job και τότε αυτό να ξαναδοκιμάζει. Σε αυτό το στάδιο το job είναι configured να ξαναδοκιμάζει σε περίπτωση αποτυχίας αλλά εδώ η προϋπόθεση είναι να σου δώσει το μύνυμα ότι απέτυχε. Το πρόβλημα εδώ είναι ότι δεν έχω ούτε το μήνυμα της αποτυχίας. Το job εκτελείται επ άπειρον...

Οιεσδήποτε εισηγήσεις από καθαρά μυαλά και out of the box thinkers ευπρόσδεκτες γιατί μαζί με το job κόλλησε και το μυαλό μου!

---

Coding at Mediterranean Acoustics

Άρα το θέμα είναι γιατί το rpc δεν φτάνει μέχρι απέναντι και γιατί κολλάει το job... Κατ' αρχήν για τι γραμμή μιλάμε; Επίσης, το rpc μέσα από το SSMS τρέχει κανονικά; Και αν ναι, πόσο χρόνο κάνει μέχρι να πάρεις τα data πίσω; Πάντως μου μυρίζεται συστεμικό πρόβλημα... (υποθέτω έχεις βάλει το SP 2 ε;)

---

Vir prudens non contra ventum mingit

Μάνο το ποιό πιθανό σενάριο (εγώ είμαι βέβαιος) είναι να είναι θέμα connectivity. Απ ότι έχω ενημερωθεί ο απομακρυσμένος server συνδέεται ασύρματα με το internet. Το θέμα είναι πώς εντοπίζω το πρόβλημα και πώς το χειρίζομαι από την πλευρά του job. Γενικά η όλη διαδικασία δεν θέλει πάνω από 1 λεπτό να ολοκληρωθεί. Ναι, το SP2 είναι πάνω. Το job εκτελεί κάποια select και insert εκατέρωθεν αλλά πάντα κολλάει σε statement που εκτελείται στον linked server. Βασικά το όλο ζήτημα είναι η ανταλλαγή κρατήσεων μεταξύ του εσωτερικού συστήματος και του web site ξενοδοχείου. Κλασική περίπτωση χρήσης web services ...

---

Coding at Mediterranean Acoustics

Pak:

Βασικά το όλο ζήτημα είναι η ανταλλαγή κρατήσεων μεταξύ του εσωτερικού συστήματος και του web site ξενοδοχείου.

Και ασύρματο??? Αυτό τραβάει ευχέλαιο! Ε, να μην έχει μερικά προβλήματα connectivity? Οι linked servers ΔΕΝ φτιάχτηκαν για occasionally connected σενάρια! Ότι και να λένε, όσο καλή σύνδεση και να νομίζουν ότι έχουν, οι ασύρματες συνδέσεις δεν είναι ποτέ σταθερές. Ένα ACK πακέτο να χαθεί, δεν θα μάθεις ποτέ ότι η σύνδεση σου πέτυχε ή όχι.

Δυστυχώς, εδώ έχεις μία περίπτωση ασπιρίνης για εγκεφαλικό. Για το άμεσο πρόβλημα, θα πρέπει να ορίσεις μή μηδενικές τιμές για το Connection Timeout στον ορισμό του linked server. Έτσι ίσως μπορέσεις να αντιληφθείς ότι η σύνδεση στον linked server απέτυχε έγκαιρα. Αν το έχεις αφήσει στο 0 ο δικός σου server θα περιμένει αιωνίως για ένα ACK πακέτο το οποίο μπορεί να έχει χαθεί λόγω παρεμβολών. Αυτό όμως δεν θα σε προστατέψει αν χαθούν κάποια πακέτα που σου λένε ότι ολοκληρώθηκε η εκτέλεση του query. Γι αυτό θα πρέπει επίσης να ορίσεις timeouts και στα jobs έτσι ώστε να έχεις άλλο ένα επίπεδο ελέγχου.
Αν τώρα τα statements που εκτελείς στον linked server μπορούν να εκτελεστούν πολλαπλές φορές χωρίς πρόβλημα (αυτό λέγεται idempotent operation) μπορείς να ορίσεις retries στο job σου έτσι ώστε να ξαναπροσπαθήσει π.χ. σε 2 λεπτά αν διαπιστώσει ότι κάτι δεν πάει καλά. Μετά μπορείς να ορίσεις τί θα συμβεί αν αποτύχει το job μετά από κάποια retries, έτσι ώστε είτε να γράψεις κάποιο μήνυμα σε ένα log ή να στείλεις ένα email σε κάποιον operator.

Ο τρόπος που δουλεύει αυτό το σύστημα πάντως δεν είναι και ότι καλύτερο! Το να ζητάς κάποιο άλλο σύστημα να σου κρατάει κλειδωμένες εγγραφές στη βάση για ένα ολόκληρο λεπτό είναι συνταγή για blocks και προβλήματα. Αυτό που χρειάζεται εδώ δεν είναι web services, τα οποία ουσιαστικά είναι άλλη μία μορφή RPC, αλλά η σχεδίαση των δύο συστημάτων έτσι ώστε να ανταλλάσσονται μηνύματα μεταξύ τους μέσω κάποιου queue. Εσύ βάζεις ένα μήνυμα στο δικό σου queue και αυτό αναλαμβάνει να το στείλει στο queue του παραλήπτη. Εκεί το μήνυμα διαβάζεται και εκτελείται κάποιος κώδικας με βάση αυτό. Τα δύο queues και ο μηχανισμός που τα υποστηρίζει αναλαμβάνουν να μεταφέρουν το μήνυμα με ασφάλεια στην άλλη πλευρά, ακόμα και αν η σύνδεση μεταξύ των δύο queues διακοπεί. Σε περίπτωση που δεν υπάρχει σύνδεση την ώρα που εσύ στείλεις ένα μήνυμα, αυτό θα σταλεί μόλις η σύνδεση αποκατασταθεί. Σε περίπτωση που το μήνυμα χαθεί, ξαναστέλνεται χωρίς όμως να φτάνουν στο τέρμα διπλά μηνύματα.

Αυτό γίνεται ήδη σε επίπεδο SQL Server με τον SQL Service Broker. Αφού οριστούν τα endpoints στους δύο servers και η επικοινωνία μεταξύ τους, εσύ γράφεις ένα μήνυμα στο ένα endpoint και ο Service Broker θα φροντίσει να φτάσει στο άλλο endpoint. Μόλις λάβει το μήνυμα ο άλλος server θα εκτελέσει ένα stored procedure με τις παραμέτρους του μηνύματος. Μάλιστα, υπάρχει και η υποστήριξη transaction έτσι ώστε αν εσύ κάνεις rollback να μην σταλεί το μήνυμα σου στον άλλο server. Αντίστοιχα, αν ο άλλος server κάνει rollback, το μήνυμα παραμένει στο endpoint και περιμένει να εκτελεστεί αργότερα.
Το παραπάνω σενάριο μπορεί να γίνει και με WCF και MSMQ αλλά αν οι δύο servers ήδη μιλάνε μεταξύ τους, ο Service Broker θα είναι η ευκολότερη λύση.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Ο SQL Service Broker ήταν η πρώτη μου σκέψη αλλά ο linked server δεν είναι SQL Server που φαντάζομαι ότι αυτό απότελεί προϋπόθεση(αν όχι τότε να το ξανασκεφτώ). Όσο για τα web services η ιδέα ήταν να απόφευχθεί η αντάλλαγή μυνημάτων μέσω queue αλλά τα δεδομένα να απόστέλλονται και να λαμβάνονται απευθείας από το κεντρικο σύστημα το οποίο θα μπορούσε να κάνει expose κάποια web services για αυτές τις λειτουργίες.

 Τέλοσπάντων μας μένουν τώρα οι ασπιρίνες. Στον linked server έχω θεσει connection timeout και query timeout. To job είναι ρυθμισμένο σε περίπτωση αποτυχίας να ξαναδοκιμάζει και να μου στέλει email. Αλλά τώρα επανέρχομαι στην αρχική μου απορία. Πώς μπορώ να τερματίσω το query ή το job μετά την παρέλευση ενός χρονικού διαστήματος και εφόσον αυτό ακόμη εκτελείται και δεν έχει δώσει ούτε μύνημα λάθους ούτε επιτυχίας;

---

Coding at Mediterranean Acoustics