Не удалось зафиксировать файл базы данных для открытия или изменения

Обновлено: 01.07.2024

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

Редактор таблиц накапливает все внесенные вами изменения. Когда вы нажимаете кнопку Submit and Commit (), DataGrip отправляет эти изменения в базу данных. В базе данных изменения обрабатываются в соответствии с выбранным режимом фиксации:

При использовании Tx:Auto база данных сама фиксирует все изменения.

При использовании Tx:Manual изменения сохраняются в транзакции в базе данных. Когда вы нажимаете Submit и Commit(), транзакции фиксируются в базе данных. Когда вы фиксируете транзакцию, значок «Отправить и подтвердить» () отключается (затеняется). Это означает, что все транзакции были зафиксированы.

Если режим фиксации установлен на Auto , каждое изменение значений, строк или столбцов неявно фиксируется и не может быть отменено. В режиме автоматической фиксации кнопки «Отправить», «Подтвердить» и «Откат» отключены.

Если для режима фиксации установлено значение «Вручную», вы можете явно подтвердить или отменить отправленные изменения, нажав кнопки «Отправить» и «Подтвердить» или «Откатить». Чтобы отправить изменения в базу данных, нажмите кнопку «Отправить» .

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

Отправить изменения вручную

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

Чтобы отправить изменения в базу данных, щелкните значок "Отправить" () или нажмите Ctrl+Enter .

Отправлять изменения автоматически

По умолчанию изменения не отправляются в базу данных, пока вы не нажмете значок "Отправить" или не нажмете Ctrl+Enter . Вы можете включить параметр «Отправить изменения немедленно», чтобы ваши изменения отправлялись автоматически.

В настройках Ctrl+Alt+S перейдите к базе данных | Редактор данных и средство просмотра .

Выберите «Отправить изменения немедленно» в разделе «Изменение данных» .

Выберите режим транзакций по умолчанию для источника данных

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

Перейти к файлу | Источники данных.

В обозревателе баз данных ( Вид | Окна инструментов | Обозреватель баз данных ) щелкните значок Свойства источника данных .

В списке созданных источников данных щелкните источник данных, который вы хотите изменить.

Перейдите на вкладку "Параметры".

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

Выбранный элемент управления транзакциями применяется к новым консолям запросов.

Отменить изменения

Прежде чем отправлять изменения, вы можете отменить их.

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

Чтобы отменить неотправленные изменения, выберите и щелкните правой кнопкой мыши ячейку или несколько ячеек. Выберите Вернуть выбранное Ctrl+Alt+Z .

Разрешение конфликтов при отправке изменений

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

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

Используйте кнопку Игнорировать (), чтобы отклонить изменение. Или кнопки «Принять» ( или ), чтобы применить изменения на левой или правой панели. На средней панели показан результат операции слияния.

Нажмите Сохранить изменения и завершить объединение .

Советы по продуктивности

Отображать предупреждение при изменении устаревшего фрагмента кода DDL

Чтобы убедиться, что вы не удаляете чью-либо работу, отправляя устаревший объект, включите параметр Предупреждать при редактировании устаревшего DDL.

В обозревателе баз данных ( Вид | Окна инструментов | Обозреватель баз данных ) щелкните правой кнопкой мыши источник данных и выберите "Свойства" .

В диалоговом окне "Источники данных и драйверы" перейдите на вкладку "Параметры".

В разделе "Самоанализ" установите флажок "Предупреждать при изменении устаревшего DDL".

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

попытка записи базы данных только для чтения

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

не удается открыть файл базы данных

Если это будет полезно, вот весь вывод:

Сообщите мне, нужна ли трассировка стека.

9 ответов 9

Ага, только что наткнулся на статью, объясняющую это. Также у Django есть информация на странице NewbieMistakes.

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

В моем случае запуск этой команды устранил проблему:

Это предполагает, что вы используете Debian/Ubuntu, если вы используете CentOS, вы захотите использовать 'apache' вместо 'www-data'

@nbolton Примечание: chown www-data. . на самом деле должно быть выбрано www-data . в противном случае есть какое-то волшебство команды chown, о котором я не знаю. просветите меня.

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

Обобщая здесь, в случае будущей гниения ссылки или tl;dr: SQLite3 хочет получить доступ на запись к каталогу файла БД, чтобы он мог создать там файл журнала при открытии транзакции.

Мое решение было похоже на это. Я действительно не хотел менять владельца этого каталога. (в основном потому, что я использую пользователя pi для таких вещей, как git)

(или любую базу данных, которую вы используете)

где pi — это пользователь, под которым я создал все файлы. (да, это raspberry pi)

Я обнаружил, что вместо изменения разрешений на www-данные мне нужно изменить только следующие разрешения:

Это дает группе доступ на запись к необходимым файлам и добавляет пользователя www-data в группу pi.

Примечание: если у вас есть ведение журнала, вам нужно будет сделать это и для файла журнала django, иначе apache это не очень понравится.

Эта статья поможет вам решить проблему, возникающую при попытке обновить таблицу с помощью SQL Server Management Studio в SQL Server.

Исходная версия продукта: SQL Server
Исходный номер базы знаний: 925719

Симптомы

Рассмотрите следующий сценарий. Вы пытаетесь использовать SQL Server Management Studio для обновления таблицы в Microsoft SQL Server. В обозревателе объектов щелкните правой кнопкой мыши имя таблицы и выберите команду Открыть таблицу. Вы обновляете строку таблицы. В этом случае вы можете неожиданно получить одно из следующих сообщений об ошибке в диалоговом окне Microsoft SQL Server Management Studio:

Сообщение об ошибке 1

Данные изменились с момента последнего извлечения панели результатов. Сохранить изменения сейчас?

(Ошибка управления оптимистичным параллелизмом)

Нажмите «Да», чтобы все равно зафиксировать изменения в базе данных.

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

Нажмите «Отмена», чтобы продолжить редактирование.

Если нажать кнопку "Да" в этом диалоговом окне сообщения об ошибке, строка будет обновлена правильно.

Сообщение об ошибке 2

Ни одна строка не была обновлена.

Данные в строке X не были зафиксированы.

Источник ошибки: Microsoft.VisualStudio.DataTools.

Сообщение об ошибке: Обновленные или удаленные значения строки либо не делают строку уникальной, либо изменяют несколько строк (N строк).

Исправьте ошибки и повторите попытку или нажмите ESC, чтобы отменить изменения. ).

Если вы видите это диалоговое окно с сообщением, вы не можете обновить строку.

Эта проблема возникает, если выполняются следующие условия:

Таблица содержит один или несколько столбцов с типом данных text или ntext.

Значение одного из этих столбцов содержит следующие символы:

Знак процента (%)
Подчеркивание (_)
Левая квадратная скобка ([)

Таблица не содержит первичного ключа.

Эта проблема также возникает при попытке использовать конструктор таблиц в Microsoft Visual Studio для обновления таблицы в базе данных SQL Server.

Причина

Эта проблема возникает из-за того, что SQL Server Management Studio создает неверный оператор SQL для операции обновления. Если таблица не содержит первичного ключа, значения всех столбцов используются для определения обновляемой строки. Когда SQL Server Management Studio создает этот оператор, неверный оператор сравнения (=) используется для сравнения столбцов типов данных text, ntext или image.

Временное решение

Чтобы обойти эту проблему, создайте новое окно запроса в SQL Server Management Studio. Затем выполните оператор SQL UPDATE, чтобы обновить строку в таблице.

Если вы получили первое сообщение об ошибке, упомянутое в разделе "Проблемы", вы можете нажать "Да", чтобы обновить строку.

Прежде чем пытаться открыть эту записную книжку, убедитесь, что Azure Data Studio установлена на вашем локальном компьютере. Чтобы установить, перейдите к разделу Узнайте, как установить Azure Data Studio.

Вариант 2. Выполните шаг вручную

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

Когда журнал транзакций заполняется, компонент SQL Server Database Engine выдает ошибку 9002. Журнал может заполняться, когда база данных подключена к сети или находится в процессе восстановления. Если журнал заполняется, когда база данных находится в сети, база данных остается в сети, но ее можно только читать, но не обновлять. Если журнал заполняется во время восстановления, компонент Database Engine помечает базу данных как RESOURCE PENDING. В любом случае требуется действие пользователя, чтобы освободить место для журнала.

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

Распространенные причины полного журнала транзакций

Правильный ответ на полный журнал транзакций зависит от того, какие условия вызвали заполнение журнала. Общие причины включают:

Журнал не усекается
Диск заполнен
Размер журнала установлен на фиксированное максимальное значение или автоматическое увеличение отключено
Репликация или синхронизация группы доступности не может быть завершена

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

Следующие конкретные шаги помогут вам найти причину полного журнала транзакций и решить проблему.

1. Сократить журнал

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

Объяснение усечения журнала

Существует разница между усечением журнала транзакций и сжатием журнала транзакций. Усечение журнала обычно происходит во время резервного копирования журнала транзакций и является логической операцией, которая удаляет зафиксированные записи внутри журнала, тогда как сжатие журнала высвобождает физическое пространство в файловой системе за счет уменьшения размера файла. Усечение журнала происходит на границе виртуального файла журнала (VLF), а файл журнала может содержать много файлов VLF. Файл журнала можно уменьшить только в том случае, если внутри файла журнала есть пустое место для восстановления. Само по себе сжатие файла журнала не может решить проблему полного файла журнала, вместо этого вы должны выяснить, почему файл журнала заполнен и не может быть усечен.

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

Что препятствует усечению журнала?

Чтобы выяснить, что мешает усечению журнала в данном случае, используйте столбцы log_reuse_wait и log_reuse_wait_desc представления каталога sys.databases. Дополнительные сведения см. в разделе sys.databases (Transact-SQL). Описание факторов, которые могут задержать усечение журнала, см. в разделе Журнал транзакций (SQL Server).

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

Если база данных находилась в процессе восстановления на момент возникновения ошибки 9002, после устранения проблемы восстановите базу данных с помощью команды ALTER DATABASE database_name SET ONLINE.

LOG_BACKUP log_reuse_wait

Наиболее распространенные действия, которые вы можете здесь рассмотреть, – это просмотр модели восстановления вашей базы данных и создание резервной копии журнала транзакций вашей базы данных.

Рассмотрите модель восстановления базы данных

Возможно, журнал транзакций не усекается с категорией LOG_BACKUP log_reuse_wait, поскольку вы никогда не создавали его резервную копию. Во многих из этих случаев ваша база данных использует модель восстановления FULL или BULK_LOGGED, но вы не создали резервные копии журналов транзакций. Вы должны внимательно рассмотреть каждую модель восстановления базы данных: выполните резервное копирование журналов транзакций для всех баз данных в моделях восстановления FULL или BULK LOGGED, чтобы свести к минимуму возникновение ошибки 9002. Дополнительные сведения см. в разделе Модели восстановления.

Создать резервную копию журнала

В модели восстановления FULL или BULK_LOGGED, если журнал транзакций недавно не создавался, резервное копирование может предотвратить усечение журнала. Вы должны сделать резервную копию журнала транзакций, чтобы разрешить выпуск записей журнала и усечение журнала. Если журнал никогда не копировался, необходимо создать две резервные копии журнала, чтобы компонент Database Engine мог обрезать журнал до точки последней резервной копии.Усечение журнала освобождает логическое пространство для новых записей журнала. Чтобы журнал не заполнялся снова, делайте резервные копии журнала регулярно и чаще. Дополнительные сведения см. в разделе Модели восстановления.

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

Полная история всех операций резервного копирования и восстановления SQL Server на экземпляре сервера хранится в системной базе данных msdb. Дополнительные сведения об истории резервного копирования см. в разделе Журнал резервного копирования и сведения о заголовках (SQL Server).

Создать резервную копию журнала транзакций

Пример резервного копирования журнала:

Если база данных повреждена, см. раздел Резервные копии Tail-Log (SQL Server).

ACTIVE_TRANSACTION log_reuse_wait

Действия по устранению причины ACTIVE_TRANSACTION включают в себя обнаружение длительно выполняющейся транзакции и ее разрешение (в некоторых случаях для этого используется команда KILL).

Обнаружение длительных транзакций

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

Это динамическое представление управления возвращает информацию о транзакциях на уровне базы данных. Для долго выполняющихся транзакций столбцы, представляющие особый интерес, включают время первой записи в журнале (database_transaction_begin_time), текущее состояние транзакции (database_transaction_state) и порядковый номер (LSN) начальной записи в журнале транзакций ( database_transaction_begin_lsn).

DBCC OPENTRAN. Этот оператор позволяет вам идентифицировать идентификатор пользователя владельца транзакции, поэтому вы потенциально можете отследить источник транзакции для более упорядоченного завершения (зафиксировать ее, а не откатить).

Завершить транзакцию

Иногда достаточно просто завершить транзакцию; возможно, вам придется использовать оператор KILL. Пожалуйста, используйте это утверждение очень осторожно, особенно когда запущены важные процессы, которые вы не хотите убивать. Дополнительные сведения см. в разделе KILL (Transact-SQL)

AVAILABILITY_REPLICA log_reuse_wait

Если изменения транзакций в первичной реплике Availability еще не закреплены на вторичной реплике, журнал транзакций на первичной реплике не может быть усечен. Это может привести к увеличению размера журнала и может произойти независимо от того, настроена ли вторичная реплика на синхронный или асинхронный режим фиксации. Информацию об устранении неполадок этого типа см. в разделе Ошибка 9002. Журнал транзакций для базы данных заполнен из-за ошибки AVAILABILITY_REPLICA

ПРОВЕРКА log_reuse_wait

С момента последнего усечения журнала не было контрольной точки или заголовок журнала еще не вышел за пределы виртуального файла журнала (VLF). (Все модели восстановления)

Это стандартная причина задержки усечения журнала. В случае задержки рассмотрите возможность выполнения команды CHECKPOINT в базе данных или проверки журналов VLF.

Для получения дополнительной информации о факторах log_reuse_wait

2. Разрешить полный объем диска

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

Свободное место на диске

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

Переместить файл журнала на другой диск

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

Файлы журналов никогда не следует размещать в сжатых файловых системах.

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

Добавить файл журнала на другой диск

Добавьте новый файл журнала в базу данных на другом диске, на котором достаточно места, с помощью команды ALTER DATABASE ADD LOG FILE . Несколько файлов журналов для одной базы данных следует рассматривать как временное условие для решения проблемы с пространством, а не долгосрочное условие. Большинство баз данных должны иметь только один файл журнала транзакций. Продолжайте исследовать причину, по которой журнал транзакций заполнен и не может быть усечен. Рассмотрите возможность добавления временных дополнительных файлов журнала транзакций в качестве расширенного шага по устранению неполадок.

Скрипт для рекомендуемых действий

Эти шаги можно частично автоматизировать, запустив этот скрипт T-SQL, который определит файлы журналов, занимающие большой процент дискового пространства, и предложит действия:

3. Изменить ограничение размера журнала или включить автоматическое увеличение

Ошибка 9002 может возникнуть, если установлен верхний предел размера журнала транзакций или не разрешено автоматическое увеличение.В этом случае включение автоматического увеличения или увеличение размера журнала вручную может помочь решить проблему. Используйте эту команду T-SQL, чтобы найти такие файлы журналов, и следуйте предоставленным рекомендациям:

Увеличить размер файла журнала или включить автоматическое увеличение

Если на диске журнала есть свободное место, вы можете увеличить размер файла журнала. Максимальный размер файлов журнала составляет два терабайта (ТБ) на файл журнала.

Если автоматическое увеличение отключено, база данных подключена к сети и на диске достаточно места, выполните одно из следующих действий:

Вручную увеличьте размер файла, чтобы получить однократное увеличение. Это общие рекомендации по увеличению размера и размера журнала.
Включите автоматическое увеличение с помощью оператора ALTER DATABASE, чтобы задать ненулевое значение приращения для параметра FILEGROWTH. См. Рекомендации по параметрам автоматического увеличения и автоматического сжатия в SQL Server

В любом случае, если достигнут текущий предел размера, увеличьте значение MAXSIZE.

Вы можете редактировать файлы прямо на GitHub в любом из ваших репозиториев с помощью редактора файлов.

Редактирование файлов в вашем репозитории

Совет. Если в репозитории есть защищенные ветки, вы не сможете редактировать или загружать файлы в защищенную ветку с помощью GitHub. Дополнительные сведения см. в разделе «О защищенных ветвях».

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

Примечание. Редактор файлов GitHub использует CodeMirror.

В репозитории перейдите к файлу, который хотите отредактировать.

В правом верхнем углу представления файла нажмите

чтобы открыть редактор файлов.

На вкладке "Редактировать файл" внесите необходимые изменения в файл.

Над новым содержимым нажмите Предварительный просмотр изменений.

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

Если с вашей учетной записью на GitHub.com связано несколько адресов электронной почты, щелкните раскрывающееся меню адресов электронной почты и выберите адрес электронной почты, который будет использоваться в качестве адреса электронной почты автора Git. В этом раскрывающемся меню отображаются только подтвержденные адреса электронной почты. Если вы включили конфиденциальность адреса электронной почты, то @users.noreply.github.com является адресом электронной почты автора коммита по умолчанию. Дополнительные сведения см. в разделе «Настройка адреса электронной почты для фиксации».

Под полями сообщения о коммите решите, следует ли добавить вашу фиксацию в текущую ветку или в новую ветку. Если ваша текущая ветка является веткой по умолчанию, вы должны создать новую ветку для своего коммита, а затем создать запрос на извлечение. Дополнительные сведения см. в разделе «Создание нового запроса на вытягивание».

Нажмите «Предложить изменение файла».

Редактирование файлов в репозитории другого пользователя

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

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

Над содержимым файла нажмите

<р>. На этом этапе GitHub разветвляет репозиторий для вас.

Внесите необходимые изменения в файл.

Над новым содержимым нажмите Предварительный просмотр изменений.

Нажмите «Предложить изменение файла».

Введите заголовок и описание запроса на вытягивание.

Нажмите Создать запрос на вытягивание.

Читайте также: