Каталог расширений

Популярные теги

3gp       avi       fb2       jpg       mp3       pdf      

Главная » Разное » Как усечь лог файл

Как усечь лог файл


Как усечь журнал транзакций MSSQL Server?

Журнал транзакций во всех версиях Microsoft SQL Server  имеет тенденцию расти со временем. Иногда он может заполнить все свободное место на сервере. Чтобы избежать этого, в SQL Server есть операция усечения журнала транзакций.

Журналы транзакций SQL Server и модель восстановления базы данных

Журналы транзакций используются для записи всех транзакций перед передачей данных в файл базы данных. Файлы журнала транзакций необходимы для отката базы данных до предыдущего состояния. Как правило, в журнале хранится порядковый номер, тип изменения, выполненные операции и т. д. Скорее всего, вы можете использовать SQL Server и без журнала транзакций, но тогда в в случае сбоя возможна потеря базы данных.

Журнал транзакций состоит из небольших логических элементов, называемых VLF (Virtual Log File). Вы можете узнать их количество, выполнив следующий запрос в контексте базы данных SQL Server:

DBCC LOGINFO

Количество возвращаемых строк указывает на то, сколько виртуальных файлов сегментировано в журнале. В поле «Status» отображается текущее состояние сегмента. Значение 0 означает, что сегмент в настоящее время не занят и может использоваться. 2 означает, что сегмент используется. Если свободных сегментов нет и в настройках базы данных SQL Server разрешено увеличение журнала транзакций, он будет увеличен и будут созданы новые VLF. Если размер журнала транзакций фиксирован или на диске недостаточно места, все операции по изменению структуры базы данных или ее содержимого станут недоступными. Скорее всего, вы получите ошибку: Журнал транзакций для базы данных переполнен.

Файлы журнала усекаются автоматически, в зависимости от модели восстановления, используемой в настройках SQL Server:

  • Простая модель восстановления – файлы журнала автоматически обрезаются после достижения контрольной точки (самый простой вариант, требующий администрирования базы данных). При использовании модели простого восстановления журнал транзакций очищается сразу после завершения транзакции. В этом режиме вы можете откатить вашу базу данных только до времени полного резервного копирования базы данных.
  • Модель  полного восстановления – журнал транзакций не будет очищен, пока не будет завершено резервное копирование журнала транзакций. Этот режим обеспечивает наилучшую возможность восстановления данных после сбоя. В полном режиме журнал транзакций (LDF) может увеличиваться (поскольку изменения базы данных накапливаются в этом журнале). В модели полного восстановления все транзакции SQL записываются в файлы журнала на диске и сохраняются там до создания резервной копии. Хранение журналов позволяет вам при необходимости вернуться к более ранней копии базы данных, и вы можете выполнить восстановление для каждой транзакции.
  • С неполным протоколированием – этот режим позволяет сократить занимаемое пространство используя минимальные настройки ведения журнала. Если журнал был поврежден или с момента создания последней резервной копии журналов выполнялись операции с неполным протоколированием, все изменения после этого резервного копирования необходимо внести повторно. Иначе результаты работы потеряны не будут.

Когда  используется модель полного восстановления базы данных, необходимо регулярно выполнять резервное копирование журнала транзакций, в противном случае он будет чрезмерно увеличиваться до тех пор, пока не займет все место на диске, и SQL Server не начнет сообщать об ошибке.

Как обрезать журналы транзакций на MS SQL Server?

Мы получили вот такое сообщение:

Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных “buh” заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы
sys. databases HRESULT=80040E14, SQLStvr: Error state=2, Severity=11,native=9002, line=1

Это означает, что на диске, где хранится журнал транзакций SQL, недостаточно места, и SQL не может записать новые данные транзакции. В этом случае вы можете обрезать файлы журналов SQL вручную (с помощью  графического интерфейса Management Studio).

Чтобы обрезать журналы транзакций SQL, запустите SQL Server Management Studio (SSMS), выберите нужную базу данных, щелкните ее правой кнопкой мыши и выберите «Свойства»  в контекстном меню. Перейдите в Параметры и переключите модель восстановления базы .

Меняем модель восстановления с Полной на Простую

Затем в главном меню перейдите в раздел «Задачи» -> «Сжать» -> «Файлы» .

 

В поле Тип файла выберите Журнал, в поле Имя файла укажите имя файла журнала. В поле «Операции сжатия» выберите « Реорганизовать страницы, перед тем как освободить неиспользуемое пространство» , установите нужный размер файла и нажмите «OK».

Нажимаем «OK». После завершения операции обязательно измените режим восстановления базы данных обратно на Полный.

Это только один из способов быстрого уменьшения размера логов. Не самый лучший, но очень простой и эффективный.

Кроме того, имейте в виду, что при усечении журналов транзакций SQL с помощью этого руководства все предыдущие резервные копии, сделанные в модели полного восстановления, могут быть отброшены. Вот почему этот метод следует использовать только в критических случаях, когда невозможно быстро очистить дисковое пространство другими способами.

Километры логов и восстановление баз данных на MS SQL / Блог компании СофтЛаб / Хабр

Или как без труда восстанавливать базы данных из длинной цепочки бэкапов




Введение


Если вы используете SQL Server, то, вероятно, слышали про Полную и Простую модель восстановления баз данных. Вы, возможно, знаете, что Простая модель позволяет восстановить данные только на момент создания резервной копии, в то время как Полная — на любой момент времени, надо лишь регулярно делать резервные копии журнала транзакций. Однако, для восстановления данных при Полной модели потребуется «накатить» резервные копии журналов транзакций в определенной последовательности. Это можно без проблем сделать с помощью SSMS, но только на том SQL Server, где создавались резервные копии. Для восстановления на другом сервере потребуется вручную написать T-SQL скрипт. И чем длиннее будет цепочка резервных копий, тем больше будет сам скрипт и тем больше времени уйдет на его создание. По этой же причине администраторы редко используют уже созданные резервные копии, когда требуется развернуть копию базы на другом SQL Server, и предпочитают создавать свежий полный бэкап. Но такая процедура может быть настоящей проблемой для больших баз данных из-за высокой нагрузки на сервер. Кроме этого, если сервер «упал», то, как правило, нет времени писать длинный T-SQL скрипт для восстановления. В такие моменты нужно делать все максимально быстро и без лишней нервотрепки.

В интернете, в том числе и на Хабре (например, тут), можно найти различные способы, решающие задачу автоматизированного построения T-SQL скрипта восстановления. В основном это различные скрипты, базирующиеся на названиях файлов резервных копий или запросы на сервер-источник к истории резервных копий (к базе msdb). В этой статье я хотел бы сделать обзор возможностей XML-планов восстановления, которые появились в Quick Maintenance & Backup for MS SQL начиная с версии 1.6.

Обзор самой утилиты можно почитать в статье по этой ссылке или на официальном сайте. Наличие XML-плана восстановления в сетевой папке вместе с резервными копиями позволит не тратить время на подготовку T-SQL скрипта. Какая бы длинная ни была цепочка резервных копий, вы в несколько кликов восстановите базу данных на другом SQL Server. Также это можно делать по расписанию, на тестовом или рабочем сервере, например, для проверки всей цепочки резервных копий или актуализации копий баз данных.

Что такое XML-план восстановления


XML-план восстановления — это XML-файл, в котором перечислены имена файлов резервных копий в последовательности, необходимой для восстановления одной или нескольких баз данных. Пример содержимого XML-файла:Пример
<?xml version="1.0" encoding="cp866"?> <RestorationPlanInfo xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/ScriptManagerServer.Core.ScriptManagerServerCore.BackupRestore"> <Version>1</Version> <ServerName>London</ServerName> <ServerVersion>10</ServerVersion> <ServerDescriptrion>Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) </ServerDescriptrion> <CreationDate>2016-02-16T17:00:04.65625+03:00</CreationDate> <Databases> <RestorationPlanDbInfo> <Name>Northwind</Name> <RestorePoint>2016-02-16T17:00:02</RestorePoint> <Files> <RestorationPlanDbFileInfo> <FileName>London\Northwind\Full\20160216_155457_London_Northwind_Full.bak</FileName> <BackupType>Full</BackupType> <Position>1</Position> <BackupStartDate>2016-02-16T15:54:57</BackupStartDate> <FirstLsn>58000000021900037</FirstLsn> <LastLsn>58000000023500001</LastLsn> <StopAt i:nil="true" /> </RestorationPlanDbFileInfo> <RestorationPlanDbFileInfo> <FileName>London\Northwind\Diff\20160216_162546_London_Northwind_Diff.bak</FileName> <BackupType>Differential</BackupType> <Position>1</Position> <BackupStartDate>2016-02-16T16:25:47</BackupStartDate> <FirstLsn>58000000024300034</FirstLsn> <LastLsn>58000000025800001</LastLsn> <StopAt i:nil="true" /> </RestorationPlanDbFileInfo> <RestorationPlanDbFileInfo> <FileName>London\Northwind\Log\20160216_163000_London_Northwind_Log.trn</FileName> <BackupType>Log</BackupType> <Position>1</Position> <BackupStartDate>2016-02-16T16:30:01</BackupStartDate> <FirstLsn>58000000024300001</FirstLsn> <LastLsn>58000000025800001</LastLsn> <StopAt i:nil="true" /> </RestorationPlanDbFileInfo> <RestorationPlanDbFileInfo> <FileName>London\Northwind\Log\20160216_170001_London_Northwind_Log.trn</FileName> <BackupType>Log</BackupType> <Position>1</Position> <BackupStartDate>2016-02-16T17:00:02</BackupStartDate> <FirstLsn>58000000025800001</FirstLsn> <LastLsn>58000000025800001</LastLsn> <StopAt i:nil="true" /> </RestorationPlanDbFileInfo> </Files> </RestorationPlanDbInfo> </Databases> </RestorationPlanInfo>

XML-файл всегда размещается в корневой папке с резервными копиями и содержит относительные пути до файлов резервных копий. Такая организация позволяет не терять актуальность после копирования файлов в другое место, например, в сетевую папку.

Создание XML-плана


Программа позволяет создавать XML-план двумя способами:
  • Для тех, кто обслуживает базы данных с помощью QMB, достаточно установить свойство Создавать XML-план восстановления в политике обслуживания. Теперь XML-файл будет пересоздаваться каждый раз после создания любой резервной копии в сценарии обслуживания. Если в программе настроено копирование бэкапов в сетевую папку, то файл XML-плана также будет копироваться. Таким образом в сетевой папке будет всегда свежий XML-план восстановления.
  • Тем, у кого уже имеется штатный План обслуживания, создающий бэкапы, можно воспользоваться специальной задачей и по расписанию создавать XML-план восстановления.  В задаче необходимо указать имя XML-файла, базы данных и подключение к папке, где будет создан XML-план восстановления, см. рисунок. Для того чтобы задача выполнялась по расписанию, её необходимо включить в сценарий.


Перед созданием XML-файла программа определит последовательность резервных копий по информации, хранимой в системной базе mdsb, аналогично тому, как это делает SQL Server Management Studio. Для первого и второго способов XML-план будет содержать последовательность резервных копий, необходимых для восстановления базы данных на последнее возможное состояние.

Важной особенностью является то, что при создании XML-плана программа всегда выполняет проверку наличия файлов резервных копий. Если хотя бы один из файлов не будет найден, то программа выдаст ошибку. Таким образом дополнительно контролируется целостность всей цепочки. Если XML-план создается при помощи задачи, то можно автоматически скопировать недостающие резервные копии с сервера источника. Для этого в задаче нужно установить соответствующий признак.

Восстановление по XML-плану


Восстановление баз данных по XML-плану может выполняться двумя способами:

1. Вручную. Для этого в программе имеется специальное окно, которое вызывается командой «Восстановить по XML-плану» из контекстного меню в древовидном списке серверов.


На форме нужно выбрать XML-файл и базы данных, резервные копии которых будут восстановлены. Обратите внимание, восстанавливать можно в одноименные базы данных, во временную, либо в указанную базу данных. Режим восстановления во временную базу данных удобен для проверки цепочки резервных копий. Режим в Указанную базу данных может быть полезен, если требуется восстановить в определенную базу данных, например, с нестандартным размещением её файлов на дисках. По кнопке «Показать Т-SQL» можно просмотреть сформированный T-SQL скрипт, который будет запущен для восстановления.
2. Автоматически по заданному расписанию. Например, если требуется регулярная проверка цепочки резервных копий на тестовом SQL Server, или актуализация баз данных. Для этих целей в программе предусмотрена специальная задача. Параметры, указываемые в задаче, практически аналогичны тем, что задаются на форме восстановления в ручном режиме.
Для того чтобы задача выполнялась по расписанию, её необходимо включить в сценарий. Например, в ночной. Подробный лог восстановления можно просматривать в журнале обслуживания.

Заключение


Механизм XML-планов восстановления в QMB — это отличная возможность, позволяющая значительно облегчить жизнь администраторам при восстановлении данных с километровыми логами, переносе баз на другой SQL Server и проверке бэкапов. Механизм можно задействовать даже в тех случаях, когда для резервного копирования используется стандартный План обслуживания. В дальнейшем мы планируем подготовить статью, о том как это сделать с помощью программы.

Если вы уже используете QMB и не задействовали эту возможность, то скорее включайте XML-план восстановления!  С удовольствием ответим на ваши вопросы в комментариях или по электронной почте [email protected]

Как очистить файл журнала в Linux

В этой статье вы узнаете, как обрезать файл журнала и удалять его содержимое, не удаляя сам файл.

Вы окажетесь в ситуациях, когда вам нужно очистить файл. Это часто случается, когда у вас огромные файлы журналов, и как бы вы это сделали?

Один не очень чистый способ – удалить файл, а затем создать новый файл. Но это не очень хорошая идея. Это не будет тот же файл, временная метка (atime, mtime и т. д.). Будет отличаться вместе с другими правами доступа к файлам.

Вместо создания нового пустого файла вы можете удалить его содержимое. Итак, как вы очищаете файл в Linux? Как очистить файл от всего его содержимого без удаления самого файла?

 

4 способа очистить файл в Linux

Существует несколько способов очистки файла без его фактического удаления. Позвольте нам показать вам некоторые из этих методов.

 

Способ 1: усечь файл с помощью команды truncate

Самый безопасный способ обрезать файл журнала – использовать команду truncate.

truncate -s 0 filename

 

В приведенной выше команде -s используется для установки/настройки размера (в байтах) файла. Когда вы используете -s 0, это означает, что вы изменили размер файла до 0 байт.

 

Способ 2: Пустой файл, используя :> или >

Самый простой способ очистить файл – использовать команду ниже. Если файл не используется, он будет работать в Bash:

> filename

 

Хотя вышеперечисленное работает только в Bash Shell, вы можете использовать аналогичную команду для других оболочек:

:> filename

 

Вы также можете использовать эту команду для очистки файла:

true > filename

 

Способ 3: использование команды echo для очистки файла в Linux

Другой способ очистить файл – использовать команду echo в Linux:

echo > filename

 

Вы также можете использовать команду echo следующим образом:

echo "" > filename

 

Способ 4: используйте /dev/null, чтобы очистить файл

Вы также можете использовать знаменитую /dev/null и объединить ее с командой cat для очистки файла журнала:

cat /dev/null > file.log

 

В конце…

И если у вас недостаточно прав для какой-либо из вышеперечисленных команд, это верный выстрел, но немного грязный способ добиться этого:

touch newfile
 mv newfile filename

 

Мы надеемся, что этот быстрый совет помог вам очистить файл в Linux. Добавьте нас в закладки для получения дополнительных советов по Linux.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Почему растет LOG в MS SQL ?

Почему растет LOG в MS SQL ?

Друзья, почти ежедневно сталкиваюсь с тем, что на курсе: Администратор 1С, при опросе студентов, на предмет «Как Вы организовали бэкап в MS SQL?». Очень редко кто пишет: «Да, помимо «полного» я делаю и бэкап журналов транзакций».

К сожалению, редко кто делает бэкап ЖТР (

И тем самым открывает прямой путь к таким проблемам как:

«Распух лог в MS SQL», «Сильно увеличился LDF», «Разрастается log, что делать?», «Журнал занял все свободное место на диске», и многое, многое другое.

В этой статье я не буду рассыпать терминами и сложными понятиями гуру специалиста DBA, нет!

Так как вижу реальную картину, реальную проблематику вопроса, на более чем 5000 тыс студентов (Что проходили у нас курс: Администратор 1С). И реальность она несколько в другом!

Большинство не делает бэкапов журналов транзакций, так как не понимает зависимостей (связей), между их созданием и размерами самого журнала (*ldf).

Собственно цель данной статьи, максимально понятно, на простом языке, объяснить  и закрыть раз и навсегда проблему растущего лога в MS SQL!

 

 

Приступим…

Кратко пройдемся по основам, чтоб даже новички быстро смогли уловить суть и не потеряться в терминах.

Файл *LDF он же и есть наш журнал транзакций!

Что там хранится?

Каждая база данных SQL Server имеет журнал транзакций, в котором фиксируются все транзакции и производимые ими в базе изменения.

Журнал транзакций — это важная составляющая базы данных. Если система даст сбой, этот журнал поможет вам вернуть базу данных в согласованное состояние.

Если говорить еще проще, благодаря бэкапу ЖТР есть возможность восстановить базу фактически на любой момент времени (вплоть до нужной секунды)!

При этом следует понимать, что никаких по факту данных из 1С в прямом смысле этого слова в журнале нет!

Все данные пишутся в файл *mdf, а вот фиксация этих действий пишется в *ldf, по каждому действию (транзакции), что происходит у Вас в 1С. Все что делают пользователи в 1С, фиксируется в журнале транзакций, только сам факт (фиксация) произошедших событий в базе, а не сами данные.

Собственно отсюда и название «Журнал транзакций». Конечно на практике все сложнее, но в упрощенном для понимания виде все именно так.

 

Почему растет лог файл в MS SQL (*ldf) ?

Конечно, если учитывать что каждое действие сделанное пользователем в 1С фиксируется в журнале транзакций, то он просто не может не расти! И здесь также стоит отметить, что не только действие пользователя влияет на рост журнала, но и различные регламентные задачи (фоновые различные процессы), особенно сильно заметен рост, когда происходит в базе 1С реструктуризация. Собственно при обновлении конфигурации также можем замечать “взрывной” рост журнала транзакций.

К слову мы только что ответили на частый вопрос: «Вот у меня лог не разрастался» в базе «А», а в базе «Б» растет очень быстро».

Конечно если с базой «Б» пользователи работают интенсивно или различные фоновые, регламентные задачи (их много), безусловно, он будет расти быстрее, такова физика работы «MS SQL»!

MS SQL всегда (в “полной” модели восстановления) будет пытаться зафиксировать, фактически все действия в базе. И журнал будет расти до тех пор, пока мы не сделаем его бэкап, этим мы и «усекаем» его!

 

«Простая» и «полная» модель восстановления

Да, «полная» модель восстановления подразумевает, что в журнал будем писать «По максимуму» все возможное.  Все что сможет записать MS SQL, он туда запишет. Исключения конечно есть. К примеру, когда свободное место закончилось на диске или есть ограничения на сам лог (если установили). Есть и другие причины, но мы сейчас не об этом.

Нам важно понимать одно: «Полная» модель = «Полный» лог! А значит, есть возможность не терять данные, при необходимости восстановится на любой момент времени (фактически до секунды), а выполнив бэкап еще и «заключительного фрагмента журнала» и вообще ничего не потерять!

На сайте Microsoft можно найти информацию о том, что единственная  «рабочая» модель, предназначенная для реальной работы, есть только  «Полная» модель восстановления! Так как в работе недопустимо терять данные, а это гарантированно произойдет в «Простой» модели восстановления, если случится “сбой”.

«Простая» модель восстановления может использоваться для тестирования, разработки, для временного переключения (Обязательно! С предварительным бэкапом базы и лога). К примеру, только на время реструктуризации ее можно включить, а потом обратно вернуть в «Полную» модель. Есть и другие случаи, когда мы только временно переключаем режим с «Полной в Простой» Но работаем всегда в “полной” модели восстановления!

В “простой” модели мы никак не можем восстановиться (в случаи чего) на интересующий нас момент времени. Только на тот момент, когда сделан либо «полный» бэкап, либо «полный» + «разностный»!

Вывод:

Только в «полной» модели мы должны работать! Она не зря «по умолчанию» в MS SQL!

 

 

«Активная» и «Неактивная» часть журнала

Сперва дадим ответ на вопрос:  «Что происходит в момент создания бэкапа ЖТР ?»

Чтоб разобраться в этом вопросе, нам нужно понимать, что журнал транзакций может быть «условно разделен» на две части: «Активная» и «Неактивная» часть журнала.

«Активная» – содержит изменения, которые были сделаны в базе, но еще не зафиксированы на диске.

«Неактивная» – изменения уже зафиксированы на диске, следовательно, можно усекать неактивную часть журнала (делать бэкап), вплоть до его активной части!

Неактивная часть журнала транзакций содержит информацию о завершенных транзакциях и не используется сервером SQL Server в процессе восстановления данных. Вместо увеличения размера файла журнала транзакций SQL Server будет повторно использовать освободившееся пространство.

И вот в момент, когда мы создаем бэкап журналов транзакций, мы тем самым «усекаем» его «неактивную» часть (точнее это делает сам MS SQL), вплоть до начала его активной части!

При этом вначале всегда происходит его бэкап, а только после уже «усечение», как на рисунке выше.

Бэкап журналов нужно делать довольно часто (раз на 30-60 мин), особенно если с базой активно работают пользователи, он может вырасти довольно быстро, и конечно без автоматизации этого процесса не обойтись!

Также мы можем сделать и бэкап «заключительного фрагмента журнала транзакций», если нужно восстановить базу на самый последний момент времени. В таком случаи мы также усекаем журнал (ту часть, что есть на момент создания самого заключительного фрагмента журнала).

Вывод:

В «полной» модели восстановления бэкап журналов транзакций НЕОБХОДИМ! Если Вы не хотите в один прекрасный день обнаружить, что свободное место на диске, где он находится, уже закончилось!

 

 

Если ЛОГ уже вырос ?

Конечно, если Вы раньше не делали бэкапов журналов, лог соответственно вырос, то здесь одним бэкапом журналов транзакций не обойтись!

И вот почему:

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

 

Успехов Вам, Коллега!

С уважением, Богдан.

Где посмотреть и как читать логи с ошибками сервера?

Блоги, форумы, посадочные страницы и другие интернет-ресурсы представляют собой совокупность графического, текстового, аудио- и видео-контента, размещенного на веб-страницах в виде кода. Чтобы обеспечить к ним доступ пользователей через интернет, файлы размещают на серверах. Это аппаратное обеспечение (персональный компьютер или рабочая станция), на жестком диске которого и хранится код. Ключевые функции выполняются без участия человека, что актуально для всех типов оборудования, включая виртуальный выделенный сервер. Но это не означает, что контроль не осуществляется. Большинство событий, которые происходят при участии оборудования, пользователей и софта, включая ошибки, логи сервера фиксируют и сохраняют. Из этой статьи вы узнаете, что они собой представляют, зачем нужны, и как их читать.

Что такое логи

Это текстовые файлы, которые хранятся на жестком диске сервера. Создаются и заполняются в автоматическом режиме, в хронологическом порядке. В них записываются:

  • системная информация о переданных пользователю данных;
  • сообщения о сбоях и ошибках;
  • протоколирующие данные о посетителях платформы.

Посмотреть логи сервера может каждый, у кого есть к ним доступ, но непосвященному обывателю этот набор символов может показаться бессмысленным. Интерпретировать записи и получить пользу после прочтения проще профессионалу.

Классификация логов

Для каждой разновидности софта предусмотрены соответствующие файлы. Все логи сервера могут храниться на одном диске или даже на отдельном сервере. Существует довольно много разновидностей логов, вот наиболее распространенные:

  • доступа (access_log) — записывают IP-адрес, время запроса, другую информацию о пользователях;
  • ошибок (error_log) — показывают файлы, в которых выявлены ошибки и классифицируют сбои;
  • FTP-авторизаций — отображают данные о попытках входа по FTP-соединению;
  • загрузки системы — с его помощью выполняется отладка при появлении проблем, в файл записываются основные системные события, включая сбои;
  • основной — содержит информацию о действиях с файерволом, DNS-сервером, ядром системы, FTP-сервисом;
  • планировщика задач — в нем выполняется протоколирование задач, отображаются ошибки при запуске cron;
  • баз данных — хранит подробности о запросах, сбоях, ошибки в логах сервера отображаются наравне с другой важной информацией;
  • хостинговой панели — включает статистику использования ресурсов сервера, время и количество входов в панель, обновление лицензии;
  • веб-сервера — содержит информацию о возникавших ошибках, обращениях;
  • почтового сервера — в нем ведутся записи о входящих и исходящих сообщениях, отклонениях писем.

Записи в системные журналы выполняет установленный софт.

Зачем нужны логи

Анализ логов сервера — неотъемлемая часть работы системного администратора или веб-разработчика. Обрабатывая их, специалисты получают массу полезных сведений. Используются в следующих целях:

  • поиск ошибок и сбоев в работе системы;
  • выявление вредоносной активности;
  • сбор статистики посещения веб-ресурса.

После изучения информации можно получить точную статистику в виде сводных цифр, информацию о юзерах, выявить поведенческие закономерности пользовательских групп.

Где посмотреть логи

Расположение определяется хостинг-провайдером или настройками установленного софта. На виртуальном хостинге доступ к лог-файлам предоставляется из панели управления хостингом. Если администратор не открыл его для владельца сайта, получить информацию не получится. Но большинство провайдеров разрешают свободно пользоваться журналами и проводить анализ логов сервера. Независимо от разновидности сервера лог-файлы хранятся в текстовом документе. По умолчанию он называется access.log, но настройки позволяют переименовать файл. Это актуально для Nginx, Apache, прокси-разновидностей squid, других типов. Для просмотра их надо скачать и открыть в текстовом редакторе. В качестве альтернативы можно использовать Grep и схожие утилиты. Они позволяют открыть и отфильтровать логи прямо на сервере.

Как читать логи. Пример

Существует довольно много форматов записи, combined — один из наиболее распространенных. В нем строчка кода может выглядеть так:

%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"

Директивы имеют следующее значение:

  • %h — IP-адрес, с которого был сделан запрос;
  • %l — длинное имя удаленного хоста;
  • %u — удаленный пользователь, если запрос был сделан аутентифицированным юзером;
  • %t — время запроса к серверу и его часовой пояс;
  • %r — тип и содержимое запроса;
  • %s — код состояния HTTP;
  • %b — количество байт информации, отданных сервером;
  • %{Referer} — URL-источник запроса;
  • %{User-Agent} — HTTP-заголовок.

Еще один пример чтения логов можно посмотреть в статье «Как читать логи сервера».

Опытные веб-мастера для сбора и чтения лог-файлов используют программы-анализаторы. Они позволяют читать логи сервера без значительных временных затрат. Вот некоторые из наиболее востребованных:

  • Analog. Один из самых популярных анализаторов, что во многом объясняется высокой скоростью обработки данных и экономным расходованием системных ресурсов. Хорошо справляется с объемными записями, совместим с любыми ОС.
  • Weblog Expert. Программа доступна в трех вариациях: Lite (бесплатная версия), Professional и Standard (платные релизы). Версии отличаются функциональными возможностями, но каждая позволяет анализировать лог-файлы и создает отчеты в PDF и HTML.
  • SpyLOG Flexolyzer. Простой аналитический инструмент, позволяющий получать отчеты с высокой степенью детализации. Интегрируется c системой статистики SpyLOG, позволяет решать задачи любой сложности.

Логи сервера с ошибками error.log

Это журнал с информацией об ошибках на сайте. В нем можно посмотреть, какие страницы отсутствуют, откуда пришел пользователь с конкретным запросом, имеются ли «битые» ссылки, другие недочеты, включая те, которые не удалось классифицировать. Используется для выявления багов и погрешностей в коде.

Каждая ошибка в логе сервера error.log отображается с новой строки. Идентифицировав и устранив ее, программист сможет наладить работу сайта. Используя журнал, можно выявить и слабые места веб-платформы. Это простой и удобный инструмент анализа, которым должен уметь пользоваться каждый веб-мастер, системный администратор и программист.

Лог файлы Linux по порядку / Хабр

Невозможно представить себе пользователя и администратора сервера, или даже рабочей станции на основе Linux, который никогда не читал лог файлы. Операционная система и работающие приложения постоянно создают различные типы сообщений, которые регистрируются в различных файлах журналов. Умение определить нужный файл журнала и что искать в нем поможет существенно сэкономить время и быстрее устранить ошибку.



Журналирование является основным источником информации о работе системы и ее ошибках. В этом кратком руководстве рассмотрим основные аспекты журналирования операционной системы, структуру каталогов, программы для чтения и обзора логов.


Основные лог файлы

Все файлы журналов, можно отнести к одной из следующих категорий:


  • приложения;
  • события;
  • службы;
  • системный.

Большинство же лог файлов содержится в директории /var/log.


  • /var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
  • /var/log/auth.log или /var/log/secure — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
  • /var/log/dmesg — драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ --level= можно отфильтровать вывод по критерию значимости.
Поддерживаемые уровни журналирования (приоритеты): emerg - система неиспользуемая alert - действие должно быть произведено немедленно crit - условия критичности err - условия ошибок warn - условия предупреждений notice - обычные, но значимые условия info - информационный debug - отладочные сообщения (5:520)$ dmesg -l err [1131424.604352] usb 1-1.1: 2:1: cannot get freq at ep 0x1 [1131424.666013] usb 1-1.1: 1:1: cannot get freq at ep 0x81 [1131424.749378] usb 1-1.1: 1:1: cannot get freq at ep 0x81

  • /var/log/alternatives.log — Вывод программы update-alternatives, в котором находятся символические ссылки на команды или библиотеки по умолчанию.
  • /var/log/anaconda.log — Записи, зарегистрированные во время установки системы.
  • /var/log/audit — Записи, созданные службой аудита auditd.
  • /var/log/boot.log — Информация, которая пишется при загрузке операционной системы.
  • /var/log/cron — Отчет службы crond об исполняемых командах и сообщения от самих команд.
  • /var/log/cups — Все, что связано с печатью и принтерами.
  • /var/log/faillog — Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog.
  • var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
  • /var/log/maillog/ или /var/log/mail.log — Журнал почтового сервера, используемого на ОС.
  • /var/log/pm-powersave.log — Сообщения службы экономии заряда батареи.
  • /var/log/samba/ — Логи файлового сервера Samba, который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
  • /var/log/spooler — Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
  • /var/log/Xorg.0.log — Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.

Для каждого дистрибутива будет отдельный журнал менеджера пакетов.


  • /var/log/yum.log — Для программ установленных с помощью Yum в RedHat Linux.
  • /var/log/emerge.log — Для ebuild-ов установленных из Portage с помощью emerge в Gentoo Linux.
  • /var/log/dpkg.log — Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.

И немного бинарных журналов учета пользовательских сессий.


  • /var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой last.
  • /var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2.
  • /var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
  • /var/log/utmp — Список входов пользователей в систему на данный момент.
  • /var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump.
(5:535)$ sudo utmpdump /var/log/wtmp [5] [02187] [l0 ] [ ] [4.0.5-gentoo ] [0.0.0.0 ] [Вт авг 11 16:50:07 2015] [1] [00000] [~~ ] [shutdown] [4.0.5-gentoo ] [0.0.0.0 ] [Вт авг 11 16:50:08 2015] [2] [00000] [~~ ] [reboot ] [3.18.12-gentoo ] [0.0.0.0 ] [Вт авг 11 16:50:57 2015] [8] [00368] [rc ] [ ] [3.18.12-gentoo ] [0.0.0.0 ] [Вт авг 11 16:50:57 2015] [1] [20019] [~~ ] [runlevel] [3.18.12-gentoo ] [0.0.0.0 ] [Вт авг 11 16:50:57 2015]

И другие журналы

Так как операционная система, даже такая замечательная как Linux, сама по себе никакой ощутимой пользы не несет в себе, то скорее всего на сервере или рабочей станции будет крутится база данных, веб сервер, разнообразные приложения. Каждое приложения или служба может иметь свой собственный файл или каталог журналов событий и ошибок. Всех их естественно невозможно перечислить, лишь некоторые.


  • /var/log/mysql/ — Лог базы данных MySQL.
  • /var/log/httpd/ или /var/log/apache2/ — Лог веб сервера Apache, журнал доступа находится в access_log, а ошибки — в error_log.
  • /var/log/lighthttpd/ — Лог веб сервера lighttpd.

В домашнем каталоге пользователя могут находится журналы графических приложений, DE.


  • ~/.xsession-errors — Вывод stderr графических приложений X11.
Initializing "kcm_input" : "kcminit_mouse" Initializing "kcm_access" : "kcminit_access" Initializing "kcm_kgamma" : "kcminit_kgamma" QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0 kf5.kcoreaddons.kaboutdata: Could not initialize the equivalent properties of Q*Application: no instance (yet) existing. QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0 Qt: Session management error: networkIdsList argument is NULL

  • ~/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

Чем просматривать — lnav

Почти все знают об утилите less и команде tail -f. Также для этих целей сгодится редактор vim и файловый менеджер Midnight Commander. У всех есть свои недостатки: less неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор vim понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью <:view /path/to/file>.

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.



Установка пакета как обычно одной командой.

$ aptitude install lnav #Debian/Ubuntu/LinuxMint $ yum install lnav #RedHat/CentOS $ dnf install lnav #Fedora $ emerge -av lnav #Gentoo, нужно добавить в файл package.accept_keywords $ yaourt -S lnav #Arch

Навигатор журналов lnav понимает ряд форматов файлов.


  • Access_log веб сервера.
  • CUPS page_log
  • Syslog
  • glog
  • dpkg.log
  • strace
  • Произвольные записи с временными отметками
  • gzip, bzip
  • Журнал VMWare ESXi/vCenter

Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.

(5:471)$ sudo lnav /var/log/pm-powersave.log /var/log/pm-suspend.log

Программа умеет напрямую открывать архивный файл.

(5:471)$ lnav -r /var/log/Xorg.0.log.old.gz

Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу <i>. Это с моего syslog-а.

Mon May 02 20:25:00 123 normal 3 errors 0 warnings 0 marks Mon May 02 22:40:00 2 normal 0 errors 0 warnings 0 marks Mon May 02 23:25:00 10 normal 0 errors 0 warnings 0 marks Tue May 03 07:25:00 96 normal 3 errors 0 warnings 0 marks Tue May 03 23:50:00 10 normal 0 errors 0 warnings 0 marks Wed May 04 07:40:00 96 normal 3 errors 0 warnings 0 marks Wed May 04 08:30:00 2 normal 0 errors 0 warnings 0 marks Wed May 04 10:40:00 10 normal 0 errors 0 warnings 0 marks Wed May 04 11:50:00 126 normal 2 errors 1 warnings 0 marks

Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь lnav будет активно развиваться, очень полезная программа на мой взгляд.


Использованные материалы

  1. lnav — An Advanced Log File viewer for Linux
  2. What Are Linux Logs? How to View Them, Most Important Directories, and More
  3. Как посмотреть логи в Linux

Операции резервного копирования, усечения и сжатия журнала транзакций SQL Server

В этой статье мы рассмотрим операции резервного копирования журналов транзакций SQL Server, операции усечения и сжатия с обзором и примерами, охватывающими все обсуждаемое.

Если эта статья является вашим первым посещением серии журналов транзакций SQL Server, я рекомендую вам ознакомиться с предыдущими статьями (см. Оглавление ниже), в которых мы описали внутреннюю структуру журнала транзакций SQL Server, важную роль, которую выполняет транзакция. Журнал играет в поддержании базы данных в согласованном состоянии и восстановлении поврежденной базы данных или ошибочно измененной таблицы до определенного момента времени.Мы также обсудили в этой серии три модели восстановления: полное, простое и с неполным протоколированием, которые контролируют, как транзакции будут записываться в файл журнала транзакций SQL Server, и, наконец, как управлять ростом журнала транзакций SQL Server и отслеживать его.

Основываясь на всей базовой информации из предыдущих статей, мы готовы подробно обсудить в этой статье разницу между концепциями резервного копирования, усечения и сжатия журнала транзакций SQL Server и способы выполнения этих операций.

Резервное копирование журнала транзакций

При настройке базы данных с использованием модели простого восстановления журнал транзакций SQL Server будет помечен как неактивный и автоматически усечен после фиксации активной транзакции. Это не относится к моделям восстановления базы данных с полным и неполным протоколированием. Когда для базы данных настроена модель полного восстановления, журнал транзакций SQL Server в файле журнала транзакций будет помечен как неактивный после фиксации транзакции без автоматического усечения, так как это будет , ожидающее выполнения резервного копирования журнала транзакций .Напомним, что только резервная копия журнала транзакций, но НЕ полная резервная копия базы данных, будет усекать журналы транзакций из файла журнала транзакций и делать его доступным для повторного использования. Если из базы данных не берется резервная копия журнала транзакций, файл журнала транзакций будет постоянно увеличиваться без усечения, пока в нем не закончится свободное пространство.

Резервная копия журнала транзакций SQL Server может быть сделана только из базы данных, если модель восстановления этой базы данных является полной или с неполным протоколированием.Модель восстановления базы данных можно проверить на вкладке Options окна Database Properties, как показано ниже:

Если вы попытаетесь сделать резервную копию журнала транзакций для базы данных, для которой настроена модель простого восстановления, операция резервного копирования завершится сбоем с сообщением об ошибке ниже:

Кроме того, для резервного копирования журнала транзакций требуется, чтобы из этой базы данных была взята хотя бы одна полная резервная копия в качестве начальной точки для новой цепочки резервных копий.Если вы попытаетесь сделать резервную копию журнала транзакций из базы данных, в которой ранее не было выполнено полное резервное копирование, операция резервного копирования завершится сбоем с сообщением об ошибке ниже:

Давайте сделаем полную резервную копию базы данных, чтобы иметь возможность делать резервную копию журнала транзакций для этой базы данных. Мы будем использовать команду T-SQL BACKUP DATABASE для выполнения операции полного резервного копирования базы данных в нашем примере. Дополнительные сведения о различных способах и вариантах выполнения резервного копирования базы данных в SQL Server см. В серии «Резервное копирование и восстановление SQL Server».Полную резервную копию базы данных можно сделать с помощью сценария T-SQL ниже:

РЕЗЕРВНАЯ БАЗА ДАННЫХ [TSQL]

НА ДИСК = N'C: \ Ahmad Yaseen \ TSQL.bak 'WITH NOFORMAT, NOINIT,

NAME = N'TSQL-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, СТАТИСТИКА = 10

GO

После того, как будет выполнено полное резервное копирование базы данных, мы начнем резервное копирование журнала транзакций для базы данных.Первая резервная копия журнала транзакций создаст резервную копию всех транзакций, произошедших в базе данных с момента последней полной резервной копии. Резервную копию журнала транзакций можно сделать с помощью команды T-SQL BACKUP LOG ниже:

РЕЗЕРВНЫЙ ЖУРНАЛ [TSQL]

НА ДИСК = N'C: \ Ahmad Yaseen \ TSQL_2.TRN 'WITH NOFORMAT, NOINIT,

NAME = N'TSQL-TRN Database Backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, СТАТИСТИКА = 10

GO

С другой стороны, резервные копии журнала транзакций, которые следует за , первая резервная копия журнала транзакций будет создавать резервные копии для всех транзакций, которые произошли в базе данных с момента остановки последнего резервного копирования журнала транзакций.Полная резервная копия и все последующие резервные копии журнала транзакций до создания новой полной резервной копии называются Backup Chain . Эта цепочка резервного копирования важна для восстановления базы данных до определенного момента времени в случае любого ошибочно выполненного изменения или повреждения базы данных. Частота резервного копирования журнала транзакций зависит от того, насколько важны ваши данные, размер базы данных и какой тип рабочей нагрузки эта база данных обслуживает. В базах данных с большим количеством транзакций рекомендуется увеличить частоту резервного копирования журнала транзакций, чтобы минимизировать потерю данных, и усечь журналы транзакций, чтобы сделать их доступными для повторного использования.

Если база данных повреждена, рекомендуется создать резервную копию хвостового журнала, чтобы вы могли восстановить базу данных на текущий момент времени. Резервная копия журнала используется для сохранения всех записей журнала, для которых еще не было выполнено резервное копирование. Это поможет предотвратить потерю данных и сохранить целостность цепочки журналов.

Предположим, что вы по ошибке выполнили приведенную ниже инструкцию DELETE, не указав предложение WHERE. Это означает, что все записи таблицы будут удалены:

Если вы разработали подходящее решение для резервного копирования, данные можно легко восстановить, восстановив базу данных до определенного момента времени перед выполнением оператора DELETE.В окне «Восстановить базу данных» SQL Server вернет полную цепочку резервных копий, взятую из этой базы данных. Если вы знаете точный файл, который берется непосредственно перед удалением данных, вы можете остановиться на этом конкретном файле, как показано ниже:

Но если вам известно точное время выполнения оператора DELETE, вы можете восстановить базу данных обратно в этот конкретный момент времени до выполнения оператора DELETE, без необходимости знать, какой файл журнала транзакций содержит этот момент времени.Этого можно добиться, щелкнув опцию Timeline и указав время, как показано ниже:

Усечение журнала транзакций

Усечение журнала транзакций SQL Server - это процесс, в котором все VLF, помеченные как неактивные, будут удалены из файла журнала транзакций SQL Server и станут доступны для повторного использования. Если в VLF имеется одна активная запись журнала , общий VLF будет считаться активным журналом и не может быть усечен.

Журнал транзакций SQL Server для базы данных, настроенной с использованием модели восстановления Simple , может быть автоматически усечен, если:

  • Сработал оператор контрольной точки
  • Транзакция базы данных зафиксирована

Журнал транзакций SQL Server для базы данных, для которой настроена модель восстановления Full или Bulk-Logged , может быть усечен автоматически:

  • После выполнения процесса резервного копирования журнала транзакций, когда журнал транзакций не ожидает активной транзакции или какой-либо функции высокой доступности, такой как зеркалирование, репликация или группа доступности AlwaysOn

  • Измените модель восстановления базы данных на Simple
    Например, если мы изменим модель восстановления указанной ниже базы данных на Простую и выполним контрольную точку напрямую, журнал транзакций будет автоматически усечен и будет доступен для повторного использования, как показано ниже:

  • TRUNCATE_ONLY Параметр резервного копирования журнала транзакций, который разрывает цепочку резервного копирования базы данных и усекает доступные журналы транзакций.(Доступно только до SQL Server 2008.)
    Если вы попытаетесь усечь журнал транзакций базы данных с помощью параметра TRUNCATE_ONLY в экземпляре SQL Server версии 2008 и более поздних версий, выполнение инструкции завершится ошибкой, и появится следующее сообщение об ошибке:

Уменьшение журнала транзакций

Когда файл журнала транзакций базы данных усекается, усеченное пространство освобождается и становится доступным для повторного использования.Но размер файла журнала транзакций не будет уменьшен, так как усеченное пространство не будет освобождено. С другой стороны, процесс восстановления пространства журнала транзакций путем освобождения свободных VLF и возврата их обратно в операционную систему называется сжатием журнала транзакций . операция.

Операция сжатия файла журнала транзакций может выполняться только при наличии свободного места в файле журнала транзакций, которое может быть доступно большую часть времени после усечения неактивной части журнала транзакций.Операция сжатия будет полезна после выполнения операции, которая создает большое количество журналов транзакций.

Файл журнала транзакций базы данных можно уменьшить, щелкнув правой кнопкой мыши базу данных и выбрав параметр «Сжать» -> «Файлы» в меню «Задачи», как показано ниже:

На странице Shrink File измените Тип файла на Log и выберите файл журнала транзакций, который вы хотите сжать. На этой странице у вас есть три варианта:

Тот же файл журнала транзакций можно сжать с помощью инструкции DBCC SHRINKFILE T-SQL ниже:

ИСПОЛЬЗОВАТЬ [AdventureWorks2016CTP3]

GO

DBCC SHRINKFILE (N'AdventureWorks2016CTP3_Log ', 0, TRUNCATEONLY)

GO

Сжать файл журнала транзакций до размера, меньшего, чем размер виртуального файла журнала, невозможно, даже если это пространство не используется.Это связано с тем, что файл журнала транзакций можно сжать только до границы VLF. В этом случае ядро ​​СУБД SQL Server освободит как можно больше места, а затем выдаст информационное сообщение, как показано ниже:

В следующей статье этой серии мы обсудим лучшие практики, которые следует применять к журналу транзакций, чтобы получить от него оптимальную производительность. Оставайтесь в курсе!

Содержание

Ахмад Ясин (Ahmad Yaseen) - инженер Microsoft по большим данным с глубокими знаниями и опытом в областях SQL BI, администрирования баз данных SQL Server и разработки.

Он является сертифицированным специалистом по решениям Microsoft в области управления данными и аналитикой, сертифицированным партнером по решениям Microsoft в области администрирования и разработки баз данных SQL, партнером разработчика Azure и сертифицированным инструктором Microsoft.

Кроме того, он вносит свои советы по SQL во многие блоги.

Посмотреть все сообщения от Ahmad Yaseen

Последние сообщения от Ahmad Yaseen (посмотреть все) .

Какая команда выполняет усечение файла журнала SQL Server?

Переполнение стека
  1. Около
  2. Продукты
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи
.

Очистить или усечь файл журнала в Linux [4 способа]

Вы окажетесь в ситуации, когда вам нужно очистить файл. Это часто случается, когда у вас огромные файлы журналов, и как бы вы это сделали?

Один из не очень простых способов - удалить файл, а затем создать новый. Но это плохая идея. Это не будет тот же файл, отметка времени (atime, mtime и т. Д.) Будет отличаться от других прав доступа к файлу.

Вместо создания нового пустого файла вы можете удалить его содержимое.Итак, как очистить файл в Linux? Как очистить файл от всего его содержимого, не удаляя сам файл?

4 способа очистить файл в Linux

Есть несколько способов очистить файл без фактического удаления файла. Позвольте мне показать вам некоторые из этих методов.

Метод 1. Усечение файла с помощью команды усечения

Самый безопасный способ усечения файла журнала - это использование команды усечения. 

  truncate -s 0 filename

В приведенной выше команде -s используется для установки / корректировки размера (в байтах) файла.Когда вы используете -s 0, это означает, что вы установили размер файла на 0 байт. В

Метод 2: Пустой файл с помощью:> или>

Самый простой способ очистить файл - использовать команду ниже. Если файл не используется, он будет работать в Bash: 

 > filename

Хотя вышеуказанное работает только в Bash Shell, вы можете использовать аналогичную команду для других оболочек: 

 :> filename

Вы также можете использовать эту команду для очистки файла: 

  true> filename

Метод 3: Использование команды echo для очистки файла в Linux

Другой способ очистить файл - с помощью команды echo в Linux: 

  echo > filename

Вы также можете использовать команду echo следующим образом: 

  echo ""> filename

Метод 4: Используйте / dev / null для очистки файла

Вы также можете использовать известный / dev / null и объединитесь с командой cat, чтобы очистить файл журнала: 

  cat / dev / null> file.log

В конце…

И если у вас недостаточно прав для выполнения какой-либо из вышеперечисленных команд, это верный, но немного грязный способ его достижения: 

  touch newfile mv newfile filename

Надеюсь, этот быстрый совет помог вам очистить файл в Linux. Добавьте нас в закладки для получения дополнительных советов по Linux.

.

Как обрезать файл журнала в SQL Server 2005

Введение

SQL Server 2005 сильно отличается от SQL Server 2000. Обрезка файла журнала - это одно отличие от SQL Server 2000. В SQL Server 2000 вы просто используете сжатие до любого размера файла, который вам нравится. В SQL Server 2005 иногда я вообще не могу сжать файл журнала.

Здесь я хочу описать некоторые приемы по усечению файла журнала для базы данных в SQL Server 2005. Рабочая среда - Microsoft SQL Server Management Studio.

I. Уменьшайте размер файла журнала в нужное время

Я обнаружил этот трюк:

Сразу после того, как я использую пакет SSIS или импортирую данные в базу данных ( выделите базу данных-> Задачи-> Импортировать данные… ), или экспортирую данные из базы данных ( выделите базу данных-> Задачи-> Экспорт данных … ), я могу сжать файл журнала до желаемого размера, например 1 МБ. То есть выделить базу данных-> Задачи-> Сжать-> Файлы , установить размер файла, скажем, 1МБ.

Затем нажмите ОК, и все готово.

II. Полностью удалить файл журнала

Иногда нам просто не нужен большой файл журнала. Например, у меня есть файл журнала размером 40 ГБ. Я уверен, что мне не нужен этот файл журнала, и я хочу полностью избавиться от него, чтобы освободить место на жестком диске. Логика:

  1. Отсоединить базу данных
  2. Переименовать файл журнала
  3. Присоединить базу данных без файла журнала
  4. Удалить файл журнала

Допустим, имя базы данных - testDev .В SQL Server Management Studio,

  1. Выделите базу данных-> Задачи-> Отсоединить ..-> Нажмите ОК
  2. Перейдите в папку с файлом журнала -> переименуйте файл testDev_log.ldf в testDev_log-aa.ldf
  3. Выделите Базы данных-> Присоединить… -> Нажмите Добавить -> добавьте базу данных testDev , выделите файл журнала и нажмите кнопку « Удалить» . Это означает, что вы подключаете только testDev.mdf
  4. После этого вы можете проверить содержимое присоединенной базы данных, а затем удалить файл журнала

Таким образом мы можем безопасно удалить файл журнала и освободить место.

Если вы считаете, что это очень полезно, оставьте, пожалуйста, свои комментарии в Интернете. Если у вас есть вопросы или предложения, напишите мне по адресу [email protected].

Счастливого SQL!

История

  • 9 -е Июнь 2006 г .: Начальная должность
.

Как обрезать журналы без резервной копии

В этом руководстве мы объясняем, как очистить журналы Microsoft Exchange. Это полезно в том случае, если у вас заканчивается место на диске для хранения журналов и нет возможности создать полную регулярную резервную копию.

Microsoft Exchange Server использует метод упреждающей записи для фиксации новых данных в базе данных. Это означает, что когда вы создаете новые элементы Exchange (электронные письма, события календаря и т. Д.), Данные записываются в файл журнала. Через некоторое время эти журналы фиксируются в базе данных, а Exchange усекает журналы, помечая их как пригодные для повторного использования.

Эти файлы журнала занимают место для хранения. Обычно журналы усекаются (что делает их короче и экономит место) всякий раз, когда вы запускаете полную резервную копию Exchange. Однако иногда невозможно запустить полное резервное копирование. К счастью, все еще можно обрезать журналы Exchange для экономии места.

Зачем нужно обрезать журналы Exchange без резервного копирования?


Выполнение усечения журнала транзакций вручную позволяет поддерживать стабильность вашей среды в следующих ситуациях:
  • Программному обеспечению резервного копирования не удалось выполнить задание резервного копирования, и журналы остаются нетронутыми.Вы можете быть вынуждены уменьшить объем памяти, занимаемый журналами Exchange, если вам нужно дополнительное время для обнаружения проблемы.
  • Если вы запустите тестовую среду Exchange, вы можете сэкономить место для хранения, удалив ненужные файлы журналов. Microsoft предлагает использовать циклическое ведение журнала для этого сценария, но у вас могут быть причины не делать этого.

Мы настоятельно не рекомендуем использовать циклическое ведение журнала, поскольку в случае выхода из строя диска хоста вы сможете восстановить данные только до точки последней резервной копии.Все последующие изменения будут потеряны. Вы должны удалять файлы журналов вручную только в ужасной ситуации или при работе в непроизводственной среде.

Дополнительные материалы для чтения Microsoft Exchange: экспорт почтовых ящиков в PST

Помните, что вы не можете выполнить инкрементное резервное копирование Exchange Server, если журналы транзакций были удалены вручную.

БЕСПЛАТНАЯ БЕЛАЯ БУМАГА

Окончательное руководство MSP по резервному копированию и восстановлению MS Exchange Server

Советы, приемы и передовые методы

Как вручную усечь журналы Exchange

Существует три основных способа усечения файлов журналов Exchange вручную:

  • [Не требует размонтирования БД] Смоделируйте процесс резервного копирования с помощью записывающего устройства VSS.Это похоже на стандартный сценарий резервного копирования, но на самом деле вы не собираете данные и не дожидаетесь завершения резервного копирования.
  • [Требуется отключение базы данных] Отключите базу данных, чтобы инициировать фиксацию всех оставшихся журналов, затем удалите файлы журналов вручную.
  • [Не требует демонтажа БД] , потенциально опасен. Использование проводника для удаления файлов журнала, которые вы наверняка зафиксировали.

Теперь давайте подробно рассмотрим каждый из этих методов.

Моделирование резервного копирования для инициирования усечения журналов Exchange

Это самый простой подход, и он работает, пока на вашем сервере Exchange нет ошибок, связанных с VSS. В принципе, вы можете запустить моделирование резервного копирования, если ранее не сталкивались с какими-либо ошибками, связанными с резервным копированием, на сервере, включая сторонние инструменты резервного копирования.

  • Откройте консоль CMD с повышенными привилегиями (другими словами, запустите от имени администратора), а затем введите следующую команду: Diskshadow
  • Затем вам нужно добавить тома диска, в которых хранится база данных и журналы Exchange: добавить том C:
    Мы предполагаем, что «C:» - это единственный системный диск, содержащий все данные сервера.
  • Создайте сеанс резервного копирования: начать резервное копирование
  • И затем запустите VSS Writer с помощью команды: create
  • После того, как VSS подготовит том, вы увидите что-то похожее на снимок экрана ниже:
  • Чтобы сказать Exchange, что имитация резервного копирования была завершена, запустите эту команду: end backup
  • Если это моделированное резервное копирование было успешно завершено и распознано сервером Exchange, вы увидите событие с идентификатором 9780 в средстве просмотра событий Windows:

Теперь ваши файлы журналов будут безопасно обрезаны после создания следующего файла журнала.

Удаление журналов вручную после отключения базы данных

Exchange обычно фиксирует все оставшиеся файлы журналов при выполнении процедуры отключения базы данных. Таким образом, это позволяет вам убедиться, что файлы журнала, которые вы хотите удалить, уже находятся в базе данных. Вы можете выполнить эту процедуру, выполнив следующие действия:

1 Откройте консоль управления Exchange и перейдите в раздел «Конфигурация организации - Почтовый ящик».

2 Выберите базу данных, которая содержит файлы журнала, которые вы хотите удалить, и выберите Dismount Database в контекстном меню:

3 Этот шаг не является обязательным - он просто гарантирует, что база данных была разобрался без проблем .Откройте консоль CMD и введите следующую команду:

eseutil / mh

4 Замените « Path_to_.EDB_file» на полный путь к вашей базе данных. Это легко сделать, перетащив файл «.EDB» из проводника файлов в окно CMD.

5 Если база данных была успешно отключена, вы увидите состояние «Чистое выключение» в выходных данных команды:

6 Теперь можно безопасно удалить все файлы журнала, связанные с этой базой данных, с помощью проводника. .Затем вы можете просто подключить базу данных с помощью консоли управления Exchange - Конфигурация организации - Почтовый ящик.

Удаление журналов вручную БЕЗ размонтирования базы данных

Это наиболее опасный подход, поскольку он не дает возможности проверить, действительно ли удаленные журналы были зафиксированы в базе данных, перед их удалением. Вместо этого мы просто предполагаем, что Exchange зафиксировал все файлы журналов старше нескольких дней после даты создания.

Используйте этот подход, только если:

  • Вы не можете выполнить моделирование резервного копирования VSS, используя первый подход, описанный выше.
  • Нет абсолютно никакого способа отключить базу данных для фиксации всех журналов.
  • Вам не нужно беспокоиться о потере данных, созданных с момента последнего полного резервного копирования.

Вот как удалить файлы журнала без отключения базы данных:

1 Откройте проводник и перейдите в папку, содержащую вашу базу данных:

2 Теперь вам нужно отсортировать содержимое папки по дате . Щелкните столбец «Дата изменения»:

3 Выберите все файлы LOG старше N дней и удалите их.Чем выше значение N, тем меньше вероятность повреждения данных. Мы предлагаем выбрать минимум одну неделю.

4 Вы можете проверить состояние целостности своей базы данных, выполнив команду eseutil / mh , которая работает только после отключения базы данных.

Заключение

Мы предоставили советы о том, как вручную обрезать журналы Exchange, чтобы избежать нехватки места для хранения. Описанные выше подходы не рекомендуется использовать в повседневной жизни; это решения для аварийного восстановления, которые полезны в случае, если что-то пойдет не так.

Конечно, всегда лучше избежать проблемы, чем бороться с ее последствиями после ее возникновения. Вот почему мы предлагаем реализовать резервное копирование Exchange с помощью Windows Server Backup или сторонних решений с поддержкой Exchange.

# 1 Business Backup. Просто. Надежный.

Используйте AWS, Wasabi, Backblaze B2 и локальное хранилище. Устранение дорогостоящих инвестиций в оборудование. Улучшение целевого времени восстановления.

.

Усечение файла журнала с использованием C # через формы

Переполнение стека
  1. Около
  2. Продукты
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд
.

Смотрите также