Συμβουλή συστήματοςΑυτό το άρθρο ισχύει για διαφορετικό λειτουργικό σύστημα από αυτό που χρησιμοποιείτε. Το περιεχόμενο του άρθρου που ενδέχεται να μην σας αφορά έχει απενεργοποιηθεί.
Υπάρχουν ορισμένα συνήθη αίτια, γιατί ένα αρχείο καταγραφής συναλλαγών ενδέχεται να μην συρρίκνωση όταν χρησιμοποιείτε την εντολή SHRINKDATABASE DBCC ή SHRINKFILE DBCC. Τα ηλεκτρονικά βιβλία SQL Server Books Online θέματα "DBCC SHRINKFILE" και "DBCC SHRINKDATABASE" παρέχουν λεπτομερείς πληροφορίες, αλλά ακολουθεί μια σύντομη Περίληψη.
Στον Microsoft SQL Server 7.0, οι εντολές SHRINKFILE και SHRINKDATABASE, ορίστε ένα μέγεθος προορισμού για τη συρρίκνωση. Κάθε αρχείο καταγραφής είναι σημαδεμένο με αυτές τις εντολές, αλλά στην πραγματικότητα είναι ένα αντίγραφο ασφαλείας του αρχείου καταγραφής ή την περικοπή του αρχείου καταγραφής που προσπαθεί να συρρικνώσετε τα αρχεία. Επομένως, μετά χρησιμοποιήστε το SHRINKFILE ή SHRINKDATABASE εντολή πρέπει να επίσης εκδώσετε μια εντολή που περικόπτει το αρχείο καταγραφής πριν να υπάρχει οποιαδήποτε πιθανότητα αυτό θα συρρικνωθεί.
Που δεν μπορεί να συρρικνωθεί ένα αρχείο καταγραφής σε μέγεθος μικρότερο από το τι επιτρέπεται από τα εξής κριτήρια:
Για να συρρικνώσετε έναν μικρότερο από το αρχικό της μέγεθος αρχείου καταγραφής που πρέπει να συρρικνώσετε μεμονωμένα αρχεία με SHRINKFILE DBCC. Δεν μπορείτε να χρησιμοποιήσετε SHRINKDATABASE DBCC να συρρικνώσετε ένα αρχείο καταγραφής σε μέγεθος μικρότερο από το μέγεθος του αρχικού ή συγκεκριμένα αναγνωρισμένα. Το αρχικό μέγεθος ορίζεται ως το μέγεθος του αρχείου καταγραφής οφείλεται σε CREATE DATABASE καθώς και τυχόν ρητή εντολές ALTER DATABASE. Το αρχικό μέγεθος δεν περιλαμβάνει αυτόματη ανάπτυξη του αρχείου καταγραφής.
Το φυσικό αρχείο καταγραφής δεν μπορεί να είναι μικρότερο από το μέγεθος του χώρου που χρησιμοποιείται αυτήν τη στιγμή μέσα στο αρχείο καταγραφής. Μπορείτε να χρησιμοποιήσετε την εντολή DBCC SQLPERF (LOGSPACE) για την εποπτεία του χώρου που χρησιμοποιείται.
Το τρέχον μέγεθος του αρχείου καταγραφής της βάσης δεδομένων του μοντέλου είναι το ελάχιστο μέγεθος για οποιαδήποτε βάση δεδομένων καταγραφής σε αυτόν το διακομιστή. Από προεπιλογή, το αρχείο καταγραφής της βάσης δεδομένων του μοντέλου είναι λιγότερο από 1 MB.
Επειδή ένα αρχείο καταγραφής μπορεί να συρρικνωθεί μόνο σε ένα εικονικό αρχείο καταγραφής όριο αρχείου (VLF), δεν μπορείτε να συρρικνώσετε ένα αρχείο καταγραφής σε μέγεθος μικρότερο από ένα VLF, ακόμα και αν το χώρο που δεν χρησιμοποιείται. Παρομοίως, αν χρησιμοποιείται ένα μέρος μιας VLF δεν μπορεί να συρρικνωθεί κάποιο χώρο στο συγκεκριμένο VLF. Για περισσότερες πληροφορίες, ανατρέξτε στα θέματα "Εικονικού αρχεία καταγραφής" και "Transaction Log φυσικής αρχιτεκτονικής" στα ηλεκτρονικά βιβλία SQL Server Books Online.
Το αρχείο καταγραφής συναλλαγών είναι ένα αρχείο καταγραφής "αναδίπλωση γύρω". Αυτό σημαίνει ότι σε κάθε δεδομένη στιγμή ενδέχεται να υπάρχουν VLFs με χώρο "Ελεύθερη" ή "με δυνατότητα επανάληψης χρήσης" κατά την αρχή, μέση, ή/και το τέλος του αρχείου καταγραφής. Για να συμπτύξετε το αρχείο καταγραφής πρέπει να είναι "Ελεύθερη" χώρου στο τέλος του αρχείου καταγραφής, όχι μόνο ελεύθερο χώρο σε οποιοδήποτε σημείο του αρχείου καταγραφής. Επίσης, μπορείτε να συρρικνώσετε ολόκληρη VLFs. Για να συμπτύξετε τη συναλλαγή καταγραφής του VLFs στο τέλος του αρχείου καταγραφής πρέπει να είναι ανενεργά και έχει περικοπεί. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα "Περικοπή της καταγραφής κινήσεων" στα ηλεκτρονικά βιβλία SQL Server Books Online.
Here are a few things to keep in mind:
Always perform system database and user database backups before and after you make changes that affect the system. DBCC SHRINKFILE and DBCC SHRINKDATABASE are not logged operations, and running them invalidates further transaction log backups. You must make a full database backup after you run either the DBCC SHRINKFILE or the DBCC SHRINKDATABASE commands.
Make sure that there are no backups scheduled to occur during the time the shrink is supposed to occur.
Make sure that there are no old, long-running, or unreplicated transactions. To do so, use code similar to:
DBCC OPENTRAN (database_name)
Run the DBCC SHRINKFILE or DBCC SHRINKDATABASE command to mark a shrinkpoint. DBCC SHRINKFILE and DBCC SHRINKDATABASE permissions default to members of the sysadmin fixed server role or thedb_ownerfixed database role, and are not transferable. For information about the differences between these commands, refer to the following topics in SQL Books Online (note the different parameters):
Create some dummy transactions to make the log wrap around and then issue a BACKUP command to truncate the log. The BACKUP statement is what actually attempts to shrink the log to the marked target size.
Here is a sample of how to create a dummy transactions that wraps the log for a single logical log file and causes it to truncate, allowing for shrinkage. Modify the sample as needed for your environment.
SET NOCOUNT ON
DECLARE @LogicalFileName sysname,
@MaxMinutes INT,
@NewSize INT
-- *** MAKE SURE TO CHANGE THE NEXT 4 LINES WITH YOUR CRITERIA. ***
USE [Test DB] -- This is the name of the database
-- for which the log will be shrunk.
SELECT @LogicalFileName = 'Test DB Log', -- Use sp_helpfile to
-- identify the logical file
-- name that you want to shrink.
@MaxMinutes = 10, -- Limit on time allowed to wrap log.
@NewSize = 10 -- in MB
-- Setup / initialize
DECLARE @OriginalSize int
SELECT @OriginalSize = size -- in 8K pages
FROM sysfiles
WHERE name = @LogicalFileName
SELECT 'Original Size of ' + db_name() + ' LOG is ' +
CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName
CREATE TABLE DummyTrans
(DummyColumn char (8000) not null)
-- Wrap log and truncate it.
DECLARE @Counter INT,
@StartTime DATETIME,
@TruncLog VARCHAR(255)
SELECT @StartTime = GETDATE(),
@TruncLog = 'BACKUP LOG ['+ db_name() + '] WITH TRUNCATE_ONLY'
-- Try an initial shrink.
DBCC SHRINKFILE (@LogicalFileName, @NewSize)
EXEC (@TruncLog)
-- Wrap the log if necessary.
WHILE @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired
AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName) -- the log has not shrunk
AND (@OriginalSize * 8 /1024) > @NewSize -- The value passed in for new size is smaller than the current size.
BEGIN -- Outer loop.
SELECT @Counter = 0
WHILE ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))
BEGIN -- update
INSERT DummyTrans VALUES ('Fill Log') -- Because it is a char field it inserts 8000 bytes.
DELETE DummyTrans
SELECT @Counter = @Counter + 1
END -- update
EXEC (@TruncLog) -- See if a trunc of the log shrinks it.
END -- outer loop
SELECT 'Final Size of ' + db_name() + ' LOG is ' +
CONVERT(VARCHAR(30),size) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName
DROP TABLE DummyTrans
PRINT '*** Perform a full database backup ***'
SET NOCOUNT OFF
Check to see if the log has shrunk from its original size.Repeat the preceding steps if necessary. If the log is not shrinking, re-check the summary at the top of the article to see if you are encountering any of the common issues with shrinking the log.
After the log shrinks:
Perform a full database backup of the master database.
Perform a full database backup of the user database. This is necessary because the SHRINK command is not logged and invalidates future transaction log backups unless a full database backup is completed.
To determine why the log is growing so big in the first place, you can check for open transactions, long running transactions, unreplicated transactions, or transactions that touch a lot of data.
Για πρόσθετες πληροφορίες, κάντε κλικ στους αριθμούς των άρθρων παρακάτω, για να προβάλετε τα άρθρα της Γνωσιακής Βάσης της Microsoft (Knowledge Base):
110139
(http://support.microsoft.com/kb/110139/EN-US/
)
Το αρχείο INF: Προκαλεί την εμφάνιση του αρχείου καταγραφής συναλλαγών SQL Συμπλήρωση προς τα επάνω
62866
(http://support.microsoft.com/kb/62866/EN-US/
)
INFO: Reasons Why SQL Transaction Log Is Not Being Truncated
66057
(http://support.microsoft.com/kb/66057/EN-US/
)
PRB: Running Out of Log Space When Running Large Bulk Loads
ΣΗΜΑΝΤΙΚΟ: Αυτό το άρθρο είναι προϊόν λογισμικού μηχανικής μετάφρασης της Microsoft και όχι ανθρώπινης μετάφρασης. Η Microsoft σάς προσφέρει άρθρα που είναι προϊόντα ανθρώπινης αλλά και μηχανικής μετάφρασης έτσι ώστε να έχετε πρόσβαση σε όλα τα άρθρα της Γνωσιακής Βάσης μας στη δική σας γλώσσα. Ωστόσο, ένα άρθρο που έχει προκύψει από μηχανική μετάφραση δεν είναι πάντα άριστης ποιότητας. Ενδέχεται να περιέχει λεξιλογικά, συντακτικά ή γραμματικά λάθη, όπως ακριβώς τα λάθη που θα έκανε ένας μη φυσικός ομιλητής επιχειρώντας να μιλήσει τη γλώσσα σας. Η Microsoft δεν φέρει καμία ευθύνη για τυχόν ανακρίβειες, σφάλματα ή ζημίες που προκύψουν λόγω τυχόν παρερμηνειών στη μετάφραση του περιεχομένου ή χρήσης του από τους πελάτες της. Επίσης, η Microsoft πραγματοποιεί συχνά ενημερώσεις στο λογισμικό μηχανικής μετάφρασης.
Η αγγλική έκδοση αυτού του άρθρου είναι η ακόλουθη:256650
(http://support.microsoft.com/kb/256650/en-us/
)
Πόση προσπάθεια καταβάλλατε για να χρησιμοποιήσετε αυτό το άρθρο;
Πολύ λίγη
Λίγη
Μέτρια
Μεγάλη
Πολύ μεγάλη
Πείτε μας για ποιον λόγο και με ποιον τρόπο θα μπορούσαμε να βελτιώσουμε αυτές τις πληροφορίες
Σας ευχαριστούμε! Τα σχόλιά σας θα μας βοηθήσουν να βελτιώσουμε το περιεχόμενο υποστήριξης. Για περισσότερες επιλογές βοήθειας, επισκεφτείτε την αρχική σελίδα της Βοήθειας και υποστήριξης.
Windows Live
Facebook
Twitter
Linkedin
Digg it
Yahoo
Delicious
StumbleUpon
Yammer
Reddit
Technorati
FriendFeed
Email
Μηχανικά μεταφρασμένο
Επιστροφή στην αρχή
