Καλησπέρα σε όλους,

Πρόσφατα αναβάθμισα έναν Sql server από 2000 σε 2005. 

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

Έχω τρέξει και την διαδικασία update statitistics όπως αναφέρεται σε σχετικό άρθρο.

Η κατάσταση είναι πραγματικά τραγική και δεν ξέρω αν το πρόβλημα οφείλεται στο στήσιμο του sql server  ή το hardware δεν μπορεί να υποστηρίξει την έκδοση 2005 ή κάτι άλλο που δεν έχω κάνει. 

Χαρακτηριστικά αναφέρω πως μέσα από αυτήν την εφαρμογή μια συγκεκριμένη εγγραφή στον 2000 την άνοιγε σε 1 έως 2 δευτερόλεπτα,

στον 2005 κάνει από 8 έως 10 λεπτά και καμία φορά δεν την ανοίγει και καθόλου και σκάει.

Το μηχάνημα είναι ένα pentium 4 στα 3,66 Ghz με 2 GB Ram και σκληρό 200GB.

Έχει κανείς ιδέα που πρέπει να εστιάσω;

Ευχαριστώ πολύ!

---

Best Regards

Τσέκαρες τα indexes? Αν είναι ΟΚ, όπως ήταν και πριν την αναβάθμιση;

---

Dimitris-Ilias Gkanatsios
Developer Evangelist, Microsoft Hellas

My Blog
StudentGuru
Twitter
Facebook

Καλησπέρα και ευχαριστώ για το ενδιαφέρον

Όχι δεν τα έχω τσεκάρει θα το κάνω πρωϊ πρωϊ άυριο.

Είναι αλήθεια πως απαιτείται πολύ RAM για να παίζει σωστά ένας SQL 2005 (Από άθρα που βρήκα στο Internet αναφέρουν κάτι για 8GB RAM ???)

Αν είναι αλήθεια η μνήμη που έχει αυτός ο server είναι το 1/4 από αυτό που χρειάζεται.

 

---

Best Regards

Το 8GB μου φαίνεται πολύ υπερβολικό.Όλα εξαρτώνται βέβαια από το μέγεθος της βάσης, των πόσων ταυτόχρονων connections μπορεί να έχεις, αν θα έχεις κάποιο merge replication και πολλούς άλλους παράγοντες. Anyway, δες και πες μας

---

Dimitris-Ilias Gkanatsios
Developer Evangelist, Microsoft Hellas

My Blog
StudentGuru
Twitter
Facebook

To performance tuning έχει συνήθως δύο προσεγγίσεις, bottom-up (από το H/W προς το client application) και top-down (από το client application προς το H/W). Βασική προϋπόθεση είναι να έχει προηγηθεί perforance auditing ώστε να μπορείς να συγκρίνεις τις μετρήσεις που ελέγχεις σε σχέση με "φυσιολογικές" μετρήσεις. Αν δεν έχει προηγηθεί performance auditing, τότε προχωράς με εικασίες...

Από εκεί και πέρα, το τι προσέγγιση θα ακολουθήσεις είναι θέμα εμπειρίας. Το ζητούμενο είναι να εντοπίσεις το γρηγορότερο δυνατόν το πρόβλημα, ωστόσο το σωστό είναι να ολοκληρωθεί η διαδικασία από άκρη σε άκρη ώστε να είναι σίγουρο ότι έχεις εντοπίσει την αιτία και όχι το σύμπτωμα. Ενδεικτικά, η bottom-up διαδικασία συμπεριλαμβάνει τουλάχιστον (καθώς υπάρχουν περίπτωσεις με πιο περίπλοκα συστήματα high-availability, κλπ) τα παρακάτω:

1. Έλεγχο H/W configuration
2. Έλεγχο ΛΣ configuration
3. Έλεγχο SQL Server configuration
4. Έλεγχο Database configuration
5. Έλεγχο Database objects (triggers, jobs, κλπ)
6. Έλεγχο Indexes
7. Έλεγχο queries
8. Έλεγχο client data-access code

Η top-down προσέγγιση πάει ανάποδα. Στην περίπτωσή σου τα στοιχεία που δίνεις είναι πολύ λίγα για να βγει οποιοδήποτε συμπέρασμα. Εγώ θα ξεκινούσα από το 7 καθώς η client εφαρμογή δεν έχει αλλάξει και ιδιαίτερα αν είναι black-box, δεν μπορείς να κάνεις και πολλά γι αυτήν. Χρησιμοποίησε τον Profiler να δεις που ακριβώς οφείλεται η καθυστέριση και από κει και πέρα... βλέποντας και κάνοντας.

---

Vir prudens non contra ventum mingit

Καλημέρα σε όλους.

Ένα Ελληνικό Ρητό έχει δίκιο που λέει όταν κοιτάς μόνο το δέντρο δεν μπορείς να δεις το δάσος έχει απόλυτο δίκιο. Το πρόβλημα παιδιά δημιουργήθηκε άπό ένα περίεργο firewall που έιχε εγκαταστήσει ο πελάτης και κατά την εκτέλεση ενός απλού query το περνούσε από τα χίλια μύρια  κύματα μέχρι να το αφήσει να πάρει τα records που χρειάζοταν.

Παλέυω με αυτό το πράμα τις τελευταίες 3 μέρες κια ελέγχω τον sql server, την βάση δεδομένων ακόμη και το κώδικα έλεγξα της εφαρμογής αλλά τελικά η αιτία ήταν το firewall.

Καλή δύναμη παιδιά και καλό κουράγιο!

---

Best Regards