Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
Скажите, а как уменьшить физический размер журнала транзакций? Делаю DBCC SHRINKFILE, а еиу хоть бы что? Причем Truncate Log уже сделан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2001, 12:03 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
SHRINKFILE с задержкой работает - я обычно после этого какую-нибудь большую операцию в базе данных выполняю, а потом еще checkpoint - в BOL, в принципе, есть информация, только несколько путанно описано... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2001, 12:08 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
Перепробовал все. Однако файл журнала как был 7 МВ, так и остался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2001, 13:23 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
2 Чайник Может в этом проблема? There are fixed boundaries within which a transaction log file can be shrunk. This depends on the initial size of the transaction log and the number of virtual log files used. For example, a large initial transaction log file of 1 gigabyte (GB) may comprise five virtual log files of 200 MB each. Shrinking the transaction log file deletes unused virtual log files, but leaves at least one virtual log file. Because each virtual log file in this example is 200 MB, the transaction log can shrink only to a minimum of 200 MB. To allow a transaction log file to shrink to a smaller size, create a smaller transaction log and allow it to grow automatically, rather than creating a large transaction log file. Shrinking a transaction log file does not shrink the file immediately but instead causes the file to be marked for later shrinking. Each time the transaction log is subsequently backed up or truncated (for example, when the trunc. log on chkpt. database option is set to true), SQL Server will attempt to shrink the transaction log file as much as possible until it reaches the desired size specified by the user. If the active portion of the transaction log is at the end of the transaction log file, the file cannot be shrunk. However, as soon as the active portion of the transaction log moved to the beginning of the file, the transaction log file can be shrunk. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2001, 13:48 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
2 Genady И это тоже я учитывал. Дело в том, что создавался он с начальным размеров 1 МВ с автоматическим увеличением на 10% без лимита. Может еще в чем дело? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2001, 14:06 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
Да забудьте Вы про эти 7Мб! Куда уж меньше... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2001, 14:50 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
Если уже больше ничего не помогает можно сделать 1) sp_detach_db 2) sp_attach_db. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2001, 05:48 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
По моему дело не в 7 МВ, а в том что "во время пути собачка могла подрасти" Лог то все равно будет увеличиваться, причем гораздо большими темпами чем хотелось бы У нас возникла такая же проблема и решение нашлось по следующему адресу http://support.microsoft.com/support/kb/articles/Q256/6/50.ASP помогло кстати Майкрософт утверждает что в 2000-м сервере DBCC SHRINKFILE больше не является отложенной операцией кто-нибудь проверял ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2001, 06:08 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
Ясное дело, что 7 МВ ерунда. Но дело в принципе. Проблему рано или поздно придется решать, когда Log будет весить 1GB? :o))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2001, 06:38 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
Из лога не удаляются транзакции, которые не были завершены, а также транзакции, которые участвуют в репликации. Участвующие в репликации транзакции помечаются специальным образом и остаются в логе даже после очистки журнала транзакций. Эти транзакции обязаны остаться в журнале, поскольку Log Reader их, возможно, еще не прочитал. Срок хранения реплицируемых транзакций задается в параметрах публикации. Вы уверены, что не проводили никаких экспериментов с репликацией? И что у вас нет подвисших незавершенных транзакций? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2001, 13:19 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
2 Garya >Срок хранения реплицируемых транзакций задается в параметрах публикации. Могли бы Вы подсказать, где именно это задается ? Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2001, 13:44 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
2 Garya Репликация только планируется, экспериментов еще небыло. А насчет транзакций - ведь DBCC OPENTRAN не может врать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2001, 13:45 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
2 Дмитрий Голубев. Publication properties - закладка General - subscription expire and are dropped if not syncronized in the following number of days: (по умолчанию 60, если я не ошибаюсь). 2 Чайник. Тады ой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2001, 11:47 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
Уважаемый Чайник, раскажите пожалуйста Кофейнику более подробно: характеристики сервера, базы, подключений, эксплуаттационных режимов и т.п., а то мы так и будем ходить вокруг да около... Ваша проблема не нова, решалась многими и не однократно и мне пока не известны случаи, когда журнал не удовалось очистить. Кроме того, нужно помнить, что журналируются не только запросы пользователей, но и другие, сугубо серверные задачи. Так что, вполне возможно, что у Вас всё паолучилось, но пока Вы пили кофе, журнал немножечко (7Мб - пренебрежимо маленькая цифра) подрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2001, 12:35 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
Может заодно надоумите, как правильно бэкапить лог в SQL6.5. А то понимаешь, кажется мне, что что то я не так делаю. DUMP TRUNSACTION db_log TO dump_dev WITH INIT Я вот сомневаюсь, должен ли он при этом обезаться? Ведь после этого надо полный дамп делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2001, 14:38 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
В 6.5 всё довольно просто. После полной копии базы, настраиваете по расписанию копирование журнала. Периодичность копирования выбираете из тех соображений, что время, затраченное на резервирование накопившихся записей в журнале, было не велико. Другим критерием, может быть объём выполннеых и зафиксированных в журнале операций, который не сложно восстановить (даже вручную) в случае сбоя, в результате которого постадает не только база но и сам журнал транзакций. В таком случае, вы сможете восстановить из резервной копии максимально большой объём данных, а остальное востановите другим путём. В 6.5 журнал не усекается автоматически, а просто очищается. В уже упоминавшейся мной в этой ветке статье, рассказывается, как определить, очищается ли он полностью и, что делать, если в журнале застряли и не удаляются записи. http://www.sql.ru/subscribe/045.shtml#2 О том, почему это происходит, было чуть раньше: Причины заполнения журнала транзакций SQL серверов 4.2x, 6.0, 6.5, 7.0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2001, 14:56 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
Александр, к сожалению, Вы меня не поняли. Мой вопрос - можно ли/предусмотренно ли проводить бекап журнала, НЕ ОБРЕЗАЯ его. Т.к. после бекапа журнала, с помощью приведенного выше скрипта, сделать ещё один бекап журнала нельзя до тех пор, пока не будет проведен полный бэкап базы. А приведенные номера рассылок я уже читал, и они мне помогли, когда журнал не очищался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2001, 06:48 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
Т.е. я хочу задать вот такое расписание: * ежедневный бекап транзакционного лога; * раз в неделю - бэкап всей базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2001, 06:54 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
DUMP TRUNSACTION db_log TO dump_dev WITH NOUNLOAD, NOINIT, NOSKIP и тогда всё получится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2001, 10:13 |
|
||
|
Transaction Log
|
|||
|---|---|---|---|
|
#18+
Согласен. Меня сбил с толку HELP. from Transact-SQL Reference Help (SQL 6.5) DUMP Statment Note The UNLOAD and NOUNLOAD options are supported only by TAPE dump devices. When you specify a PIPE dump device, multivolume dumps and >>>_dump_device_<<< options (UNLOAD, NOUNLOAD, INIT, NOINIT, SKIP, NOSKIP, EXPIREDATE, and RETAINDAYS) are not supported. (ну не умеют америкозы толково сложноподчиненные предложения строить ) Я изначально понял, что неподдерживаются By "PIPE dump device, multivolume dumps and dump device"... А правильно, видимо: Опции применимые к "multivolume dumps and dump device", не поддерживаются By "PIPE dump device" Сплошной ансапортед ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2001, 14:03 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32007470&tid=1826460]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
81ms |
get tp. blocked users: |
2ms |
| others: | 261ms |
| total: | 430ms |

| 0 / 0 |
