Templog.ldf saya sangat besar (45GB), Bagaimana jika sesuatu harus saya lakukan?


8

Saya sudah menginstal SQL 2005 dan file templog.ldf saya terus berkembang untuk mengkonsumsi semua ruang kosong pada drive itu. Kadang-kadang akan berhenti dengan beberapa mb gratis tetapi kadang-kadang lebih jauh, ini menjadi drive saya pikir perilaku ini mungkin terlibat dalam beberapa masalah lain yang telah saya lihat.

Pertanyaan saya adalah, apa yang harus saya lakukan, saya dapat memindahkan log ke drive lain tapi saya punya alasan untuk menganggap itu tidak akan melakukan hal yang sama di sana. Saya berasumsi bahwa perilaku ini kemungkinan sebagai akibat dari sesuatu yang dapat saya ubah dan bahwa 45GB adalah ukuran yang tidak biasa untuk tempdb log. Kami memang menggunakan banyak tabel sementara dan fungsi-fungsi bernilai tabel dalam kode kami sehingga ada banyak ruang untuk menggunakan tempdb, saya bisa memahami basis data tempdb yang berkembang tetapi tidak mengerti alasan pertumbuhan templog.

Sejauh ini, saya sudah menjalankan DBCC OPENTRAN ('tempdb') untuk melihat apakah ada transaksi lama yang berkeliaran, tidak. Saya telah membaca tentang cara mengecilkan tempdb dan telah melakukan ini beberapa kali, tetapi saya benar-benar bertanya-tanya bagaimana jika apa pun yang dapat saya lakukan untuk menghentikan ini terjadi di tempat pertama atau lebih detail tentang mengapa itu mungkin tumbuh begitu banyak di posisi pertama.

== EDIT ==

1) Tempdb menggunakan model pemulihan sederhana

2) Pertumbuhan templog terjadi selama beberapa jam di pagi hari ketika kami memiliki beberapa permintaan terjadwal berjalan, pada dasarnya beban pelaporan yang kehabisan jam kantor untuk hari berikutnya. Ukuran file terus bertambah dari waktu ke waktu ini. Kami mengontrol berapa banyak laporan bersamaan yang berjalan pada saat yang sama, meningkatkan jumlah laporan bersamaan meningkatkan laju pertumbuhan log.


Anda harus melihat (dan memposting?) SQL untuk laporan itu.
RBarryYoung

Jawaban:


3

Periksa kueri pelaporan Anda. Apakah Anda memiliki yang berbeda di dalamnya? Apakah ada di antara mereka yang memiliki kartesian bergabung?

Apakah ada dari kueri pelaporan yang mengakses server yang ditautkan sebagai anggota bergabung? Jika demikian, ini dapat menyebabkan tempdb log dan database bertambah.

Ketika laporan berjalan di pagi hari, apakah ada yang rusak?


Kami sedang mencari lebih jauh tentang ini sekarang, saya akan memposting hasilnya ketika saya memiliki sesuatu yang meyakinkan. Saat ini terlihat seperti satu laporan macet tetapi tidak melepaskan koneksi itu. Saya pikir kemudian orang lain akan melalui tetapi menyebabkan log untuk memperluas karena transaksi yang sebelumnya tidak lengkap.
Robin

Terima kasih atas jawabannya, Masalah saya cukup jelas ke laporan mogok sekarang, saya telah membatasi ukuran templog dapat tumbuh. Saya telah melihat pertumbuhan pelarian dalam hubungannya dengan laporan gagal tidak melakukan transaksi. Saya tidak yakin apakah ada sesuatu yang sangat buruk dalam laporan sql karena mereka berjalan dengan baik di bawah SQL Server 2000 tetapi saya akan menyelidiki apa yang mereka lakukan juga.
Robin

4

Kami memiliki masalah yang sama, setelah mengangkat panggilan PSS dengan Microsoft dan investigasi mendalam tentang masalah ini kami zonasi dengan kemungkinan penyebab dan resolusi berikut.

Sebab:

Kemungkinan penyebab gejalanya adalah karena disk / lun tempat database pengguna ditempatkan mengalami masalah respons I / O yang parah; ini menyebabkan pos pemeriksaan otomatis pada basis data pengguna sangat lama untuk diselesaikan.

Sekarang, pos pemeriksaan pada tempdb hanya terjadi ketika tempdb log menjadi 70% penuh dan juga memiliki prioritas lebih rendah daripada pos pemeriksaan basis data pengguna. Jadi, efektif ketika pos pemeriksaan otomatis pada basis data pengguna dikeluarkan dan sedang mencoba untuk menyelesaikan, karena penggunaan tempdb yang berat menyebabkan file log tempdb terisi dengan cepat; pada 70% penggunaan log, pos pemeriksaan tempdb terjadi tetapi dalam antrian di belakang pos pemeriksaan basis data pengguna.

Dalam waktu yang dibutuhkan untuk pos pemeriksaan basis data pengguna untuk menyelesaikan file log tempdb terus terisi dan jika autogrow diatur, file log akan bertambah ketika membutuhkan lebih banyak ruang. Inilah alasan mengapa file log terus bertambah.

Singkatnya, akar penyebab yang paling mungkin untuk gejala yang Anda gambarkan adalah karena respons I / O yang buruk dari disk / lun untuk pengguna Anda dan / atau file database / log tempdb.

Larutan:

Kami mengatasi masalah ini sementara kami menyortir subsistem I / O dengan mengatur peringatan yang dipecat ketika file log tempdb menjadi 75% penuh dan sebagai respons menjalankan pekerjaan yang memaksa manual "CHECKPOINT" (yang diutamakan daripada sistem otomatis) checkpoints), membersihkan tempdb log yang mencegahnya tumbuh secara otomatis tanpa batas. Itu masih merupakan ide yang baik untuk membiarkan file log pada tumbuh otomatis untuk kemungkinan lain. Juga, saya sangat menyarankan Anda untuk mempertimbangkan mengurangi ukuran file log tempdb menjadi sesuatu yang bermakna sesuai lingkungan Anda setelah Anda memperbaikinya.

Semoga ini membantu.


Ini adalah solusi pada contoh SQL 2000 yang dikonfigurasi dengan buruk yang saya warisi di mana semua data dan file log berada di satu disk. Kami tidak dapat menambahkan penyimpanan sehingga saya mengukur ukuran file berdasarkan penggunaan dan memiliki pekerjaan yang menjalankan pos pemeriksaan setiap 30 menit.
Your_comment_is_not_funny

1

Apa Model Pemulihan diatur ke pada temp db? Jika tidak diatur ke Simple, maka atur ke Simple. Ini harus mencegahnya tumbuh. Jika sudah diatur ke Simple maka saya akan mengatakan ada masalah mendasar yang perlu diatasi dan setiap upaya untuk mengecilkan file hanyalah mengobati gejala dari masalah dan bukan akar penyebabnya.


ya, ini diatur ke pemulihan sederhana, saya hanya memeriksa dua kali bahwa ketika saya menulis posting, kemudian lupa untuk memasukkannya di atas.
Robin

Saya baru saja memeriksa file templog.ldf kami dan berukuran sekitar 60MB. Kami memiliki satu file tempdb untuk setiap prosesor di server. Sudahkah Anda mencoba membuat file tambahan untuk tempdb? Rekomendasi ini adalah untuk memiliki satu file untuk setiap prosesor (termasuk prosesor hyperhtreading). Server kami memiliki dua CPU dual core dengan hyperthreading sehingga kami memiliki 8 file tempdb.
joeqwerty

Itulah rekomendasi untuk SQL Server 2000. rekomendasi untuk tahun 2005 jauh lebih sedikit dari itu. Either way, itu tidak berpengaruh pada total ruang setelah Anda melampaui ukuran standar.
RBarryYoung

Ini kasus lain dari kontradiksi informasi. Artikel ini untuk SQL 2005 merekomendasikan rasio satu banding satu file ke cpu core: msdn.microsoft.com/en-us/library/ms175527(SQL.90).aspx Sementara artikel ini untuk SQL 2008 merekomendasikan hal yang sama: msdn. microsoft.com/en-us/library/ms175527.aspx
joeqwerty

Asumsi saya adalah bahwa jika ada banyak file templog, mereka tidak akan tumbuh menjadi ukuran besar.
joeqwerty

1

Saya telah menghabiskan beberapa jam terakhir membaca dan membuat catatan tentang ini

http://technet.microsoft.com/en-gb/library/cc966545.aspx

Ada banyak detail di sana dan saran untuk masalah pengambilan gambar. Tampaknya, kecuali jika tempdb Anda mengembang dan tidak pernah berhenti tumbuh, itu mungkin hanya mengambil jumlah ruang yang dibutuhkan dan seharusnya sudah dikonfigurasikan menjadi ukuran semula. Ada bagian tentang memperkirakan ruang yang diperlukan untuk tempdb Anda serta melacak apa yang mungkin menghabiskan ruang di tempdb. Sebagai hasilnya, hal pertama yang akan saya lakukan adalah memindahkan tempdb ke drive yang lebih besar dan melihat apa yang terjadi dari sana.

Ada bagian berjudul 'Ruang yang diperlukan untuk logging tempdb' yang menunjukkan fitur mana yang menggunakan log, ada bagian lain sebelumnya yang merinci superset fitur yang menggunakan tempdb.

Bagian berjudul 'Pemantauan I / O' memiliki beberapa gagasan tentang penghitung kinerja untuk ditonton, sekilas melihat server saya menempatkan ini di wilayah Anda-mungkin-mendapat-io-bottleneck. Saya akan memonitor ini sebentar dan melihat bagaimana semuanya berjalan baik. File tempdb log sebenarnya juga kurang dari pemanfaatan 50% yang sesuai dengan ide itu diperluas di bawah beban pagi ini dan telah mempertahankan ruang sejak itu.

Saya akan maju berdasarkan ukuran pertumbuhannya adalah ukuran yang dibutuhkan, pantau ukuran ini di masa depan dan pastikan ada ruang untuk pertumbuhan pada drive apa pun yang ada. Seperti yang disarankan oleh beberapa orang di sini saya akan melihat apa yang sedang dieksekusi ketika temp log mengembang dan melihat apakah ada yang bisa diubah di sana. Saya juga akan mengawasi penghitung kinerja io itu untuk melihat apakah sesuatu perlu ditangani.

Ada satu lagi bagian menarik yang berjudul 'Memutakhirkan ke SQL Server 2005' yang menunjukkan bahwa tempdb digunakan untuk lebih banyak hal pada 2005 dari 2000 (baik fitur baru, dan fitur yang sudah ada yang sebelumnya tidak menggunakan tempdb). Saya baru saja ditingkatkan ke 2005 sehingga ini bisa menjadi bagian dari alasan ini tiba-tiba menjadi masalah. Saya tidak ingat melihat ini di tempat lain dengan referensi untuk meningkatkan ke 2005, yang agak menyebalkan.


0

Ini kemungkinan besar disebabkan oleh kueri Cross Join yang tidak terkontrol. Taruhan terbaik Anda adalah menggunakan Profiler untuk menemukannya dan kemudian memperbaikinya.

Cara lain untuk menemukannya adalah dengan membatasi ukuran file log TempDB dan kemudian menunggu untuk melihat permintaan apa yang gagal. Namun, saya berani bertaruh bahwa itu sudah gagal dan tidak ada yang memberitahu Anda.


0

Jika Anda me-restart mesin SQL file akan diatur ke ukuran awal. Anda harus memberi ukuran maksimal pada semua file autogrow Anda.


0

Beberapa query SQL atau proc yang disimpan melakukan hal-hal buruk - satu-satunya yang dapat Anda lakukan adalah membuat profil tempdb untuk menangkap peristiwa "Database: Log File Auto Grow", dan ketika itu terjadi, gunakan profiler dan kueri terhadap tabel seperti proses sys untuk menemukan apa proses yang buruk.

Sayangnya, itu tergantung pada pekerjaan detektif kuno untuk melacak proses jahat.

Sudahkah Anda mencoba mengubah ukuran file log tempdb dengan DBCC SHRINKFILE ()? Jika demikian, berapa lama untuk mendapatkan dari [nilai sangat kecil] ke 45GB atau lebih?


Silakan lihat edit 2 di atas untuk perincian tentang seberapa cepat file tumbuh. Catatan ini didasarkan pada restart setelah jam kantor sebelum hari berikutnya dan pelaporan terjadwal yang disebutkan. Fakta bahwa itu tumbuh secara bertahap selama beberapa jam menunjukkan kepada saya itu bukan proses yang berperilaku buruk tetapi kombinasi dari semua beban simultan. Mungkin ukurannya tumbuh hanya ukuran yang dibutuhkannya.
Robin
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.