Wpis z mikrobloga

via Wykop Mobilny (Android)
  • 0
Hej, jako że internet nie jest jeszcze pełen różnych tutoriali i blogasków, to postanowiłem wraz z kumplem stworzyć coś swojego i ja będę odpowiadał za wpsiy z tematyki #mssql #sql
Luźny blog, mniej teorii, więcej przykładów nawet bez dokładnych opisów wszelkich użytych funkcji, tylko żeby pokazać co się da zrobić i zaciekawić czytelnika. Bo zawsze twierdziłem, że bardziej liczy się wiedza że można coś zrobić, a niekoniecznie jak to zrobić, przecież mamy Google ( ͡ ͜ʖ ͡)
Ale może są jakieś tematy które was ciekawią, chcielibyście mieć opisane z przykładami bądź zawsze mieliście problemy z dokładnym zrozumieniem? Chętnie opiszę, tylko proszę o tematy związane z developmentem i optymalizacją zapytań/struktury, na backupach/rzeczach administracyjnych się nie znam poza podstawy sprawdzania wydajności serwera ( )
  • 6
via Wykop Mobilny (Android)
  • 0
@JacobTheLiar: masz jakiś sposób na replikacje tego problemu? Ale po pierwsze to bym zerknął kiedy ostatnio był log backup albo full backup, bo bez tego w full recovery log się nigdy nie wyczyści ( )
via Wykop Mobilny (Android)
  • 0
@JacobTheLiar: a, i bym jeszcze sprawdził jaki jest autogrowth pliku log, bo może być ustawiony na jakieś wielkie wartości, a plik sam się potem nie zmniejszy, tylko miejsce zostanie oznaczone dla serwera jako puste. DBCC SHRINKFILE może pomóc jak przez przypadek urośnie, ale nie polecam stosować za każdym razem, bo potem masz nadmiarową pracę serwera jak znowu musi urosnąć ( )
@DarkAlchemy: FullBackup jest robiony co 24h i niestety nie zmienia to wielkości pliku. Autogrowth jest ustawiony na przyzwoite wartości i po tyle wzrasta co jakiś czas.

Nie wiem, czy o nie ma związku z tym, że klient do bazy jest podłączony 24h/dobę.

Pomaga dopiero wykonanie przełączenia bazę w tryb Simple Recovery Model i ponowne przełączenia na Full Recovery Model powoduje, że popracuje kilkanaście-kilkadziesiąt dni i znowu mam zapełniony dysk. Myślałem, ze