Πήγα να πάρω backup το sharepoint με το Windows Server Backup και μου έβγαλα αυτό το event. Μετά είδα ότι το event viewer είναι γεμάτο με αυτό.
The transaction log for database 'SharePoint_Config' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

Το θέμα είναι ότι δε μπορώ να το πάρω backup Οπότε πως θα ελαττώσω το transaction log?

---

Vasilis

αν το ανοίξεις μέσα από τον Enterprise Manager και πας στην βάση και δηλώσεις το log να μπορεί να μεγαλώσει; έτσι ώστε να πάρεις το Backup να πέσει και μετά να το ξαναγυρίσεις στο όριο που ήταν;

---

G.K.
BSc in Business Information Systems,
MSc in Information Technology Management,
MCP

Με 3 τρόπους.

1.

 Δεξί κλίκ στην database και properties.

πηγαίνεις στα files και αλλάζεις το autogrowth σε unrestricted ή μεγαλώνεις το size. Μετά θα σε αφήσει να πάρεις backup

2.  

Δεξί κλίκ στην database και απο τα tasks επιλέγεις backup.

Στο backup_type βάζεις transaction_log και στο κάνει truncate.

3.

USE your_db;
  BACKUP LOG yourdb WITH TRUNCATE_ONLY
  DBCC SHRINKFILE (yourdb_Log, 5)

 

cheers.

---

To V or not to V?
Ignorance is not the problem, the problem is the one that doesn't want to learn.
If you fail to plan, you plan to fail...

Παιδιά όσο κι αν με στεναχωρεί το  BACKUP LOG yourdb WITH TRUNCATE_ONLY και οι άλλες παλιές καλές συνταγές δεν παίζουν στον SQL 2008.

Μου το είπε ένα πουλάκι και μάλιστα ....προσωπικά

Στο παραπάνω link λέει και την λύση νομίζω αν το unrestricted  growth δεν σε παίρνει.

---

Θανάσης Κλαδάκης

Thanasis Kladakis:

Παιδιά όσο κι αν με στεναχωρεί το  BACKUP LOG yourdb WITH TRUNCATE_ONLY και οι άλλες παλιές καλές συνταγές δεν παίζουν στον SQL 2008.

Thanks για το tip. Απλά υπάρχουν περιπτώσεις που το χθεσινό backup σου αρκεί και κατα τη διάρκεια της ημέρας τα log αρχεία μεγαλώνουν υπερβολικά. Ειδικά για εφαρμογές που χρησιμοποιούν replication. Anywayz καλύτερα έτσι.

Με το παρακάτω παίρνεις backup το transaction log και το κάνει και truncate. 

BACKUP LOG [Your_db]
TO  DISK = N'c:\your_db.bak'
WITH NOFORMAT, NOINIT,
 NAME = N'your_db-Transaction Log  Backup',
SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

---

To V or not to V?
Ignorance is not the problem, the problem is the one that doesn't want to learn.
If you fail to plan, you plan to fail...

Θα ήθελα να επισημάνω μερικά πράγματα στην backup statemement που μας έδωσε ο φίλος Απόστολος.

Καταρχήν να διευκρινίσουμε τη σημαίνει truncate στον SQL Server.
Ας ξεκινήσουμε με την βασική αρχή του.
Σε καμία περίπτωση δεν σημαίνει ότι ο χώρος που έχει δεσμευθεί μέχρι εκείνη την στιγμή στο δίσκο από αυτό θα μειωθεί.
Απλά γίνεται εσωτερικά ώστε να επαναχρησιμοποιηθεί ο χώρος που καθαρίστηκε.
Αν θέλεις να δώσεις τον χώρο αυτό πίσω στο λειτουργικό θα πρέπει αν κάνεις shrink το αρχείο (DBCC SHRINKFILE).

Οι διακόπτες στην εντολή δεν έχουν καμία σημασία στο truncate και αυτό γιατί αν είσαι σε FULL RECOVERY model, κάθε φορά που κάνεις transaction log backup αυτό γίνεται truncate.
Βέβαια υπάρχουν και περιπτώσεις όπου μπορεί αυτό να αργήσει να γίνει http://msdn.microsoft.com/en-us/library/ms345414.aspx.

Εάν είσαι σε SIMPLE RECOVERY model έτσι και αλλιώς γίνεται truncate κάθε φορά που γίνεται checkpoint. Αλλά σε αυτή την περίπτωση δεν μπορείς να πάρεις transaction log backup.

Οι διακόπτες που αναφέρονται κάνουν απλά τα εξής:

NOFORMAT
Είναι και default και δεν χρειάζεται να το βάζεις και το μόνο που κάνει είναι να μην σβήνει τους headers που υπάρχουν στον backup device.

NOINIT
Αυτό που κάνει είναι να μην σβήνει τα άλλα backups τα οποία υπάρχουν σε αυτό το backup device. (το default είναι INIT).

NAME
Δεν είναι τίποτα άλλο από μια περιγραφή την οποία μπορείς να βάλεις για να έχεις την δυνατότητα να διαβάζεις καλύτερα τα περιεχόμενα του backup device.

SKIP
Δεν ελέγχει το backup set expiration date, το οποίο μερικοί βάζουμε για να προστατεύσουμε τον εαυτό μας από το να κάνουμε overwrite προηγούμενα backup sets.

NOREWIND
Αυτό είναι μόνο για την περίπτωση που παίρνεις backup σε tape και δεν θέλεις μετά την ολοκλήρωση να κάνει rewind την ταινία γιατί θέλεις να αφήσεις την ταινία μέσα στο streamer ώστε να συνεχίσεις από εκεί και πέρα στα επόμενα backup.

NOUNLOAD.
Πάλι για την περίπτωση που έχεις streamer. Το μόνο μου κάνει είναι να μην κάνει eject την ταινία.

STAT
Το μόνο που κάνει είναι βγάζει ένα μήνυμα κάθε φορά που έχει συμπληρωθεί το ποσοστό που έχεις αναφέρεις σε αυτό στο παράδειγμα σου 10%

---

Antonios Chatzipavlis

και επειδή αυτό το post μου έδωσε την αφορμή να γράψω ένα blog post γιατι με το transaction log backup γινεται truncate το log file, το βάζω και εδω ώστε να υπάρχει η συνέχεια και ελπίζω η λύση σε αυτό που σας βασανίζει

---

Antonios Chatzipavlis

Τελικά άλλαξα το autogrowth σε unrestricted και σταμάτησαν τα errors και παίρνω όλο το δίσκο backup με το Windows Backup Service.
Τα transaction logs πρέπει να μένουν μικρά ή δε μας πειράζει το μέγεθος εκτός ότι καταναλώνουν χώρο. Η συγκεκριμένη βάση είναι 8mb και το transaction log είναι 2,3gb. Ακόμα κ shrink file που το έκανα δε μίκρυνε.

Αν πάρω με το Windows Backup Service Full Backup και όχι copy που πήρα τώρα, τα transaction logs θα μικρύνουν?

Τι μου προτείνετε να κάνω. Θυμίζω ότι πρόκειται για βάσεις του Sharepoint Server 2007

Ευχαριστώ

---

Vasilis

λογικά θα έχει γίνει truncate τώρα που πήρες transaction log backup

τρέξε την DBCC SQLPERF(LOGSPACE)  και θα δεις το log space used θα πρέπει να είναι μικρό.

για να αποδεσμεύσεις το χώρο που το log καταλαμβάνει στον δίσκο τρέξε την DBCC SHRINKFILE (p1,p2)

p1= λογικό όνομα του Log,

p2 = επιθυμητό μέγεθος που θέλεις να είναι στο δίσκο φυσικά οχι μικρότερο από το μέγεθος που καταλαμβάνουν τα δεδομένα του

 

---

Antonios Chatzipavlis

ops δεν είδα καλα τι έγραψες!

Μόνο αν πάρεις SQL Server Transaction Log Backup θα γίνει truncate το log.

Ότι άλλο backup και να πάρεις δεν θα γίνει τίποτα

Τώρα όσο για το αν μας πειράζει το μεγάλο Log δεν μας πειράζει ειδικά σε βάσεις που έχουμε μεγάλο όγκο από transactions ή είναι βάσεις στις οποίες γίνεται μαζική εισαγωγή δεδομένων.

Αυτό που σας βασανίζει είναι μόνο ο χώρος που έχει δεσμευτεί στον δίσκο. Για τον SQL Server είναι το ίδιο και το αυτό, σε γενικές γράμμες.

Πάρε transaction log backup και ακολούθησε τις οδηγίες που έχω ήδη γράψει

---

Antonios Chatzipavlis

Είναι λίγο ρίσκο να το έχεις σε unrestricted mode το transaction log.
Σε κάθε περίπτωση, πιστεύω ότι ένα log backup σε τακτά χρονικά διαστήματα με κάποιο maintenance plan θα κρατήσει το χώρο σε ικανοποιητικό επίπεδο.

---

CKotsis
My Blog: SQL & Sharepoint tips and how to's

MCTS SQL Server 2008

ckotsidimos:

Είναι λίγο ρίσκο να το έχεις σε unrestricted mode το transaction log.

Καλημέρα

Δεν βλέπω κάποιο ρίσκο στο να έχεις unrestricted το transaction log, εκτός από το γεγονός ότι μπορεί να σου πάρει όλο το δίσκο. Αλλά αυτό δεν πρόκειτε ποτέ να γίνει αν έχεις μια σωστή πολιτική που ξεκινάει από το σωστό capacity plan και φτάνει μέχρι την πολιτική να παίρνεις transaction log backup.

Υπάρχει ένας κανόνας που βέβαια σε κάποιες περιπτώσεις μπορεί να παραβιαστεί. Ο κανόνας αυτός λέει ότι όταν φτίαχνουμε μια βάση το transaction log θα πρέπει να έχει μέγεθος τέτοιο που να είναι ίσο με το 30% του μεγέθους των data files. Βέβαια όπως προείπα αυτό είναι κάτι το οποίο αλλάζει ειδικά στις περιπτώσεις που έχεις heavily transactional databases ή βάσεις που έχουν blob fields και έχεις πει ότι θέλεις να είναι logged τα actions (insert, update, delete) που κάνεις σε αυτά.

Αυτό που θέλω να γίνει όμως ΑΠΟΛΥΤΑ κατανοητό είναι ότι το transaction log είναι το ΣΥΜΑΝΤΙΚΟΤΕΡΟ συστατικό μιας βάσης στον SQL Server.

Έτσι λοιπόν εφόσον όλα τα παραπάνω τα έχεις κάνει καλά δεν θα αντιμετωπίσεις ποτέ πρόβλημα με το μέγεθος τους log file. Αν για παράδειγμα φτίαξεις μια βάση που έχεις προϋπολογίσει ότι το μέγεθος των data για τους πρώτους 6 μήνες πχ θα είναι 100ΜΒ και ο ημερήσιος αριθμός των transactions είναι σε λογικές γραμμές, αν ακολουθήσεις τον κανόνα του 30% και σε συνδιασμό μιας πολιτικής να παίρνεις transaction log backup σε τακτά χρονικά διαστήματα κατά την διάρκεια της ημέρας δεν θα δεις σχεδόν πότε να μεγαλώνει το μέγεθος του transaction log.

Μην σας φοβίζει το να παίρνεται transaction log backup σε τακτά χρονικά διαστήματα μέσα στην ημέρα. Το overhead την ώρα που θα γίνεται κάτι τέτοιο είναι πραγματικά ασήμαντο, άσε δε που αν για οποιαδήποτε λόγο έχεις πρόβλημα με την βάση σου μέσα στην ημέρα μπορείς να γυρίσεις ακόμα και στο σημείο που έχεις το πρόβλημα και να μην χάσεις τα δεδομένα σου που έχεις βάλει, αλλάξει από το τελευταίο full backup.

Εάν πάλι δεν θέλεις να κάνεις κάτι τέτοιο και το ζητούμενο σου είναι να έχεις μόνο ένα ημερήσιο full backup και δεν σε ενδιαφέρει να γυρίζεις στο σημείο της πτώσης της βάσης όταν και όποτε αυτό συμβεί, τότε δεν βλέπω το λόγο να είσαι σε FULL RECOVERY model. Δώσε ένα σωστό (πάντα κάτω από την εκτίμηση με βάση το capacity plan που θα έχεις κάνει) μέγεθος στο log file μην το κάνεις autogrowth, και άσε τον SQL Server να κάνει την δουλειά του. Εάν θα δείτε το video από post μου θα δείτε ότι ακόμα και στην περίπτωση που είμαι σε full recovery model και δεν έχω πάρει ακόμα full backup ο SQL Server έχει την βάση σε μια ψευδοSimple recovery model κατάσταση και θα δείτε ότι μόλις πάει να ξεπεραστεί το μέγεθος του transaction log αυτόματα κάνει truncate. Οπότε όλα είναι μέλι γάλα.

Τώρα σε βάσεις όπως τους Sharepoint το full recovery model το θεωρώ δεδομένο. Απλά δεν κάθομαι στο ένα και μοναδικό ημερήσιο full backup της βάσης. Φροντίζω να παίρνω και transaction log backup σε τακτά χρονικά διαστήματα πχ ανά 2 ώρες.

Δεν νομίζω ότι είναι δα τόσο φοβερό να υλοποιήσεις μια πολιτική μέσα στην ημέρα που να κάνει σε τακτά χρονικά διαστήματα transaction log backup.

Αυτή είναι η άποψη μου που βγαίνει μέσα από την εμπειρία μου με τον SQL Server με τον οποίο ασχολούμαι από το 1996 (SQL Server 6.0).

Είμαι στην διάθεση σας για παρατηρήσεις, διευκρινήσεις και ότι άλλο θέλετε για το θέμα αυτό.

Φιλικά

---

Antonios Chatzipavlis

Η σκέψη μου είναι ότι αν δεν υπάρχει dbadmin ή κάποιος επιφορτισμένος με το ρόλο αυτό το μέγεθος μπορεί να ξεφύγει. Αναφέρω το συγκεκριμένο μιας και ήταν κάτι με το οποίο την πάτησα παλιότερα και όπως λέει ο σοφός λαός "Όποιος καεί απ' το χυλό ...."

Οπότε είμαι παθόν και μαθών!

---

CKotsis
My Blog: SQL & Sharepoint tips and how to's

MCTS SQL Server 2008

Καλημέρα και ευχαριστώ για τη βοήθεια.

Μετά από μία έρευνα μου έκανα από τις 13 βάσεις που έχω (project server, sharepoint, wss) οι περισσότερες είναι σε Full Recovery και λίγες σε Simple.

Δε γνωρίζω αν αυτά έγιναν από default ή αν τα πείραξε κάποιος.

Το transaction log το έκανα unrestricted και αμέσως έγινε από μόνο του restricted "By 10 percent, restricted growth to 2097152 MB "

Από εκείνη τη στιγμή κατάφερα και πήρα και όλο το Server image backup με το backup των Windows 2008.
Πήρα και με maintenace plan ένα backup όλες τις user DBs με Full Backup.

2 ερωτήσεις τώρα:

1ον θέλω να τη κάνω schedule τη διαδικασία. Θα κάνω schedule το maintenace plan να παίρνει backup κάθε βράδυ. Να φανταστώ differencial ε? Ένα full τη βδομάδα και τα υπόλοιπα differencial σωστά? Το append είναι καλή επιλογή ή την αποφέυγουμε?

2ον Με το full backup δεν είμαι καλυμμένος σε περίπτωση που συμβεί κάτι? Θέλουμε και transaction log backup? Να πάρω transaction log backup για να μικρύνει το μέγεθος του transaction log και μετά να του θέσω όριο? Αν γεμίσει όμως πάλι δε θα βγάζει σφάλμα?

Ευχαριστώ

---

Vasilis

Και για τις 2 ερωτήσεις η απάντηση δυστυχώς είναι πάλι με ερωτήσεις. Αυτά που ρωτάς έχουν να κάνουν με την πολυτιμότητα των δεδομένων και σε ποιά φάση θέλουμε να κάνουμε restore.

Με ένα χθεσινοβραδυνό backup και χάνοντας της αλλαγές της ημέρας είμαστε καλυμένοι? Πρέπει να μπορούμε να γυρίσουμε τη βάση σε κάποιο σημείο της ημέρας πρωτού κάποιος χρήστης ανατινάξει την βάση? Αυτά είναι τα 2 βασικά ερωτήματα με τα οποία θα φτιάξουμε ένα maintenance plan. Α και επίσης πόσο γρήγορα πρέπει να έχουμε τα δεδομένα πίσω.

Με ένα full την εβδομάδα και τα υπόλοιπα dif αν γίνει καταστροφή την παρασκευή, ξεκινάς ένα ένα τα backup απο το full και μετά τα diferrencial. Αν έχεις χθεσινό full με τη μία ρίχνεις τα trans logs και καθάρισες. Η επιλογή append βάζει μέσα στο ίδιο αρχείο backup το νέο backup. Αν παίρνεις full backups κάθε μέρα τότε το αρχείο μέσα έχει τα καθημερινά full backups. Όταν πας να κάνεις restore μπορείς να επιλέξεις πιας ημερομηνίας το backup θα κάνεις restore. Αυτό είναι λογικό ότι το μέγεθος του αρχείου αυξάνει σχεδόν μαθηματικά και αν οι βάση έχει πολλά transactions την ημέρα μπορεί και γεωμετρικά. Μεγάλη προσοχή στο χώρο.

To transaction log το χρειάζεσαι για να μπορέσεις να γυρίσεις σε κάποιο σημείο μεταξύ των backups. Ένα full χθεσινό backup και ένα trans log backup πχ στης 13:00 η ώρα σου δίνει 2 δυνατότητες. Πρώτον να μπορέσεις να φέρεις τη βάση σου σε κάποιο state μεταξύ του backup και τη μία το μεσημέρι. Αν χτυπήσει η βάση σου στις 5 το απόγευμα θα χάσεις της αλλαγές απο τη μία και μετά.

ΠΡΟΣΟΧΗ. Όταν παθαίνει κάτι η database ή ο server . ΠΡΩΤΑ παίρνουμε backup τα φυσικά αρχεία και μετά κάνουμε ότι είναι να κάνουμε. Αυτό είναι ερώτηση απο τις εξετάσεις του SBS2003

---

To V or not to V?
Ignorance is not the problem, the problem is the one that doesn't want to learn.
If you fail to plan, you plan to fail...