KelMan

Αυτό το SKU βλέπει όση μνήμη υποστηρίζει το OS στο οποίο κάθεται. http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx?PHPSESSID=0324345d45ef1bf1f764044e03584cd0 Αρκεί πάντοτε να είσαι σίγουρος ότι με την extra μνήμη θα βελτιωθεί όντως το σύστημα...

Κοίτα, μια λύση για να αποφύγεις το CPU cost είναι να κάνεις backup σε ένα folder που θα το έχεις shared και μετά να κάνεις το compress από άλλο PC.

Αν είχες πρόθεση να αγοράσεις SQL Server 2008 Enterprise τότε ναι, χάνεις το Backup compression. Διαφορετικά δεν το έχεις για να το χάσεις... [] Πάντως δεν είναι και τόσο killer feature καθώς το compression δεν είναι τόσο μεγάλο και έχει υπολογίσιμο overhead στο CPU utilization. Καλύτερα να εξετάσεις το σενάριο να αυτοματοποιήσεις τη διαδικασία κάνοντας zip (7z, rar, κλπ) το bak αρχείο μετά το backup.

H διαφορά είναι στα features. Αν μπορείς να κάνεις τη δουλειά σου με Express τότε όντως δεν χρειάζεται να επιβαρυνθεί ο πελάτης σου με 1500€, ειδικά στους χαλεπούς καιρούς που ζούμε. Και βέβαια, το πέρασμα σε Standard ή Enterprise είναι πάντοτε πολύ εύκολο, όταν αργότερα χρειαστεί.

Τρία πράγματα έγιναν και τελικά έπαιξε. Μπορεί να φταίνε και τα τρία ή μόνο κάποιο από αυτά, ωστόσο δεν είχα την πολυτέλεια του χρόνου για να δοκιμάσω ένα-ένα. Έχουμε και λέμε: 1. Μετά από σύσταση του fellow MCT Αντώνη Χατζηπαυλή, ότι υπάρχουν περιπτώσεις που μπορεί μια IP διεύθυνση να έχει ξεμείνει σε κάποια ARP cache, έγινε restart οποιουδήποτε device μπορεί να είχε ARP cache. 2. Τα παιδιά ξαναέστησαν το Windows 2003 Server cluster 3. Έκανα εγκατάσταση από slipstreamed prepared media (SQL Server 2008 + Service Pack 1 + Cumulative Updates 2 for SP1) Works like charm...

Όχι, δεν έχει σχέση... Δοκιμάζω ξανά τώρα με κάποιες αλλαγές στο strategy, θα ενημερώσω για την έκβαση.

Προσπαθώ να στήσω ένα SQL Server 2008 x64 cluster πάνω σε Windows Server 2003 x64 cluster αλλά αντιμετωπίζω το εξής πρόβλημα: Στο βήμα "Cluster Network Configuration" όπου θα πρέπει να δώσω την IP διεύθυνση που θα χρησιμοποιηθεί από το cluster του SQL Server, ο,τι διεύθυνση και να βάλω, παίρνω ένα validation error ότι αυτή η IP διεύθυνση χρησιμοποιείται ήδη ("The IP Address X is already in use. To continue, specify a different IP address."). Ο administrator μου έχει δώσει τρεις διαθέσιμες διευθύνσεις και αυτό συμβαίνει και για τις τρεις. Το θέμα είναι ότι έχω τσεκάρει τις διευθύνσεις με ping και δεν απαντά κανείς. Επίσης δεν υπάρχουν στα forward και reverse lookup zones του DNS και ούτε ανήκουν στο range του DHCP. Επιπρόσθετα, μπορώ άνετα να δηλώσω τη διεύθυνση αυτή ως resource στον cluster manager. Μια τελευταία σκέψη που έχω είναι να φτιάξω ένα slipstreamed setup dir για τον SQL Server με το SP1 και τo cumulative update και να δοκιμάσω ξανά το setup. Έχει κανείς άλλος καμιά ιδέα;

Υπάρχουν διάφοροι λόγοι για τους οποίους μπορεί να μην αξιοποιούνται και οι τέσσερις επεξεργαστές. Γενικά ο SQL Server προκειμένου να αποφασίσει πώς θα τρέξει ένα query ελέγχει τι κόστος έχει το query και ποιοί επεξεργαστές είναι διαθέσιμοι. Επιπρόσθετα, ανάλογα το execution plan (μέρος του οποίου είναι και το πώς θα κάνει τα joins) τελικά καταλήγει στο πόσους επεξεργαστές θα χρησιμοποιήσει. Τυπικά, σε περιπτώσεις ως 8 επεξεργαστές δεν χρειάζεται να πειράξεις τίποτα. Αν μένουν unitilized επεξεργαστές, πιθανότατα σημαίνει ότι λείπουν indexes ή ότι χρησιμοποιούνται λανθασμένα indexes. Μου έχει τύχει σε performance auditing να το διαπιστώσω από πρώτο χέρι. Από την άλλη μην ξεχνάς ότι ο SQL Server έχει multi user φιλοσοφία που σημαίνει ότι το τι θα διαλέξει να κάνει μπαίνει πάντοτε κάτω από το πρίσμα ότι μπορεί να ζητήσουν το ίδιο κι άλλοι χρήστες στη συνέχεια. Έτσι λοιπόν, το query engine πάντοτε προσπαθεί να κρατάει ισοροπία μεταξύ performance και resources. Αυτήν την ισοροπία "πειράζεις" με το OPTION(MAXDOP)! Μπορεί το query εκείνη τη στιγμή να πάει σφαίρα, αλλά αν συμβεί αυτό για όλους τους χρήστες ενδεχομένως να υπάρχει πρόβλημα.

Με 80$ πάντως, μπορείς να αγοράσεις agent από τρίτο κατασκευαστή: http://www.valesoftware.com/products-express-agent.php

Δεν πολυκατάλαβα τι εννοείς λέγοντας "o admin backup (backup agents)" ωστόσο γενικά, σαφώς και μπορείς να παίρνεις backup και ακόμη να προγραμματίσεις jobs για τα backup αυτά. Από εκεί και πέρα, το backup του SQL Server δεν είναι καθόλου απλώς μια αντιγραφή του mdf. Κατά τη διάρκεια του backup γίνονται διάφορες "δουλειές" εσωτερικά, οπότε ούτε να το σκεφτείς να κάνεις κάποια κομπογιανίτικη λύση του τύπου αντιγράφω-το-mdf-αρχείο.

Μπορείς να δοκιμάσεις να βάλεις το τελευταίο MDAC αλλά δεν κρατάω την ανάσα μου ότι θα πετύχει. Κυρίως γιατί φαντάζομαι ότι το source connection είναι για τον συγκεκριμένο τύπο αρχείου. Αν αλλάξεις το connection type για να παίζει με Excel 2003 format, τότε θα χρειαστεί να ξαναορίσεις τα mappings, κλπ. Μια τελευταία λύση που σκέφτομαι είναι μήπως γλυτώσεις κάτι τέτοιο αν αποθηκεύσεις το πακέτο με μορφή vb script ώστε να πειράξεις τον κώδικα και να μην αφήσεις τον designer να σου χαλάσει τα mappings.

*speechless* Ποιό κλειδί ήταν; Θυμάσαι;

Δυστυχώς δεν μπορώ να σκεφτώ κάτι άλλο... Στην περίπτωση που το δώσεις ως incident, ελπίζω να μην είναι τελικά καμιά !@#$%@$#%^$ και βαράμε το κεφάλι μας που δεν το σκεφτήκαμε! Ωστόσο, θα ήθελα πολύ να μάθω τελικά τι έφταιγε...

Άρα δηλαδή, αν κατάλαβα καλά, το πρόβλημα είναι ανάμεσα στον server και τον συγκερκιμένο client. Ο server παίζει με άλλον client και ο client παίζει με άλλον server;

Οι ρυθμίσεις στο security όπως τις είχες δεν επέτρεπαν καν τη σύνδεση στο Linked Server καθώς ουσιαστικά έλεγαν: "Πάρε τα παρακάτω logins (δλδ κανένα) και κάντα map σε accounts και αν κάποιο login πάει να κάνει connect και δεν είναι στη λίστα (πράγμα που συμβαίνει πάντα αφού η λίστα είναι άδεια) τότε κάνε connect στον linked server χωρίς να προσδιορίσεις security context (ενώ η Access χρειάζεται το Admin/(null password) συνδυασμό)". Άρα, αυτή η αλλαγή χρειάζεται όπως και να έχει. Μερικά άλλα πράγματα για να τσεκάρεις: Αν φέρεις το mdb αρχείο της Access στον Server, εξακολουθεί να υπάρχει το πρόβλημα; Στον file server έχεις το ίδιο MDAC που έχεις και στον SQL Server; Αν ο SQL Server παίζει πάνω σε Windows 2003 Server, τότε έχεις το MDAC 2.8. Στον fileserver τι MDAC έχεις; Στοn file server και στον server που βρίσκεται ο SQL Server είναι εγκατεστημένος και τρέχει o Distributed Transaction Coordinator (από Administrative Tools > Component Services); Τώρα, αν τελικά τίποτα από τα παραπάνω δεν παίξει, μπορείς να δοκιμάσεις το step-by-step configuration που αναφέρει στο http://msdn.microsoft.com/en-us/library/ms175866.aspx για να δούμε αν παίζει αυτό; Αν παίζει, θα πρέπει να δεις είναι οι διαφορές σε σχέση με το δικό σου setup.

Ωραία, για δοκίμασε να πας πας στο Security page και στα mappings να προσθέσεις ένα login του SQL Server το οποίο θα το βάλεις να αντιστοιχεί στον remote user "Admin" με κενό password. Κατόπιν, κάνε login από remote SSMS με αυτό το login και προσπάθησε να στείλεις ένα query στον Linked Server.

Μόλις τελείωσα ένα test environment με virtual machines για να δοκιμάσω το setup των linked server στον SQL Server 2005. Στο setup του Linked Server ακολούθησα αυτά http://msdn.microsoft.com/en-us/library/ms175866.aspx ώστε να έχουμε κοινό reference στη δοκιμή. Στον client είδα αμέσως τη βάση χωρίς πρόβλημα και χωρίς να κάνω κάποια extra ρύθμιση. H ενεργοποίηση του OPENROWSEΤ στο Surface Configuration Tool δεν χρειάστηκε.

Χμμμ... Δεν καταλήγουμε πουθενά έτσι... Όπως σου ανέφερα στο προ-προηγούμενο μήνυμα, χωρίς να δούμε τις ρυθμίσεις του linked server, κάνουμε εικασίες. Το upgrade που έκανες δεν είναι απλό, άλλαξες και έκδοση λειτουργικού αλλά και έκδοση SQL Server. Εξάλλου, o SQL Server 2005 είναι τελείως διαφορετικό ζώο ως προς το θέμα του security. Ως DBA δεν θα θεωρούσα ότι υπάρχει καμία εγγύηση και δεν μου λέει τίποτα το ότι στο documentation αναφέρει ότι "ΘΑ ΠΡΕΠΕΙ" να παίζει ή όχι (γι αυτό και τα upgrades γίνονται πρώτα δοκιμαστικά στο testing environment). Οπότε που καταλήγουμε: Στο ότι υπάρχει ένα πρόβλημα και θα πρέπει να λυθεί πράγμα που σημαίνει θα πρέπει να ακολουθήσουμε μια μεθοδολογία για να απομονώσουμε το λάθος. Οι μεθοδολογίες στον SQL Server ξεκινούν bottom-up ή top-down. Bottom-up είναι (χονδρικά) η σειρά: Server H/W, Server O/S, SQL Server, Client App, O/S client, H/W client. Top-down είναι το ανάποδο. Στη συγκεκριμένη περίπτωση, αφού είμαστε σίγουροι ότι έχει γίνει σωστά το Surface Area Configuration και εφόσον βλέπουμε ότι από Server συνδεόμαστε ενώ από client όχι τότε καλύτερα να πάμε Top-down. Στα γρήγορα, κάνουμε τον εξής έλεγχο: Αν δούμε ότι από client SMSS μπορούμε να συνδεθούμε σε οποιαδήποτε άλλη βάση του Server, αλλά όχι στον Linked Server, τότε κατά 99% είναι θέμα security ρυθμίσεων του SQL Server και του Linked Server. Αν τώρα είχαμε τις ρυθμίσεις στο Security στα properties του Linked Server θα μπορούσαμε να δούμε ένα request που ξεκινάει από τον client, πώς φτάνει στον server από άποψη security context. Εξάλλου, το error 7303 αναφέρει ότι το λάθος συμβαίνει σε ένα από τα δύο πράγματα: One of the initialization parameters specified in sp_addlinkedserver (data_source, location, provider_string, or catalog) is incorrect for this provider. Login and password sent to the provider is invalid. Βέβαια, δεν είναι η πρώτη φορά που κάτι άλλο πραγματικά φταίει και άλλο μήνυμα λάθους εφανίζεται, ωστόσο πρν αρχίσουμε να ψάχνουμε τις κουφές αιτίες, ελέγχουμε το τι γίνεται με τα παραπάνω. Εδώ κολλάει το "πριν το upgrade δούλευε" μιας και εφόσον δεν έχουν αλλάξει οι ρυθμίσεις του Linked Server, μάλλον στη δεύτερη αιτία οφείλεται το πρόβλημα. Τώρα, το πώς γίνεται logon στον SQL Server από τον client (με sa ή με domain admin account ή whatever), ενδέχεται να μην έχει καμία σημασία καθώς μπορεί στο Securiy tab (να το πάλι!) του Linked Server να έχουν ορισθεί τα mappings με τέτοιο τρόπο που να εμποδίζουν τη σύνδεση. Προσοχή: Άλλο πράγμα το πώς συνδέεσαι στον SQL Server μέσω SSMS και άλλο ο Linked Server. Στον Linked Server ισχύουν τα mappings που ορίζεις, τα οποία "μεταφράζουν" τα security credentials ώστε να μπορεί να τα καταλάβει o Linked Server (είτε πρόκειται για Access ή για Excel ή για Oracle) αφού ο Linked Server δεν καταλαβαίνει από το security του SQL Server. Περισσότερα για το security σε Linked Servers δες εδώ: http://msdn.microsoft.com/en-us/library/ms175537.aspx

Πιστεύω ότι το πρόβλημα είναι στο setup του linked server. Δες τις λεπτομέρειες στο προηγούμενο post μου.

Ολόκληρο το μήνυμα λάθους; Πάντως όπως και να έχει, το setάρισμα ενός linked server αποτελείται από πολλές ρυθμίσεις. Χωρίς να τις βλέπουμε αυτές, απλά κάνουμε ικασίες. Για παράδειγμα, ιδιαίτερα σημαντικές είναι αυτές του security tab ώστε να "μεταφραστούν" σωστά τα credentials καθώς περνάνε από τον client στον server. Εκεί τι ρυθμίσεις έχεις κάνει; Μήπως το local login είναι κανένα orphaned user account που έχει προέλθει από backup/restore της βάσης; Επίσης, στο "Server Options" tab, έχεις ενεργοποιήσει το Rpc και Rpc out;

Πάμε άλλη μία: Όταν είσαι remotely, μέσω SSMS, παίζεις κανονικά με τον linked server, ενώ όταν είσαι πάνω στον server τρως "access denied"? Επίσης, μπορείς να κάνεις post ολόκληρο το μήνυμα λάθους;

Ρίξε μια ματιά στα services του SQL Server και βεβαιώσου ότι τα accounts τα οποία χρησιμοποιούν έχουν επαρκή δικαιώματα για να κάνεις ...ό,τι κάνεις τέλος πάντων (γιατί δεν πολυκατάλαβα πότε παρουσιάζεται το πρόβλημα και πότε όχι) Καλό είναι να μην αφήσεις το localhost και να βάλεις ένα domain account ώστε να μπορείς να ελέγξεις πλήρως τα δικαιώματά του.