Ερωτηση για μέγεθος βάσης SQL και backup

[ΜΑΝΩΛΗΣ1]

Έχουμε μια βάση στην δουλειά η οποία αυτή την στιγμή έχει φτάσει γύρω στα 10 gb (Μιλάω για το αρχείο bak ) το οποίο κάθε βράδυ στέλνεται αυτόματα σε ξεχωριστό δίσκο. Αυτός ο δίσκος φυσικά μετά από λίγες καιρό γεμίζει και αναγκάζομαι και σβήνω παλαιότερες βάσεις που δεν χρειάζονται για να έχουμε χώρο.

Το θέμα είναι ότι κάθε μέρα το backup του bak file καταλαμβάνει 10GB στον δίσκο και περιλαμβάνει ότι είχε πάρει την προηγούμενη μέρα συν τις αλλαγές της τρέχουσας μέρας

Παραθέτω ενα screenshot

Είναι σωστός γενικά αυτός ο τρόπος backup? Η θα έπρεπε να υπάρχει πχ ένα αρχείο το οποίο απλά θα ενημερώνεται χωρίς να χρειάζεται να κρατάει ιστορικό για κάθε μερα?

Παίρνω και σε αλλο δίσκο εκτός server εξτρα backup μια φορά την βδομάδα.

Δεν ξέρω από sql απλά ρωτάω για να δω τι πρέπει να πω στον προγραμματιστή

[Predatorkill]

Μηπως να εκανες incremental /differential backups?
 

https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/create-a-differential-database-backup-sql-server?view=sql-server-ver15

Επεξ/σία 24 Μαΐου 2020 από Predatorkill

[masteripper]

Προσωπική άποψη...ποτέ δεν πολυσυμπάθησα το incremental εκτός και αν δεν γινόταν αλλιως....δηλαδή έχεις 1 backup Πριν Χ χρόνο και παίρνεις Incremental κατά N τακτά διαστήματα...λογικά όλα είναι όμορφα και ωραία...αλλά αν κάτι χτυπήσει στο ενδιάμεσο όλα τα επόμενα μπορεί να είναι σκουπίδια,

Προσωπική άποψη...μην τσιγγουνεύεσαι τους δίσκους οι 2 είναι καλύτεροι απο 1 και οι 3 απο 2 και πάει λέγοντας....προσπάθησε να έχεις 2 εντελώς ανεξάρτητα full backup .

Και φυσικά δεν ξεχνάμε το compression αν..ο χώρος δεν επαρκεί απλώς συμπιέζεις και προχωράς....τα .bak συμπιέζονται καλά.

Επεξ/σία 24 Μαΐου 2020 από masteripper

[Predatorkill]

41 λεπτά πριν, masteripper είπε

..αλλά αν κάτι χτυπήσει στο ενδιάμεσο όλα τα επόμενα μπορεί να είναι σκουπίδια,

Τι διαφορα θα ειχε αμα εκανε full?

 

https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-a-transaction-log-backup-sql-server?view=sql-server-ver15

[ier506]

Καλημέρα,

Πώς παίρνεις το backup? Μέσω agent η μέσω script? Έχεις ενεργοποιήσει το compression?

Επίσης υπάρχει λόγος να κρατάς τόσα αρχεία backup? Μπορείς με ένα script να σβήνεις τα παλαιότερα.

 

[masteripper]

19 ώρες πριν, Predatorkill είπε

Τι διαφορα θα ειχε αμα εκανε full?

https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-a-transaction-log-backup-sql-server?view=sql-server-ver15

Απλώς συνήθως οι πιθανότητες αυξάνουν όταν έχεις , incremental backup να χάσεις ενδιάμεσα.

Backups must be restored in the order in which they were created

Επεξ/σία 25 Μαΐου 2020 από masteripper

[ΜΑΝΩΛΗΣ1]

Το backup νομίζω ότι ειναι μέσω agent. Compression δεν ξέρω αν έχει ενεργοποιηθεί

Κάθε μέρα στις 7 αρχίζει το backup της βάσης. Υπάρχει ένα Raid 5 και ένας έξτρα backup δίσκος 1TB. Αυτή την στιγμή μόνο τα BAK ειναι στα 850GB...

Μια δυο φορές την εβδομάδα παίρνω backup σε εξωτερικό και το ρίχνω και στο cloud (Συμπιεσμένα)

Το θέμα είναι ότι το πρόγραμμα που έχουμε και ο SQL δούλευαν σε Server 2003 (Με SQL 2008 αν θυμάμαι). Έγινε το Migration πριν εναμιση χρόνο με νεο Server (Windows 2016 Και sql 2016)

Πέρα από το backup υπάρχουν και γενικά πολλές καθυστερήσεις. Κάθε βράδυ σχεδόν κάνω restart τον sql η τον server χειροκίνητα αφού κάνω updates γιατί μετά από 2-3 μέρες ο sql έχει φτάσει στα 12,3Gb RAM (εκεί έχει βάλει κόφτη ο προγραμματιστής). 32GB είναι η μνήμη γενικά αλλά υπάρχουν έτσι και αλλιώς πολλές καθυστερήσεις. Το δίκτυο το έχω ελέγξει , δεν έχει θέμα. Ακόμα και μόνος του ο server καθυστερεί όταν τρέξεις το πρόγραμμα από κει.

Δεν έχω ιδέα γενικά από SQL αλλά κάποια στιγμή πρέπει να το αποφασίσω να ασχοληθώ τουλάχιστον με τσεκαρίσματα όσον αφορά καθυστερήσεις , λάθη κλπ κλπ (αν και όποτε έχει τύχει να τρέξω query τρέμει το φυλλοκάρδι μου)

[masteripper]

Κάτι μου λέει ότι έχετε σχεδιαστικά προβλήματα που είναι σαφώς σημαντικά ...ειδικά εκεί με τα restart με ανησυχείς....

Γενικά ο SQL (όπως και κάθε server) δεν είναι για να κάνει restart ....μόνο αν έχει κάποιο σημαντικό Update.

Αν το RAID 5 είναι μέσα στο ίδιο φυσικό μηχάνημα δεν σου παρέχει την προστασία που νομίζεις....και φυσικά 1 άλλο ανησυχητικό είναι ότι "ξεκινάς" backup στις 7 ...πόσο χρόνο παίρνει... (?)

Κανονικά πρέπει να παίρνεις επι καθημερινής βάσης σε τουλάχιστον 1 "εξωτερικό" υποσύστημα και κατα προτίμηση 2....στο κάτα κάτω της γραφής αν μιλάμε για εταιρεία δεν είναι λεφτά να πάρετε 2 dual bay NAS Και να κοιμάστε ήσυχοι... 

[archer100]

Στις 24/5/2020 στις 5:01 ΜΜ, ΜΑΝΩΛΗΣ1 είπε

Είναι σωστός γενικά αυτός ο τρόπος backup? Η θα έπρεπε να υπάρχει πχ ένα αρχείο το οποίο απλά θα ενημερώνεται χωρίς να χρειάζεται να κρατάει ιστορικό για κάθε μερα?

Σωστα τα ερωτηματα σου, αλλα οι απαντησεις εξαρτωνται καθαρα απο το τι θελει η εταιρια σου και τι ειναι σημαντικοτερο. Αν σε ενδιαφερει μονο το τελευταιο backup και τιποτε αλλο, εισαι δηλαδη απολυτα σιγουρος οτι δεν υπαρχει περιπτωση να χρειαστει να ανατρεξεις σε παλαιοτερο backup για να δεις κατι, τοτε μπορεις να κρατας πολυ λιγα backup. Το ενα μονο δε θα το συνιστουσα, ειναι πολυ λιγο. Αν ομως υπαρχει περιπτωση να χρειαστειτε να ανατρεξετε σε παλαιοτερα back up τοτε σιγουρα χρειαζεσαι περισσοτερα. Μια λυση ειναι να "αραιωνεις" τα παλιοτερα back up σου, δηλαδη οσο πιο παλια ειναι, τοσο πιο αραια. Πχ μπορεις να κρατας ολα του τελευταιου μηνα, 15 απο τον προηγουμενο μηνα (ενα παρα ενα), 10 απο τον παρα-προηγουμενο, 5 απο τον αλλον και 1-2 απο καθε μηνα του τελευταιου ετους, κλπ

Απ την αλλη, ενα κρισιμο ερωτημα ειναι τι θα συμβει αν χασετε τα δεδομενα της τρεχουσας ημερας; Αν υπαρχει μεγαλος κινδυνος, δηλαδη χρειαζεστε τα παντα, μεχρι το τελευταιο δεδομενο, τοτε ισως πρεπει να αλλαξετε τον τροπο του back up, πχ να γραψετε ενα script που να αποθηκευει καθε λιγο τα πιο προσφατα δεδομενα. 

Παρεπιπτοντως ποση ωρα κανει να αποθηκευσει ενα backup?

[stefanos90_K]

Οι σκληροί είναι αρκετά φθηνοί, 0,03 €/GB οπότε το ένα αρχείο για σένα κοστίζει ~0.30€ βέβαια δεν είναι και σωστή λύση γιατί κάποια στιγμή πάλι θα γεμίσεις και για λόγους μεταφοράς. 
Πρέπει να τα κρατάς συμπιεσμένα, έστω με zip. Πόσο πιάνει ένα συμπιεσμένο αρχείο? Σίγουρα κάτι πάει πολύ στραβά με την βάση... Όπως είπαν παραπάνω πρέπει, αυτά, να λυθούν.

[ΜΑΝΩΛΗΣ1]

Στις 26/5/2020 στις 11:39 ΠΜ, masteripper είπε

Κάτι μου λέει ότι έχετε σχεδιαστικά προβλήματα που είναι σαφώς σημαντικά ...ειδικά εκεί με τα restart με ανησυχείς....

Γενικά ο SQL (όπως και κάθε server) δεν είναι για να κάνει restart ....μόνο αν έχει κάποιο σημαντικό Update.

Αν το RAID 5 είναι μέσα στο ίδιο φυσικό μηχάνημα δεν σου παρέχει την προστασία που νομίζεις....και φυσικά 1 άλλο ανησυχητικό είναι ότι "ξεκινάς" backup στις 7 ...πόσο χρόνο παίρνει... (?)

Κανονικά πρέπει να παίρνεις επι καθημερινής βάσης σε τουλάχιστον 1 "εξωτερικό" υποσύστημα και κατα προτίμηση 2....στο κάτα κάτω της γραφής αν μιλάμε για εταιρεία δεν είναι λεφτά να πάρετε 2 dual bay NAS Και να κοιμάστε ήσυχοι... 

Επειδή το θέμα συνεχίζει...

Ο προγραμματιστής ανέβασε το όριο της μνήμης στα 24GB. Έτσι και αλλιώς ο Server δεν κάνει κάποια άλλη λειτουργία (ουτε domain controller, ούτε mailserver , μόνο το πρόγραμμα τρέχει)

Την προηγούμενη βδομάδα έκανα restart τον sql 3 φορές γιατί κόλλαγε το πρόγραμμα στους clients (πχ όταν πήγαιναν να ανοίξουν νέα παραγγελία η να μετασχηματίσουν ένα δελτίο)

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

Αυτή την στιγμή η μνημη έχει φτάσει στα 23,5GB και με βλέπω αύριο για restart πάλι... Δεν μου δίνει άλλη λύση

Το backup νομίζω παίρνει κανά μισάωρο με τρία τέταρτα

Όσο για το backup παραλαμβάνω αύριο ένα DS1019+ με 2 δίσκους RED 2TB (256MB Cache) .Mirror για αρχή και στην πορεία θα το πάμε σε Raid6

[masteripper]

17 λεπτά πριν, ΜΑΝΩΛΗΣ1 είπε

Επειδή το θέμα συνεχίζει...

Ο προγραμματιστής ανέβασε το όριο της μνήμης στα 24GB. Έτσι και αλλιώς ο Server δεν κάνει κάποια άλλη λειτουργία (ουτε domain controller, ούτε mailserver , μόνο το πρόγραμμα τρέχει)

Την προηγούμενη βδομάδα έκανα restart τον sql 3 φορές γιατί κόλλαγε το πρόγραμμα στους clients (πχ όταν πήγαιναν να ανοίξουν νέα παραγγελία η να μετασχηματίσουν ένα δελτίο)

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

Αυτή την στιγμή η μνημη έχει φτάσει στα 23,5GB και με βλέπω αύριο για restart πάλι... Δεν μου δίνει άλλη λύση

Το backup νομίζω παίρνει κανά μισάωρο με τρία τέταρτα

Όσο για το backup παραλαμβάνω αύριο ένα DS1019+ με 2 δίσκους RED 2TB (256MB Cache) .Mirror για αρχή και στην πορεία θα το πάμε σε Raid6

Να ελέγξεις αν οι δίσκοι είναι SMR και αν είναι να τους γυρίσεις πίσω....εκτός αν θες να παίρνεις backup με 10Mb/s....απ'οτι διαβάζω είναι τρελλή φόλα.

Τώρα στο τουτέστιν....δεν ξέρω πως να το διατυπώσω.....δεν κάνει επανεκκίνηση ο SQL server...ΔΕΝ....το ότι κάνουμε καμμιά έξτρα σε νεκρούς χρόνους έτσι για να καθαρίσει το σύστημα το κάνουμε.... αλλά κανονικά δεν χρειάζεται.... 

Το ότι έφαγε όλη την μνήμη είναι φυσιολογικό καθώς έτσι είναι σχεδιασμένος : https://dba.stackexchange.com/questions/47431/why-is-sql-server-consuming-more-server-memory

Απλώς πρέπει να αφήνεις μνήμη για το λειτουργικό τουλάχιστον 2gb,καλύτερα 4GB και όλα τα υπόλοιπα στον SQL : https://www.brentozar.com/archive/2011/09/sysadmins-guide-microsoft-sql-server-memory/

το θέμα δεν είναι αν έχει καταναλώσει όλη την μνήμη αλλά αν γίνεται πιο αργός...δεν την σελίδα του Brent Πως θα ελέγξεις τον SQL αν συμπεριφέρεται σωστά

Επεξ/σία 6 Ιουλίου 2020 από masteripper

[ΜΑΝΩΛΗΣ1]

Απο οτι βλέπω για τους δίσκους οι οποίοι ειναι οι WD20EFRX είναι μάλλον CMR...

Για το λειτουργικό έχουν μείνει τώρα 8GB 

Θα μελετήσω και το brent αν και όλα συντελούν στο ότι έχει θέμα η βάση..

[dovecotDev]

Αναφέρεσαι σε ένα λογιστικό πρόγραμμα που αρχίζει από E και τελειώνει σε Soft;

[anon667]

Κάτι ανάμεσα σε Entersoft, Ίλυδα, CSA και Navision μου μυρίζει εμένα.

Η μνήμη που έχει ο σέρβερ είναι τίποτα μπροστά σε αυτά που έχει η βάση (κάπου αναφέρθηκε πως είναι 800+ GB το .bak νομίζω). Φαντάζομαι κάποια tables θα είναι πάρα πολλά GB, και μόνο και μόνο για να κάνει αναζήτηση σε κάποια tables/indices χρειάζεται συνεχής μεταφορά δεδομένων από τον δίσκο στη μνήμη (π.χ. αν ένα table είναι 100GB και για οποιοδήποτε λόγο πρέπει να κάνεις sequential scan για ένα χαζοwhere, και 1GB/s δίσκο->μνήμη μεταφορά να έχεις, θα χρειαστείς πάρα πολύ χρόνο για να ολοκληρωθεί το ερώτημα (που κατά πάσα πιθανότητα lockάρει για όλο αυτό το χρονικό διάστημα το table).

Δες με τον vendor αν υπάρχει η δυνατότητα να μεταφέρετε παλιά δεδομένα σε άλλη database και να παραμείνει αυτή που χρησιμοποιείται τώρα ως παραγωγική με λιγότερα δεδομένα (αν π.χ. έχει data στα tables από 4-5 χρόνια πριν που κατά κύριο λόγο δεν σας ενδιαφέρει η αναζήτηση σε αυτά). Λέγοντας άλλη database εννοώ απλά να φτιαχτεί στον ίδιο SQL Server άλλη μία database που απλά θα μεταφερθούν τα παλιά data εκεί (και θα γίνεται αναζήτηση μία στο τόσο που θα σας ενδιαφέρει κάτι παρελθοντικό).

Επίσης ο Brent έχει κάποια ωραία scriptάκια για health checks σε SQL Server (κάποια κάνουν και προτάσεις για indices κλπ) - https://www.brentozar.com/blitz/ .