Υπήρχε στο παρελθόν , καταργήθηκε (καλώς) και επανέρχεται (με εντελώς νέο τρόπο)  ;)

Έτσι και αλλιώς τα δεδομένα σου είναι στην μνήμη (buffer cache) (http://www.sqlschool.gr/blog/μια-μικρή-βουτία-στα-άδυτα-της-αρχιτεκτονικής-μιας-βάσης-107.aspx)

Αν εξασφαλίσεις ότι έχεις και μεγάλο PLE (http://www.sqlschool.gr/blog/tip-of-the-day-page-life-expectancy-performance-counter-287.aspx)  τοτε θα είναι σχεδόν το περισσότερο χρόνο στην μνήμη

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

Υπάρχει κάποιο πρόβλημα performance το οποίο θέλεις να λύσεις καρφώνοντας τα δεδομένα? Ή μήπως θέλεις να "προφορτώσεις" κάποια δεδομένα ελπίζοντας ότι θα αυξηθεί η ταχύτητα?

Ο SQL Server χρησιμοποιεί όσο το δυνατόν περισσότερη από τη μνήμη του συστήματος για να φορτώσει indexes και δεδομένα, προσπαθώντας να πετύχει την καλύτερη δυνατή απόδοση για όλους τους χρήστες. "Καρφώνοντας" δεδομένα στη μνήμη, αφαιρείς αυτή τη μνήμη από άλλα δεδομένα.

Έτσι κι αλλιώς, το σημαντικότερο είναι να έχεις σωστά indexes στον πίνακα και όχι όλο τον πίνακα στη μνήμη. Μία αναζήτηση σε ένα Index (το οποίο μπορεί να είναι ήδη στη μνήμη) θα είναι γρηγορότερη από ένα table scan, ακόμα και αν αυτό είναι στη μνήμη.

Όσο για τους SSD, τί εννοείς? Δεν ισχύει κάτι διαφορετικό απ' ότι με τους άλλους σκληρούς, απλά είναι γρηγορότεροι. Αν τους έχεις σε RAID θα έχεις καλύτερη ταχύτητα. Αν έχεις σε διαφορετικούς σκληρούς το log από τα data, θα έχεις καλύτερη ταχύτητα. Αν έχεις κάποιο RAID με reduncancy δεν σε απασχολεί να χαλάσει κάποιος SSD. Ουσιαστικά ακριβώς ότι ισχύει και με τους άλλους σκληρούς.

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

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

Να συμπληρώσω στην απάντηση του Παναγιώτη οτι θα πρέπει να ξεκαθαρίσουμε τι εννοούμε με την έννοια "μνήμη". Π.χ. και το pagefile μνήμη θεωρείτε και είναι στην διακριτική ευχέρεια του OS ή του SQL Server να αποφασίσει τι θα μπει και που...

Επίσης κάποιος μπορεί να σου προτείνει άλλες "μαγκιές", όπως:

Αν η βάση σου είναι μικρή και η RAM σου μεγάλη, φτιάχνεις ένα RAM-DISK και φορτώνεις όλη την βάση εκεί (πολύ εξτρεμιστικό)... Εκεί θα μπορούσες να "παίξεις" με το replication σε ένα κλώνο σε πραγματικό δίσκο,... κλπ κλπ... 

Thiseas:

Αν η βάση σου είναι μικρή και η RAM σου μεγάλη, φτιάχνεις ένα RAM-DISK και φορτώνεις όλη την βάση εκεί (πολύ εξτρεμιστικό)... Εκεί θα μπορούσες να "παίξεις" με το replication σε ένα κλώνο σε πραγματικό δίσκο,... κλπ κλπ... 

Στην όντως "εξτρεμιστική" παρέμβασή σου, θα αντιπαράθετα, ότι το RAM disk δεν μπορεί να "ξεχρεώσει" το μόνο χαρακτηριστικό που αναζητά μια τέτοια είδους βάση - στην δυνατότητα να παραμένει το state στο δίσκο... Μια προσέγγιση θα ήταν ένας SSD δίσκος.

Σε αντίθετη περίπτωση, υπάρχουν και οι file based databases, που το access στα δεδομένα είναι γενικώς πιο γρήγορα, μιας και λείπουν αρκετά layers ασφάλειας, και ή χρήση τους με τη χρήση της μνήμης είναι πολύ πιο ελεγχόμενη.

George J.

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Thiseas:

Αν η βάση σου είναι μικρή και η RAM σου μεγάλη, φτιάχνεις ένα RAM-DISK και φορτώνεις όλη την βάση εκεί (πολύ εξτρεμιστικό)... Εκεί θα μπορούσες να "παίξεις" με το replication σε ένα κλώνο σε πραγματικό δίσκο,... κλπ κλπ...  

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

Από τότε που ξεκίνησε η κουβέντα πάντως, ανακοινώθηκαν νέα features του SQL Server 2014 όπως .... η χρήση του SSD ως επέκτασης του buffer pool  

To BPE καταρχήν όπως μέχρι τώρα έχει ανακοινωθεί θα είναι στην enterprise edition του SQL Server και χρήζει περισσότερης προσοχής από πλευράς αρχιτεκτονικής και το τι αυτό περιέχει. Σύντομα θα έχετε post για αυτό.

Θα γυρίζω στο θέμα και θα πω για ακόμα μια φορά ότι τα δεδομένα είναι στην μνήμη έτσι και αλλιώς ιδιαίτερα όταν έχω μια βαση τις οποίας τα δεδομένα μπορούν να χωρέσουν στην μνήμη και με την προυπόθεση ότι δεν υπάρχουν εργασίες που κατεβάζουν τις σελίδες από την μνήμη. Εξάλλου μπορεί κανείς εύκολα με ένα SET STATISTIC IO ON να το μετρήσει.

Μερικά άρθρα για αυτό

• http://www.sqlschool.gr/blog/tip-of-the-day-when-buffer-cache-does-clean-297.aspx
• http://www.sqlschool.gr/blog/tip-of-the-day-πώς-ορίζω-το-μέγεθος-της-buffer-cache-301.aspx
• http://www.sqlschool.gr/blog/tip-of-the-day-monitoring-buffer-cache-size-309.aspx
• http://www.sqlschool.gr/blog/what-is-the-buffer-cache-usage-for-each-database-in-a-sql-server-instance-766.aspx
• http://www.sqlschool.gr/blog/tip-of-the-day-page-life-expectancy-performance-counter-287.aspx
• http://www.sqlschool.gr/blog/tip-of-the-day-2-what-dbcc-dropcleanbuffers-does-298.aspx
• http://www.sqlschool.gr/blog/tip-of-the-day-sys-dm_os_buffer_descriptors-283.aspx
• http://www.sqlschool.gr/blog/tip-of-the-day-what-dbcc-freeproccache-does-303.aspx
• http://www.sqlschool.gr/blog/tip-of-the-day2-what-checkpoint-operation-does-292.aspx
• http://www.sqlschool.gr/blog/tip-of-the-day-pageiolatch-273.aspx
• http://www.sqlschool.gr/blog/tip-of-the-day-what-dbcc-freesystemcache-does-307.aspx
• http://www.sqlschool.gr/blog/tip-of-the-day2-what-checkpoint-operation-does-292.aspx

Απο εκεί και πέρα μιας και μιλήσαμε για τον SQL Server 2014 πάλι στην enterprise έκδοση υπάρχει το In-Memory OLTP και για αυτό θα έχετε σύντομα post

<offtopic>
Κατ' αρχάς θέλω να πω είστε πολύ τυχεροί όσοι έχετε την δυνατότητα, ευχέρεια και κυρίως τον χρόνο, να μπορείτε να δοκιμάζετε κάθε νέο προϊόν της MS και μάλιστα από τα "ακριβά" της!

</offtopic>

Επίσης, topics όπως αυτό πολλές φορές βοηθούν όλους μας με την εποικοδομητική κουβέντα που γίνεται "After Topic" και όχι τόσο In Topic...

Τώρα, για το θέμα της διαχείρισης της μνήμης... δεν έχω άποψη να σας πω γενικά για όλες εκδόσεις και πόσο μάλλον για τον 2014. Σε περίπτωση που μιλάμε όμως για την "πιάτσα", νομίζω οτι αυτό που μετράει είναι το "εν-ενεργεία" περισσότερο από το "εν-δυνάμη". Επίσης, οι περισσότερες Ελληνικές εταιρίες (και όχι μόνο) δεν ξέρω αν έχουν την δυνατότητα και κυρίως την διάθεση να επενδύσουν σε κάποια έκδοση enterprise. Μιλώντας λοιπόν με βάση την δική μου εργασιακή εμπειρία με SQL server Web 2008 ή και 2005 Standard edition έχω δει τα εξής:

• Μπορείς να καθορίσεις δυναμικά το ποσό που θα "διαχειρίζεται" ο SQL Server σου την μνήμη. Ωραία μέχρι εδώ.
  
• Έχει καλό integration με το Win OS και κατά συνέπεια μπορείς να του δώσεις όλη την μνήμη και να τον αφήσεις να... "παίξει" όπως νομίζει.
• Η εναλλαγή των σελίδων και και των data chunks στην μνήμη όμως, δεν μπορεί παρά να βασίζεται σε heuristics ή σε non-deterministic algorithms ή και functions (βλέπεVistualAlloc etc). Κατά συνέπεια:
•  Κανείς δεν μπορεί να μου πει a-priori αν κάποια δεδομένα είναι στον δίσκο ή στην RAM. Kαι ποια RAM (θα ρωτήσει κάποιος) αφού πολλές φορές και η RAM είναι ο δίσκος.
• Σε έναν από τους servers μας στο εξωτερικό με SQL 2008 Web (x64) επάνω και μνήμη 6Gb, το ποσοστό ελεύθερης μνήμης είναι κοντά στο 4% και το ποσοστό απασχόλησης του επεξεργαστή (κατά το 80% της ημέρας) είναι κοντά το 5%. Νομίζω οτι "ο νοών νοείτω". It's not a bug it's a feature ;) - εννοώ οτι ο SQL SERVER διαχειρίζεται πλέον την μνήμη και όχι το OS.
  
• Μπορεί όλος ο πίνακας να "έρθει" στην μνήμη με ένα query, view κλπ, οι προβληματισμοί όμως παραμένουν: Ποιά μνήμη; κλπ.
  
• Με δεδομένο οτι το RDBMS "δουλεύει" στην πραγματικότητα με data-sets και οι πίνακες με τα πραγματικά δεδομένα είναι απλά μια παράπλευρη αλλά αναγκαστική απώλεια χρόνου στον κόσμο των pointers και τον temporary ή μη indexes, το αν κάποιος πίνακας "έρθει" στην μνήμη, μπορεί (από μόνο του) να μην σημαίνει και πολλά πράγματα.
  
• Στην τελική, πράγματι, με ένα μεγάλο pagefile και βασική μνήμη 6Gb μπορεί με το Ram Disk τα πράγματα να γίνουν χειρότερα!
  

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

Σας διαβεβαιώ οτι πάρα πολλές εταιρίες "ζουν" με ένα "ποταπό" SQL Server 2005 Express και με βάση αυτόν, κάποιοι, έχουν καταφέρει αξιοθαύμαστες επιδόσεις ξεπερνώντας πολλές φορές και κάποια limitation του ίδιου του software.

Κι εγώ μπορώ να σε διαβεβαιώσω ότι καμμία εταιρεία δεν ζει με SQL Server 2005 Express. Ανάλογα με τους πελάτες στους οποίους απευθύνεσαι θα δεις διαφορετικά πράγματα. Επειδή βλέπεις μόνο μικρούς πελάτες, δεν σημαίνει ότι όλοι είναι μικροί. Όσο για το "πολύ ακριβά", είδες ποτέ άδειες Oracle? 

Όσο για τη δοκιμή προϊόντων ... αυτό είναι κομμάτι του επαγγέλματος. Μπορείς να αντιδράς στις κατραπακιές που σου έρχονται, ή να διαβάζεις και να ψάχνεις συνέχεια. Όσο μεγαλύτερη εμπειρία έχεις, τόσο καταλαβαίνεις τη σημασία της προληπτικής έρευνας.

Όσο  για το χρόνο ......

Συγγνώμη μεγάλε, αλλά όταν αποκτήσεις κι εσύ 2 και 3 και 4 παιδιά, έλα να μου πεις ότι δεν έχεις χρόνο για διάβασμα.  

H εμπειρία αδελφέ στην πληροφορική είναι μια τσατσάρα που όταν φτάσει στα χέρια σου είσαι πια καραφλός!

Τεσπα... άλλη κουβέντα ανοίγεις - σε λάθος χώρα.

Για όσους πάντως αναρωτιούνται για την ακρίβεια (ή την ΚΛΕΨΙΑ για μερικούς), δεν είναι ανάγκη να κολλήσω στο ΨΕΥΤΟ-δίλημα SQL-Server ή ORACLE.

Ξέρετε υπάρχει και κάτι εντελώς δωρεάν με εξίσου καλό potential...

As Simple As It Could!

και όχι μόνο...

Thiseas:

Ξέρετε υπάρχει και κάτι εντελώς δωρεάν με εξίσου καλό potential...

As Simple As It Could!

και όχι μόνο...

Να μου έλεγες PostgreSQL (αληθινό OSS), θα έλεγα κάτι έχει κάνει παραπάνω από μένα αυτός...

Να μου λες MySQL (λέγε με Oracle, αλλά δεν θέλω να πέσω στο ΨΕΥΤΟ-δίλημα SQL Server / Oracle Database), δεν νομίζω ότι έχει potential σε καμιά περίπτωση!

George J.

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

George J. Capnias:

Να μου έλεγες PostgreSQL (αληθινό OSS), θα έλεγα κάτι έχει κάνει παραπάνω από μένα αυτός...

Να μου λες MySQL (λέγε με Oracle, αλλά δεν θέλω να πέσω στο ΨΕΥΤΟ-δίλημα SQL Server / Oracle Database), δεν νομίζω ότι έχει potential σε καμιά περίπτωση!

George J.

Μα, αυτό που ήθελα να πω ή μάλλον να δείξω στο link αυτό είναι οτι υπάρχουν μεγάλοι, μα πολύ μεγάλοι "πελάτες" (για να μην μείνει η εντύπωση οτι οι "μεγάλοι" πελάτες έχουν μόνο SQL-Server ή Oracle) που διατηρούν database servers που για να τους "αγοράσουν" δεν πλήρωσαν ούτε ένα cent (μην μου πείτε για SLAs, maintenace costs, developing costs κλπ... pls!!).

ΚΑΙ η Postges μου κάνει μια χαρά.
Επίσης μην ξεχνάμε οτι σε βάθος χρόνου (παρελθοντικού), όταν κάποτε χρειαζόταν μια μικρή περουσία για να πάρεις ένα δυνατό DB Server (βλέπε DB2, Ingres αλλά ακόμα και Informix, Sybase) και τώρα για να κάνεις παρόμοια "δουλειά" δεν δίνεις "φράγκο"...ε ναι λογικό για κάποιους αυτό να αποτελεί "potential", και μάλιστα... a big one. 

Ακριβώς με την ίδια λογική (fmho) η εξέλιξη θα συνεχίσει με την ίδα γεωμετρική (μην πω εκθετική) πρόοδο.