Saya bukan ahli SQL, dan saya teringat fakta setiap kali saya perlu melakukan sesuatu di luar dasar-dasar. Saya memiliki database pengujian yang ukurannya tidak besar, tetapi log transaksi pasti. Bagaimana cara menghapus log transaksi?

Membuat file log lebih kecil harus benar-benar dicadangkan untuk skenario di mana ia mengalami pertumbuhan tak terduga yang Anda tidak harapkan terjadi lagi. Jika file log akan tumbuh dengan ukuran yang sama lagi, tidak terlalu banyak dilakukan dengan menyusutkannya sementara. Sekarang, tergantung pada tujuan pemulihan database Anda, ini adalah tindakan yang harus Anda ambil.

Pertama, ambil cadangan penuh

Jangan pernah melakukan perubahan apa pun pada basis data Anda tanpa memastikan Anda dapat memulihkannya jika terjadi kesalahan.

Jika Anda peduli tentang pemulihan point-in-time

(Dan dengan pemulihan point-in-time, maksud saya Anda peduli untuk dapat memulihkan apa pun selain cadangan penuh atau diferensial.)

Mungkin basis data Anda dalam FULLmode pemulihan. Jika tidak, maka pastikan:

ALTER DATABASE testdb SET RECOVERY FULL;

Bahkan jika Anda mengambil cadangan penuh reguler, file log akan tumbuh dan berkembang sampai Anda melakukan backup log - ini adalah untuk perlindungan Anda, tidak perlu menggerogoti ruang disk Anda. Anda harus melakukan pencadangan log ini cukup sering, sesuai dengan tujuan pemulihan Anda. Misalnya, jika Anda memiliki aturan bisnis yang menyatakan Anda mampu kehilangan tidak lebih dari 15 menit data jika terjadi bencana, Anda harus memiliki pekerjaan yang membuat cadangan log setiap 15 menit. Berikut ini adalah skrip yang akan menghasilkan nama file timestamped berdasarkan waktu saat ini (tetapi Anda juga dapat melakukan ini dengan paket pemeliharaan dll., Jangan pilih opsi menyusut apa pun dalam paket pemeliharaan, itu mengerikan).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Catatan yang \\backup_share\harus pada mesin yang berbeda yang mewakili perangkat penyimpanan dasar yang berbeda. Membackup ini ke mesin yang sama (atau ke mesin lain yang menggunakan disk dasar yang sama, atau VM berbeda yang ada di host fisik yang sama) tidak benar-benar membantu Anda, karena jika mesin meledak, Anda telah kehilangan database Anda dan cadangannya. Bergantung pada infrastruktur jaringan Anda, mungkin lebih masuk akal untuk membuat cadangan secara lokal dan kemudian mentransfernya ke lokasi lain di belakang layar; dalam kedua kasus, Anda ingin mengeluarkannya dari mesin basis data utama secepat mungkin.

Sekarang, setelah Anda memiliki cadangan log reguler berjalan, itu harus masuk akal untuk mengecilkan file log menjadi sesuatu yang lebih masuk akal daripada apa pun yang dihancurkan hingga sekarang. Ini tidak berarti berjalan SHRINKFILEberulang-ulang sampai file log adalah 1 MB - bahkan jika Anda sering mencadangkan log, itu masih perlu mengakomodasi jumlah dari setiap transaksi bersamaan yang dapat terjadi. Kejadian autogrow file log itu mahal, karena SQL Server harus menghapus file (tidak seperti file data ketika inisialisasi file instan diaktifkan), dan transaksi pengguna harus menunggu saat ini terjadi. Anda ingin melakukan rutinitas susut-susut-susut sesedikit mungkin, dan Anda tentu tidak ingin membuat pengguna Anda membayar untuk itu.

Perhatikan bahwa Anda mungkin perlu mencadangkan log dua kali sebelum psikiater dimungkinkan (terima kasih Robert).

Jadi, Anda perlu membuat ukuran praktis untuk file log Anda. Tidak ada orang di sini yang dapat memberi tahu Anda apa itu tanpa mengetahui lebih banyak tentang sistem Anda, tetapi jika Anda telah sering menyusutkan file log dan telah tumbuh lagi, tanda air yang baik mungkin 10-50% lebih tinggi daripada yang terbesar. . Katakanlah itu mencapai 200 MB, dan Anda ingin acara autogrowth berikutnya menjadi 50 MB, maka Anda dapat menyesuaikan ukuran file log dengan cara ini:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Perhatikan bahwa jika file log saat ini> 200 MB, Anda mungkin perlu menjalankan ini terlebih dahulu:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Jika Anda tidak peduli dengan pemulihan point-in-time

Jika ini adalah database uji, dan Anda tidak peduli tentang pemulihan titik-waktu, maka Anda harus memastikan bahwa database Anda dalam SIMPLEmode pemulihan.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Menempatkan database dalam SIMPLEmode pemulihan akan memastikan bahwa SQL Server menggunakan kembali sebagian dari file log (pada dasarnya menghapus transaksi tidak aktif) alih-alih tumbuh untuk menyimpan catatan semua transaksi (seperti halnya FULLpemulihan hingga Anda membuat cadangan log). CHECKPOINTPeristiwa akan membantu mengendalikan log dan memastikan bahwa itu tidak perlu tumbuh kecuali jika Anda menghasilkan banyak aktivitas t-log antara CHECKPOINTs.

Selanjutnya, Anda harus memastikan sepenuhnya bahwa pertumbuhan log ini benar-benar disebabkan oleh peristiwa abnormal (misalnya, pembersihan musim semi tahunan atau membangun kembali indeks terbesar Anda), dan bukan karena penggunaan normal setiap hari. Jika Anda mengecilkan file log ke ukuran yang sangat kecil, dan SQL Server hanya perlu menumbuhkannya lagi untuk mengakomodasi aktivitas normal Anda, apa yang Anda peroleh? Apakah Anda dapat menggunakan ruang disk yang Anda dibebaskan hanya sementara? Jika Anda memerlukan perbaikan segera, maka Anda dapat menjalankan yang berikut:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO

Jika tidak, atur ukuran dan tingkat pertumbuhan yang sesuai. Seperti contoh dalam kasus pemulihan point-in-time, Anda dapat menggunakan kode dan logika yang sama untuk menentukan ukuran file apa yang sesuai dan mengatur parameter autogrowth yang masuk akal.

Beberapa hal yang tidak ingin Anda lakukan

• Cadangkan log dengan TRUNCATE_ONLYopsi laluSHRINKFILE . Pertama, TRUNCATE_ONLYopsi ini sudah usang dan tidak lagi tersedia di versi SQL Server saat ini. Kedua, jika Anda berada dalam FULLmodel pemulihan, ini akan menghancurkan rantai log Anda dan memerlukan cadangan lengkap baru.

• Lepaskan database, hapus file log, dan pasang kembali . Saya tidak bisa menekankan betapa berbahayanya ini. Basis data Anda mungkin tidak muncul kembali, mungkin muncul sebagai tersangka, Anda mungkin harus kembali ke cadangan (jika ada), dll. Dll.

• Gunakan opsi "shrink database" . DBCC SHRINKDATABASEdan opsi rencana pemeliharaan untuk melakukan hal yang sama adalah ide yang buruk, terutama jika Anda benar-benar hanya perlu menyelesaikan masalah masalah log. Targetkan file yang ingin Anda sesuaikan dan sesuaikan secara mandiri, menggunakan DBCC SHRINKFILEatau ALTER DATABASE ... MODIFY FILE(contoh di atas).

• Kecilkan file log ke 1 MB . Ini terlihat menggoda karena, hei, SQL Server akan membiarkan saya melakukannya dalam skenario tertentu, dan lihat semua ruang yang dibebaskannya! Kecuali jika basis data Anda hanya baca (dan itu, Anda harus menandainya menggunakan itu ALTER DATABASE), ini benar-benar hanya akan menyebabkan banyak peristiwa pertumbuhan yang tidak perlu, karena log harus mengakomodasi transaksi saat ini terlepas dari model pemulihan. Apa gunanya membebaskan ruang itu untuk sementara waktu, hanya agar SQL Server dapat mengembalikannya secara perlahan dan menyakitkan?

• Buat file log kedua . Ini akan memberikan bantuan sementara untuk drive yang telah mengisi disk Anda, tetapi ini seperti mencoba memperbaiki paru yang tertusuk dengan bantuan pita. Anda harus berurusan dengan file log yang bermasalah secara langsung, bukan hanya menambahkan masalah potensial lainnya. Selain mengarahkan beberapa aktivitas log transaksi ke drive lain, file log kedua benar-benar tidak berguna bagi Anda (tidak seperti file data kedua), karena hanya satu file yang dapat digunakan pada satu waktu. Paul Randal juga menjelaskan mengapa banyak file log dapat menggigit Anda nanti .

Bersikap proaktif

Alih-alih mengecilkan file log Anda ke sejumlah kecil dan membiarkannya terus-menerus autogrow dengan harga kecil sendiri, atur ke beberapa ukuran yang cukup besar (yang akan mengakomodasi jumlah set transaksi bersamaan terbesar Anda) dan tetapkan autogrow yang masuk akal menetapkan sebagai mundur, sehingga tidak harus tumbuh beberapa kali untuk memuaskan transaksi tunggal dan sehingga akan relatif jarang untuk itu harus tumbuh selama operasi bisnis normal.

Pengaturan terburuk yang mungkin terjadi di sini adalah pertumbuhan 1 MB atau pertumbuhan 10%. Cukup lucu, ini adalah default untuk SQL Server (yang saya keluhkan dan minta perubahan tidak berhasil ) - 1 MB untuk file data, dan 10% untuk file log. Yang pertama jauh terlalu kecil di hari ini dan usia, dan yang terakhir mengarah ke acara yang lebih lama setiap kali (katakanlah, file log Anda adalah 500 MB, pertumbuhan pertama adalah 50 MB, pertumbuhan berikutnya adalah 55 MB, pertumbuhan berikutnya adalah 60,5 MB , dll. - dan pada I / O lambat, percayalah, Anda akan benar-benar memperhatikan kurva ini).

Bacaan lebih lanjut

Tolong jangan berhenti di sini; sementara banyak saran yang Anda lihat di sana tentang menyusutkan file log secara inheren buruk dan bahkan berpotensi bencana, ada beberapa orang yang lebih peduli tentang integritas data daripada membebaskan ruang disk.

Sebuah posting blog yang saya tulis pada tahun 2009, ketika saya melihat beberapa posting "inilah cara mengecilkan file log" muncul .

Sebuah posting blog Brent Ozar menulis empat tahun lalu, menunjuk ke banyak sumber, sebagai tanggapan terhadap artikel Majalah SQL Server yang seharusnya tidak dipublikasikan .

Sebuah posting blog oleh Paul Randal menjelaskan mengapa pemeliharaan t-log penting dan mengapa Anda juga tidak perlu mengecilkan file data Anda .

Mike Walsh memiliki jawaban yang bagus yang mencakup beberapa aspek ini juga, termasuk alasan mengapa Anda mungkin tidak dapat segera mengecilkan file log Anda .

-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1]) 


USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

Dari: DBCC SHRINKFILE (Transact-SQL)

Anda mungkin ingin membuat cadangan terlebih dahulu.

PENOLAKAN: Silakan baca komentar di bawah ini dengan seksama, dan saya menganggap Anda sudah membaca jawaban yang diterima. Seperti yang saya katakan hampir 5 tahun yang lalu:

jika ada yang punya komentar untuk ditambahkan untuk situasi ketika ini BUKAN solusi yang memadai atau optimal maka silakan komentar di bawah ini

• Klik kanan pada nama basis data.

• Pilih Tugas → Kecilkan → Database

• Kemudian klik OK!

Saya biasanya membuka direktori Windows Explorer yang berisi file-file database, jadi saya bisa langsung melihat efeknya.

Sebenarnya saya cukup terkejut ini berhasil! Biasanya saya sudah menggunakan DBCC sebelumnya, tetapi saya hanya mencobanya dan tidak menyusut apa pun, jadi saya mencoba GUI (2005) dan bekerja dengan sangat baik - membebaskan 17 GB dalam 10 detik

Dalam mode Pemulihan penuh ini mungkin tidak berfungsi, jadi Anda harus mencadangkan log terlebih dahulu, atau mengubah ke Pemulihan sederhana, lalu mengecilkan file. [terima kasih @onupdatecascade untuk ini]

-

PS: Saya menghargai apa yang telah dikomentari beberapa orang mengenai bahaya ini, tetapi di lingkungan saya saya tidak punya masalah melakukan ini sendiri terutama karena saya selalu melakukan pencadangan penuh terlebih dahulu. Jadi harap pertimbangkan apa lingkungan Anda, dan bagaimana ini memengaruhi strategi cadangan dan keamanan pekerjaan Anda sebelum melanjutkan. Yang saya lakukan hanyalah mengarahkan orang ke fitur yang disediakan oleh Microsoft!

Di bawah ini adalah skrip untuk mengecilkan log transaksi, tetapi saya pasti akan merekomendasikan mencadangkan log transaksi sebelum mengecilkannya.

Jika Anda hanya mengecilkan file Anda akan kehilangan satu ton data yang mungkin datang sebagai penyelamat jika terjadi bencana. Log transaksi berisi banyak data berguna yang dapat dibaca menggunakan pembaca log transaksi pihak ketiga (dapat dibaca secara manual tetapi dengan usaha yang ekstrem).

Log transaksi juga merupakan keharusan ketika datang ke titik pemulihan waktu, jadi jangan hanya membuangnya, tetapi pastikan Anda mencadangkannya sebelumnya.

Berikut adalah beberapa pos di mana orang menggunakan data yang disimpan dalam log transaksi untuk menyelesaikan pemulihan:

• Cara melihat log transaksi di SQL Server 2008

• Baca file log (* .LDF) di SQL Server 2008

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

Anda mungkin mendapatkan kesalahan yang terlihat seperti ini ketika menjalankan perintah di atas

"Tidak dapat mengecilkan file log (nama file log) karena file log logis yang terletak di akhir file sedang digunakan"

Ini berarti TLOG sedang digunakan. Dalam hal ini coba jalankan ini beberapa kali berturut-turut atau temukan cara untuk mengurangi aktivitas basis data.

Ini adalah cara yang sederhana dan sangat tidak akurat & berpotensi berbahaya .

1. Cadangkan DB
2. Lepaskan DB
3. Ganti nama file Log
4. Lampirkan DB
5. File log baru akan dibuat ulang
6. Hapus file Log yang Dikenal Kembali.

Saya menduga Anda tidak melakukan backup log. (Yang memotong log). Saran saya adalah mengubah model pemulihan dari penuh menjadi sederhana . Ini akan mencegah log mengasapi.

Jika Anda tidak menggunakan log transaksi untuk mengembalikan (yaitu Anda hanya pernah melakukan backup penuh), Anda dapat mengatur Mode Pemulihan ke "Sederhana", dan log transaksi akan segera menyusut dan tidak pernah terisi lagi.

Jika Anda menggunakan SQL 7 atau 2000, Anda dapat mengaktifkan "truncate log on checkpoint" di tab opsi database. Ini memiliki efek yang sama.

Ini tidak direkomendasikan di lingkungan produksi jelas, karena Anda tidak akan dapat mengembalikan ke titik waktu.

Teknik yang direkomendasikan John ini tidak direkomendasikan karena tidak ada jaminan bahwa database akan dilampirkan tanpa file log. Ubah database dari penuh menjadi sederhana, paksakan pos pemeriksaan, dan tunggu beberapa menit. SQL Server akan menghapus log, yang kemudian Anda dapat menyusutkan menggunakan DBCC SHRINKFILE.

Sebagian besar jawaban di sini sejauh ini dengan asumsi Anda tidak benar-benar membutuhkan file Transaction Log, namun jika database Anda menggunakan FULLmodel pemulihan, dan Anda ingin menyimpan cadangan Anda jika Anda perlu mengembalikan database, maka jangan memotong atau menghapus file. log file seperti yang disarankan oleh banyak jawaban ini.

Menghapus file log (dengan memotongnya, membuangnya, menghapusnya, dll) akan memutus rantai cadangan Anda, dan akan mencegah Anda memulihkan ke titik waktu sejak cadangan log transaksi penuh, diferensial, atau transaksi terakhir, hingga penuh berikutnya atau cadangan diferensial dibuat.

Dari artikel Microsoft padaBACKUP

Kami menyarankan Anda untuk tidak pernah menggunakan NO_LOG atau TRUNCATE_ONLY untuk memotong log transaksi secara manual, karena ini memutus rantai log. Hingga cadangan basis data lengkap atau diferensial berikutnya, basis data tidak dilindungi dari kegagalan media. Gunakan pemotongan log manual hanya dalam keadaan yang sangat khusus, dan segera buat cadangan data.

Untuk menghindarinya, buat cadangan file log Anda ke disk sebelum menyusut. Sintaksnya akan terlihat seperti ini:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

Log transaksi SQL Server perlu dipelihara dengan baik untuk mencegah pertumbuhan yang tidak diinginkan. Ini berarti menjalankan pencadangan log transaksi cukup sering. Dengan tidak melakukan itu, Anda berisiko log transaksi menjadi penuh dan mulai tumbuh.

Selain jawaban untuk pertanyaan ini saya sarankan membaca dan memahami log transaksi mitos umum. Bacaan ini dapat membantu memahami log transaksi dan memutuskan teknik apa yang akan digunakan untuk "menghapusnya":

Dari 10 mitos log transaksi SQL Server yang paling penting :

Mitos: Server SQL saya terlalu sibuk. Saya tidak ingin membuat cadangan log transaksi SQL Server

Salah satu operasi intensif kinerja terbesar di SQL Server adalah peristiwa tumbuh-otomatis dari file log transaksi online. Dengan tidak membuat cadangan log transaksi cukup sering, log transaksi online akan penuh dan harus tumbuh. Ukuran pertumbuhan standar adalah 10%. Semakin sibuk basis datanya, semakin cepat log transaksi online akan tumbuh jika cadangan log transaksi tidak dibuat. Membuat cadangan log transaksi SQL Server tidak memblokir log transaksi online, tetapi acara pertumbuhan otomatis tidak. Itu dapat memblokir semua aktivitas dalam log transaksi online

Dari Mitos log transaksi :

Mitos: Penyusutan log secara teratur adalah praktik perawatan yang baik

SALAH. Pertumbuhan log sangat mahal karena potongan baru harus di-zero-out. Semua aktivitas tulis berhenti pada database itu sampai zeroing selesai, dan jika penulisan disk Anda lambat atau ukuran autogrowth besar, jeda itu bisa sangat besar dan pengguna akan melihat. Itulah salah satu alasan mengapa Anda ingin menghindari pertumbuhan. Jika Anda mengecilkan log, itu akan tumbuh lagi dan Anda hanya membuang-buang operasi disk pada gim menyusut dan tumbuh lagi yang tidak perlu

Pertama periksa model pemulihan basis data. Secara default, SQL Server Express Edition membuat database untuk model pemulihan sederhana (jika saya tidak salah).

Backup log DatabaseName Dengan Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile akan memberi Anda nama file log logis.

Mengacu pada:

Pulihkan dari log transaksi lengkap dalam database SQL Server

Jika basis data Anda dalam Model Pemulihan Penuh dan jika Anda tidak mengambil cadangan TL, ubah ke SIMPLE.

Gunakan DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY)perintah. Jika ini adalah database uji dan Anda mencoba untuk menghemat / merebut kembali ruang, ini akan membantu.

Namun ingat bahwa TX log memiliki semacam ukuran minimum / kondisi tunak yang akan tumbuh. Bergantung pada model pemulihan Anda, Anda mungkin tidak dapat mengecilkan log - jika dalam FULL dan Anda tidak mengeluarkan cadangan log TX log tidak dapat menyusut - itu akan tumbuh selamanya. Jika Anda tidak memerlukan cadangan log TX, alihkan model pemulihan ke Simple .

Dan ingat, jangan pernah dalam keadaan apa pun menghapus file log (LDF)! Anda akan mengalami banyak kerusakan database instan. Matang! Selesai! Data hilang! Jika dibiarkan "tidak diperbaiki", file utama MDF dapat rusak secara permanen.

Jangan pernah menghapus log transaksi - Anda akan kehilangan data! Sebagian dari data Anda ada di Log TX (terlepas dari model pemulihan) ... jika Anda melepaskan dan "mengganti nama" file log TX yang secara efektif menghapus bagian dari database Anda.

Bagi mereka yang telah menghapus Log TX Anda mungkin ingin menjalankan beberapa perintah checkdb dan memperbaiki korupsi sebelum Anda kehilangan lebih banyak data.

Lihat posting blog Paul Randal tentang topik ini, saran yang buruk .

Juga secara umum tidak menggunakan shrinkfile pada file MDF karena dapat sangat memecah-mecah data Anda. Lihat bagian Saran Buruknya untuk info lebih lanjut ("Mengapa Anda tidak harus mengecilkan file data Anda")

Lihatlah situs web Paul - dia membahas pertanyaan-pertanyaan ini. Bulan lalu dia membahas banyak masalah ini dalam seri Myth A Day- nya.

Untuk Memotong file log:

• Cadangkan basis data
• Lepaskan basis data, baik dengan menggunakan Enterprise Manager atau dengan menjalankan: Sp_DetachDB [DBName]
• Hapus file log transaksi. (atau ganti nama file, untuk berjaga-jaga)
• Pasang kembali basis data lagi menggunakan: Sp_AttachDB [DBName]
• Ketika database dilampirkan, file log transaksi baru dibuat.

Untuk Mengecilkan file log:

• Cadangan log [DBName] dengan No_Log

• Kecilkan basis data dengan:

  Menggunakan Enterprise manager: - Klik kanan pada database, Semua tugas, Kecilkan database, File, Pilih file log, OK.

  Menggunakan T-SQL: - Dbcc Shrinkfile ([Log_Logical_Name])

Anda dapat menemukan nama logis file log dengan menjalankan sp_helpdb atau dengan melihat properti database di Enterprise Manager.

Untuk pengalaman saya di sebagian besar SQL Server tidak ada cadangan dari log transaksi. Cadangan lengkap atau cadangan diferensial adalah praktik yang umum, tetapi cadangan log transaksi jarang terjadi. Jadi file log transaksi tumbuh selamanya (sampai disk penuh). Dalam hal ini model pemulihan harus diatur ke " sederhana ". Jangan lupa untuk memodifikasi database sistem "model" dan "tempdb" juga.

Cadangan database "tempdb" tidak masuk akal, jadi model pemulihan db ini harus selalu "sederhana".

1. Ambil cadangan file MDB.
2. Hentikan layanan SQL
3. Ganti nama file log
4. Mulai layanan

(Sistem akan membuat file log baru.)

Hapus atau pindahkan file log yang diubah namanya.

Itu terjadi dengan saya di mana file log database 28 GB.

Apa yang dapat Anda lakukan untuk mengurangi ini? Sebenarnya, file log adalah data file yang disimpan oleh server SQL ketika transaksi telah terjadi. Untuk transaksi untuk memproses server SQL mengalokasikan halaman untuk hal yang sama. Tetapi setelah selesainya transaksi, ini tidak dirilis tiba-tiba berharap bahwa mungkin ada transaksi datang seperti yang sama. Ini menampung ruang.

Langkah 1: Pertama Jalankan perintah ini dalam pemeriksaan database yang dieksplorasi titik pemeriksaan

Langkah 2: Klik kanan pada database Tugas> Pencadangan Pilih jenis pencadangan sebagai Log Transaksi Tambahkan alamat tujuan dan nama file untuk menyimpan data cadangan (.bak)

Ulangi langkah ini lagi dan saat ini berikan nama file lain

Langkah 3: Sekarang pergi ke database Klik kanan pada database

Tugas> Susut> File Pilih jenis File sebagai Log Tindakan susut sebagai lepaskan ruang yang tidak digunakan

Langkah 4:

Periksa file log Anda secara normal di SQL 2014 ini dapat ditemukan di

C: \ Program Files \ Microsoft SQL Server \ MSSQL12.MSSQL2014EXPRESS \ MSSQL \ DATA

Dalam kasus saya, ini berkurang dari 28 GB menjadi 1 MB

Coba ini:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

Database → klik kanan Properties → file → tambahkan file log lain dengan nama yang berbeda dan setel path sama dengan file log lama dengan nama file yang berbeda.

Database secara otomatis mengambil file log yang baru dibuat.

1. Cadangkan DB
2. Lepaskan DB
3. Ganti nama file Log
4. Lampirkan DB (sambil melampirkan hapus .ldf berganti nama (file log). Pilih dan hapus dengan menekan tombol Hapus)
5. File log baru akan dibuat ulang
6. Hapus file Log yang Dikenal Kembali.

Ini akan berfungsi tetapi disarankan untuk mengambil cadangan dari basis data Anda terlebih dahulu.

Beberapa jawaban lain tidak berfungsi untuk saya: Tidak mungkin membuat pos pemeriksaan ketika db sedang online, karena log transaksi penuh (betapa ironisnya). Namun, setelah mengatur basis data ke mode darurat, saya dapat mengecilkan file log:

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

Contoh:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Jawaban yang sedikit diperbarui, untuk MSSQL 2017, dan menggunakan studio manajemen server SQL. Saya pergi sebagian besar dari instruksi ini https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

Saya memiliki cadangan db baru-baru ini, jadi saya membuat cadangan log transaksi. Lalu saya mencadangkannya kembali untuk ukuran yang baik. Akhirnya saya menyusutkan file log, dan beralih dari 20G ke 7MB, lebih sesuai dengan ukuran data saya. Saya tidak berpikir log transaksi telah didukung sejak ini diinstal 2 tahun yang lalu .. jadi menempatkan tugas itu di kalender rumah tangga.

Log Transaksi DB Susut ke ukuran minimum :

1. Cadangan: Log transaksi
2. Kecilkan file: Log transaksi
3. Cadangan: Log transaksi
4. Kecilkan file: Log transaksi

Saya membuat tes pada beberapa DB: urutan ini berfungsi .

Itu biasanya menyusut menjadi 2MB .

ATAU dengan skrip:

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --Input Variable
EXEC 
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO