Чтобы обнаружить причину по которой место в журнале не может быть

Журнал транзакций заполнен. HRESULT=80040E14. Лог в 350 гиг

Основная теорема систематики: Новые системы плодят новые проблемы.

Источник

По какой причине место в журнале транзакций не может быть повторно использовано?

• Вопрос

• По какой причине место в журнале транзакций не может быть повторно использовано при режиме восстановления Simple Recovery Mode?

Ответы

• Предложено в качестве ответа Abolmasov Dmitry 7 июня 2012 г. 9:33
• Отменено предложение в качестве ответа TownSparrow 7 июня 2012 г. 19:51
• Помечено в качестве ответа TownSparrow 11 июня 2012 г. 6:58

Все ответы

• • Предложено в качестве ответа Abolmasov Dmitry 7 июня 2012 г. 9:33
  • Отменено предложение в качестве ответа TownSparrow 7 июня 2012 г. 19:51
  • Помечено в качестве ответа TownSparrow 11 июня 2012 г. 6:58

• Причина по которой я задал вопрос — почему место в журнале транзакций не может быть повторно использовано при режиме восстановления Simple Recovery Model следующая. Я сейчас пишу WPF-приложение, использующее MS SQL 2008 R2 с простой моделью восстановления. Это приложение должно работать с фондовой биржей РТС/ММВБ. Для связи с биржей использую их библиотеку объектов P2ClientGate. Мне нужно только создать в MS SQL базу данных и пользователя (с соответствующими привилегиями), а таблицы и данные в них объект пропишет сам автоматом. Суть моей проблемы в том, что с одними потоками репликации SQL Server работает прекрасно, а вот с другими — нет. Например, при использовании одного из потоков у меня в логе появилась следующая запись (здесь привожу её не полностью):

  …descr ‘[] / e:42000 native_error:9002[Microsoft][ODBC SQL Server

  Driver][SQL Server]Журнал транзакций для базы данных «FortsReplication_Futures» заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы sys.databases (row:1,col:-1)’

  В службе техподдержки РТС/ММВБ мне, относительно этого, ответили, что: «в данном случе проблема заключается именно в работе SQL сервера». А почему же тогда он с другими потоками нормально работает? Пользователь на всех один и тот же. Привилегии — одни и те же. Кстати, я смотрел столбец log_reuse_wait_descr таблицы sys.databases. В первой строке содержится слово NOTHING, во второй — ACTIVE TRANSACTION, во всех остальных — NOTHING. На всякий случай привожу тест оператора CREATE DATABASE с помощью которого создавал БД, в которую должны писаться данные из глючного потока.

  USE master; GO CREATE DATABASE FortsReplication_Futures1 ON PRIMARY (NAME = Arch2, FILENAME = ‘C:FortsReplicationDataFutures_ReplicationDataFutFortsReplDat1.mdf’, SIZE = 50MB, MAXSIZE = 100, FILEGROWTH = 10), ( NAME = Arch2, FILENAME = ‘C:FortsReplicationDataFutures_ReplicationDataFutFortsReplDat2.ndf’, SIZE = 50MB, MAXSIZE = 100, FILEGROWTH = 10), ( NAME = Arch3, FILENAME = ‘C:FortsReplicationDataFutures_ReplicationDataFutFortsReplDat3.ndf’, SIZE = 50MB, MAXSIZE = 100, FILEGROWTH = 10) (NAME = Archlog1, FILENAME = ‘C:FortsReplicationDataFutures_ReplicationDataFutFortsReplLog1.ldf’, SIZE = 25MB, MAXSIZE = 50, FILEGROWTH = 5), (NAME = Archlog2, FILENAME = ‘C:FortsReplicationDataFutures_ReplicationDataFutFortsReplLog2.ldf’, SIZE = 25MB, MAXSIZE = 50, FILEGROWTH = 5) ; GO

  Исходя из написанного выше — из за чего может кпапризничать SQL Server?

  С уважением Евгений.

  P.S. Поделюсь секретом — в MS SQL Server я пока ещё очень слаб.

• Исходя из написанного выше — из за чего может кпапризничать SQL Server?

  Ещё раз: сиквел работает, так как ВЫ это инициируете…смотрите активные транзакции, смотрите размер этих активных транзакций, ищите повисшие транзакции…запрос я вам указал в самом первом ответе

  ЗЫ: диски стоят копейки…вопрос свободного места сегодня звучит — смешно

  https://www.t-sql.ru

• Хорошо, Алексей. Все материалы по ссылкам, которые вы дали, я прочитаю. Большое спасибо вам за них и за помощь вобще.

  Но меня смущает следующая вещь. Зимой я поймал вирус (сейчас не помню точно как он назывался) и после этого у меня впервые появились глюки с сервером и потоком, которые я и описываю здесь. Потом я купил лицензионного Касперского Internet Security, установил его и пролечил компьютер. Касперский нашёл этот вирус и подавил его. Но глюки после этого некоторое время (довольно долго) всё равно шли. Потом прекратились. А вот сейчас опять начались. Поэтому у меня вопрос — мог ли быть SQL Server испорчен вирусом и настолько сильно, что даже после подавления вируса Касперским эта «поломка» в сервере осталась? Не очень-то хочется возиться с его переустановкой и пересозданием БД и пользователя. Но вобще есть вероятность порчи SQL Server’а вирусом? Кстати вирус я тогда поймал при включенном брандмауэре — предупреждение о нём дал он. Не мог ли брандмауэр тогда прописать в реестр что-нибудь такое, что сейчас мешает приёму даннвх? Хотя перед установкой Касперского я отключил брандмауэр, но если он до этого выполнил запись в реестр, то она всё равно осталась. Может ли всё это мешать работе сервера?

• Сомневаюсь, что вирус стал причиной того, что у вас переполняется лог-файл. Вы с этим «проблемным» сервером можете работать? проблемы только с P2ClientGate?

  https://www.t-sql.ru

• У меня этот сервер только и работает, что с P2ClientGate. Но ведь с другими-то потоками, и вчера в частности, он работал хорошо — не глючил.

  В принципе, вот как раз сейчас я гоняю своё приложение с P2ClientGate и SQL Server заработал с глючным потоком скажем так хорошо: где-то на 4 с минусом, а то и на 4. Но во первых, сегодня на бирже нет торгов и соответственно потоки только переходят в режим online-репликации, а физические данные по ним не идут, а во вторых, я сделал серверу полный backup, при котором, при Simple Recovery Model, файлы журналов автоматически очищаются. Вобщем пока работает.

  У меня ещё один вопрос. Вот если я хочу увеличить общую ёмкость журналов транзакций (что бы подстраховаться от ошибки 9002), то как лучше это сделать — добавить к двум имеющимся ldf-файлам третий таковой или же просто увеличить ёмкость каждого из двух имеющихся ldf-файлов, не добавляя при этом ещё один? Как лучше?

Источник

По какой причине место в журнале транзакций не может быть повторно использовано?

• Вопрос

• По какой причине место в журнале транзакций не может быть повторно использовано при режиме восстановления Simple Recovery Mode?

Ответы

• Предложено в качестве ответа Abolmasov Dmitry 7 июня 2012 г. 9:33
• Отменено предложение в качестве ответа TownSparrow 7 июня 2012 г. 19:51
• Помечено в качестве ответа TownSparrow 11 июня 2012 г. 6:58

Все ответы

• • Предложено в качестве ответа Abolmasov Dmitry 7 июня 2012 г. 9:33
  • Отменено предложение в качестве ответа TownSparrow 7 июня 2012 г. 19:51
  • Помечено в качестве ответа TownSparrow 11 июня 2012 г. 6:58

• Причина по которой я задал вопрос — почему место в журнале транзакций не может быть повторно использовано при режиме восстановления Simple Recovery Model следующая. Я сейчас пишу WPF-приложение, использующее MS SQL 2008 R2 с простой моделью восстановления. Это приложение должно работать с фондовой биржей РТС/ММВБ. Для связи с биржей использую их библиотеку объектов P2ClientGate. Мне нужно только создать в MS SQL базу данных и пользователя (с соответствующими привилегиями), а таблицы и данные в них объект пропишет сам автоматом. Суть моей проблемы в том, что с одними потоками репликации SQL Server работает прекрасно, а вот с другими — нет. Например, при использовании одного из потоков у меня в логе появилась следующая запись (здесь привожу её не полностью):

  …descr ‘[] / e:42000 native_error:9002[Microsoft][ODBC SQL Server

  Driver][SQL Server]Журнал транзакций для базы данных «FortsReplication_Futures» заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы sys.databases (row:1,col:-1)’

  В службе техподдержки РТС/ММВБ мне, относительно этого, ответили, что: «в данном случе проблема заключается именно в работе SQL сервера». А почему же тогда он с другими потоками нормально работает? Пользователь на всех один и тот же. Привилегии — одни и те же. Кстати, я смотрел столбец log_reuse_wait_descr таблицы sys.databases. В первой строке содержится слово NOTHING, во второй — ACTIVE TRANSACTION, во всех остальных — NOTHING. На всякий случай привожу тест оператора CREATE DATABASE с помощью которого создавал БД, в которую должны писаться данные из глючного потока.

  USE master; GO CREATE DATABASE FortsReplication_Futures1 ON PRIMARY (NAME = Arch2, FILENAME = ‘C:FortsReplicationDataFutures_ReplicationDataFutFortsReplDat1.mdf’, SIZE = 50MB, MAXSIZE = 100, FILEGROWTH = 10), ( NAME = Arch2, FILENAME = ‘C:FortsReplicationDataFutures_ReplicationDataFutFortsReplDat2.ndf’, SIZE = 50MB, MAXSIZE = 100, FILEGROWTH = 10), ( NAME = Arch3, FILENAME = ‘C:FortsReplicationDataFutures_ReplicationDataFutFortsReplDat3.ndf’, SIZE = 50MB, MAXSIZE = 100, FILEGROWTH = 10) (NAME = Archlog1, FILENAME = ‘C:FortsReplicationDataFutures_ReplicationDataFutFortsReplLog1.ldf’, SIZE = 25MB, MAXSIZE = 50, FILEGROWTH = 5), (NAME = Archlog2, FILENAME = ‘C:FortsReplicationDataFutures_ReplicationDataFutFortsReplLog2.ldf’, SIZE = 25MB, MAXSIZE = 50, FILEGROWTH = 5) ; GO

  Исходя из написанного выше — из за чего может кпапризничать SQL Server?

  С уважением Евгений.

  P.S. Поделюсь секретом — в MS SQL Server я пока ещё очень слаб.

• Исходя из написанного выше — из за чего может кпапризничать SQL Server?

  Ещё раз: сиквел работает, так как ВЫ это инициируете…смотрите активные транзакции, смотрите размер этих активных транзакций, ищите повисшие транзакции…запрос я вам указал в самом первом ответе

  ЗЫ: диски стоят копейки…вопрос свободного места сегодня звучит — смешно

  https://www.t-sql.ru

• Хорошо, Алексей. Все материалы по ссылкам, которые вы дали, я прочитаю. Большое спасибо вам за них и за помощь вобще.

  Но меня смущает следующая вещь. Зимой я поймал вирус (сейчас не помню точно как он назывался) и после этого у меня впервые появились глюки с сервером и потоком, которые я и описываю здесь. Потом я купил лицензионного Касперского Internet Security, установил его и пролечил компьютер. Касперский нашёл этот вирус и подавил его. Но глюки после этого некоторое время (довольно долго) всё равно шли. Потом прекратились. А вот сейчас опять начались. Поэтому у меня вопрос — мог ли быть SQL Server испорчен вирусом и настолько сильно, что даже после подавления вируса Касперским эта «поломка» в сервере осталась? Не очень-то хочется возиться с его переустановкой и пересозданием БД и пользователя. Но вобще есть вероятность порчи SQL Server’а вирусом? Кстати вирус я тогда поймал при включенном брандмауэре — предупреждение о нём дал он. Не мог ли брандмауэр тогда прописать в реестр что-нибудь такое, что сейчас мешает приёму даннвх? Хотя перед установкой Касперского я отключил брандмауэр, но если он до этого выполнил запись в реестр, то она всё равно осталась. Может ли всё это мешать работе сервера?

• Сомневаюсь, что вирус стал причиной того, что у вас переполняется лог-файл. Вы с этим «проблемным» сервером можете работать? проблемы только с P2ClientGate?

  https://www.t-sql.ru

• У меня этот сервер только и работает, что с P2ClientGate. Но ведь с другими-то потоками, и вчера в частности, он работал хорошо — не глючил.

  В принципе, вот как раз сейчас я гоняю своё приложение с P2ClientGate и SQL Server заработал с глючным потоком скажем так хорошо: где-то на 4 с минусом, а то и на 4. Но во первых, сегодня на бирже нет торгов и соответственно потоки только переходят в режим online-репликации, а физические данные по ним не идут, а во вторых, я сделал серверу полный backup, при котором, при Simple Recovery Model, файлы журналов автоматически очищаются. Вобщем пока работает.

  У меня ещё один вопрос. Вот если я хочу увеличить общую ёмкость журналов транзакций (что бы подстраховаться от ошибки 9002), то как лучше это сделать — добавить к двум имеющимся ldf-файлам третий таковой или же просто увеличить ёмкость каждого из двух имеющихся ldf-файлов, не добавляя при этом ещё один? Как лучше?

Источник