Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
bargain Member Откуда: Сообщений: 3 |
Добрый день! Прошу подсказать советом. Что-то смущают несколько факторов относительно нашей основной базы. 1) Не меняется ни размер, ни даты файлов (mdf ldf) в проводнике именно этой базы SQL, с момента последнего выключения сервера 30.10.2020. У другой базы меняется только mdf. 2) Оперативная память на процессе sqlservr уже больше 21 гигабайта 3) При создании отчета занятое место на диске показывает данные на 30.10.2020г. и есть запись что "в журнале трассировки не найдена запись автоматического увеличения или сжатия для базы данных". Из всего этого напрашивается только один вывод- база данных крутится в оперативке, возможно ли вообще такое? Очень хотелось бы ошибиться. Базы 1С. Метод восстановления- простая. SQL Server 2008R2 |
15 фев 21, 10:21 [22280983] Ответить | Цитировать Сообщить модератору |
max44 Member Откуда: МОСКВА Сообщений: 279 |
"база данных крутится в оперативке, возможно ли вообще такое?" БД так или иначе крутиться в оперативке, но на диск обязательно идет запись. пункт 1) это нормально пункт 2) MS SQL Server забирает памяти столько сколько ему нужно, ограничение только в ее доступности или настройках которые не разрешают выделять SQL Server больше определенного лимита. пункт 3) Каким отчетом (или запросом) смотрите занятое место на диске, опубликуйте название отчета (или текст запроса) + скрин экрана с результатом. |
15 фев 21, 11:51 [22281005] Ответить | Цитировать Сообщить модератору |
L_argo Member Откуда: Сообщений: 1386 |
В базе было много свободного пространства. Оно постепенно заполняется. Но пока не заполнится, файл будет прежнего размера. |
15 фев 21, 11:55 [22281009] Ответить | Цитировать Сообщить модератору |
Ролг Хупин Member Откуда: Чебаркуль Сообщений: 3970 |
А можно расшифровать для ткскыть чяйников эту фразу: "БД так или иначе крутиться в оперативке,[/b] но на диск обязательно идет запись." Например, для простоты: если "оперативки" на сервере скажем 32 ГБ, а база 1 ТБ, то как она "так или иначе крутиться в оперативке"? |
||||
15 фев 21, 12:03 [22281012] Ответить | Цитировать Сообщить модератору |
bargain Member Откуда: Сообщений: 3 |
Спасибо за ответ. Нажимаю правой кнопкой на базу в management studio, отчеты-стандартный отчет-занято место на диске. А по поводу сообщения "в журнале трассировке ..." это ничего страшного? К сообщению приложен файл. Размер - 75Kb |
||||
15 фев 21, 12:10 [22281020] Ответить | Цитировать Сообщить модератору |
max44 Member Откуда: МОСКВА Сообщений: 279 |
"если "оперативки" на сервере скажем 32 ГБ, а база 1 ТБ, то как она "так или иначе крутиться в оперативке"?" по моему для чайников я дал ответ во втором пункте: пункт 2) MS SQL Server забирает памяти столько сколько ему нужно, ограничение только в ее доступности или настройках которые не разрешают выделять SQL Server больше определенного лимита. Для более продвинутых пацанов можно почитать здесь: https://docs.microsoft.com/ru-ru/sql/relational-databases/memory-management-architecture-guide?view=sql-server-ver15 Ролг Хупин, судя по количеству ваших постов в ветке форума про MS-SQL вы точно не чайник:) а скорее Гуру! |
15 фев 21, 12:16 [22281025] Ответить | Цитировать Сообщить модератору |
max44 Member Откуда: МОСКВА Сообщений: 279 |
"А по поводу сообщения "в журнале трассировке ..." это ничего страшного?" не страшно, присоединяюсь к ответу от "L_argo" судя по скрину отчета у вас больше половины файла данных не занято, вы скорей всего еще не скоро увидите в журнале трассировки сообщения об изменения физического размера файлов. |
15 фев 21, 12:21 [22281032] Ответить | Цитировать Сообщить модератору |
max44 Member Откуда: МОСКВА Сообщений: 279 |
"Метод восстановления- простая" если это не тестовая база, то я вам рекомендую включить режим FULL и грамотно настроить резервное копирование ... |
15 фев 21, 12:24 [22281034] Ответить | Цитировать Сообщить модератору |
bargain Member Откуда: Сообщений: 3 |
max44, В личке хотел обсудить 10 минутную консультацию по поводу как это сделать. Естественно не задаром, но не нашел куда писать. |
15 фев 21, 12:54 [22281058] Ответить | Цитировать Сообщить модератору |
max44 Member Откуда: МОСКВА Сообщений: 279 |
почитайте здесь Модели восстановления: https://docs.microsoft.com/ru-ru/sql/relational-databases/backup-restore/recovery-models-sql-server?view=sql-server-2016 https://docs.microsoft.com/ru-ru/sql/relational-databases/backup-restore/create-a-full-database-backup-sql-server?view=sql-server-2016 разделы: - Полное резервное копирование - Разностное резервное копирования - Журнал транзакций - + Восстановление потренируйтесь самостоятельно: создавая резервную копию вашей рабочей БД и ее восстановление на соседнем сервере (если нет такой возможности, то в "соседнюю БД"), аккуратнее не затрите рабочую БД. потом подключайтесь к восстановленной БД клиентом 1С с смотрите какие данные попали в копию ... Когда вы "своими руками" все эти вещи практически "пощупаете" у вас будет начальное понимание зачем и как создать свои стратегии резервного копирования и восстановления в случае сбоев, тогда возможно появятся и уточняющие вопросы. |
15 фев 21, 14:35 [22281127] Ответить | Цитировать Сообщить модератору |
Ролг Хупин Member Откуда: Чебаркуль Сообщений: 3970 |
тут такое дело: не задаром - это ко мне, вопросы к max44 в личке или публично. ![]() |
||||
15 фев 21, 14:43 [22281138] Ответить | Цитировать Сообщить модератору |
uaggster Member Откуда: Сообщений: 950 |
Хрустальный шар показывает, что имелось ввиду следующее: База в любом случае "крутится" в оперативной памяти, т.к. процессор может обрабатывать данные, которые расположены только в озу (ну, и в регистрах процессора), но никак не на диске. :-) MSSQLSERVER стремится удерживать данные, которые подняты с диска в ОЗУ так долго, как только возможно. Судить, как это у него получается, можно по параметру Page life expectancy из sys.dm_os_performance_counters. При этом сервер, разумеется, непрерывно пишет на диск, в файл лога, потому что ни одна транзакция, читай: вставка, удаление, модификация данных - не может быть завершена, пока не произведена запись о ней в лог (правда, тут есть нюансы с отложенной устойчивостью, которая появилась в 2016). База в 1 Тб может легко помещаться в 32 Гб ОЗУ, если речь, например, идет об OLTP базе, операции в которой идут на самых "свежих" страницах таблиц, а "старые" данные - не используются. Или используются, но, например используемые данные, целиком ложатся в компактные покрывающие индексы, которые сами в память помещаются, а данные за пределами этих индексов - не используются. Так что, на мой взгляд, приведенные тезисы - вполне осмысленны. :-) |
||||||||
15 фев 21, 15:17 [22281174] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |