транзакции, сборка мусора и проч.

IBX, FIBPlus, UIB, ADO, .Net и прочее-прочее-прочее, в общем все, что относится к созданию приложений, работающих с InterBase, Firebird и Yaffil - клиент-серверных, трехзвенных, консольных и т.п.

Модератор: kdv

SVG
Сообщения: 10
Зарегистрирован: 15 май 2008, 12:59

транзакции, сборка мусора и проч.

Сообщение SVG » 15 май 2008, 15:56

Здравствуйте,

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

опять же, в силу сложившихся обстоятельств, необходимо регулярно переливать данные из gdb в fdb. делается это под Firebird 1.5.
если опустить не слишком важные подробности:
имеем три базы данных:
1.gdb - из нее регулярно необходимо перекачивать данные для того, чтобы обеспечить более удобную их организацию
2.fdb - старая версия рабочей базы. для этой базы есть софтина, перекачивающая данные с исходниками (delfi, FIBPlus).
3.fdb - новая версия рабочей базы. для этой базы софтина, перекачивающая данные, разрабатывается (delphi, FIBPlus).собссно, по ней и вопрос.

с 1.gdb работают клиентские приложения. с 2.fdb - на текущий момент - нет (по причине ввода в опытную эксплуатацию новой базы 3.fdb).

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

параметры базы данных 3.fdb в новом приложении (приведены в соответствие со старым приложением):

Код: Выделить всё

object pMedDB: TpFIBDatabase
    ClientLibraryName = 'gds32.dll'
    DBParams.Strings = (
      'lc_ctype=WIN1251')
    DefaultTransaction = pMedTrans
    SQLDialect = 3
    Timeout = 0
    DesignDBOptions = []
    Left = 72
    Top = 24
  end
object pMedTrans: TpFIBTransaction
    DefaultDatabase = pMedDB
    TimeoutAction = TARollback
    TRParams.Strings = (
      'write'
      'nowait'
      'rec_version'
      'read_committed')
    TPBMode = tpbDefault
    UserKindTransaction = 'rw'
    Left = 136
    Top = 16
  end

в ОБЩЕМ ВИДЕ код ОБОИХ приложений выглядит приблизительно так:

Код: Выделить всё

  if not DestDB.Connected then
    begin
      DestDB.Connected:=true;
      if not DestDB.DefaultTransaction.InTransaction then
        DestDB.DefaultTransaction.StartTransaction;
    end;
  if not SourceDB.Connected then
    begin
      SourceDB.Connected:=true;
      if not SourceDB.DefaultTransaction.InTransaction then
        SourceDB.DefaultTransaction.StartTransaction;
    end;

  DestQuery.Close;
  DestQuery.SQL.Clear;
  DestQuery.SQL.Add('DELETE FROM "table1"');
  DestQuery.Prepare;
  DestQuery.ExecQuery;

  DestQuery.Close;
  DestQuery.SQL.Clear;
  DestQuery.SQL.Add('insert into "table1" ("field1"..."fieldn") values (:val1,... :valn)');

  SourceQuery.Close;
  SourceQuery.SQL.Clear;
  SourceQuery.SQL.Add('select * from table1');
  SourceQuery.Prepare;
  SourceQuery.ExecQuery;
  RC:=0;
  while not SourceQuery.Eof do
  begin
    Id1:=SourceQuery.FieldByName['field1'].Value;
    Id2:=SourceQuery.FieldByName['id_field2'].Value;
    ...
    Idn:=SourceQuery.FieldByName['id_fieldn'].Value;
    ...{некоторая обработка}
    DestQuery.ExecWP([Id1,Id2,...Idn]);
    DestQuery.Close;
    Inc(RC);
    if (RC mod 10) = 0
      then Application.ProcessMessages;
    SourceQuery.Next;
  end;
  SourceQuery.Close;
  if SourceDB.Connected then
    begin
      if SourceDB.DefaultTransaction.InTransaction then
        SourceDB.DefaultTransaction.Commit;
      SourceDB.Connected:=false;
    end;
  if DestDb.Connected then
    begin
      if DestDb.DefaultTransaction.InTransaction then
         DestDb.DefaultTransaction.Commit;
       DestDB.Close;
    end;
в таблице table1 порядка 150 тыс записей.
в случае запуска подобной процедуры c 2.fdb в старом приложении получаю 2.fdb такого же размера, как и до обновления (когда количество записей в table1 в 1.gdb и 2.fdb одинаковое) или незначительный прирост (если количество записей в 1.gdb больше). запуская процедуру обновления данных в новом приложении получаю 3.fdb c приростом в размере ~30 Мб. то есть выполняя аналогичные действия с аналогичным количеством записей (с аналогичной исходной таблицей и разными базами - получателями данных), новое приложение по всей видимости накапливает в новой базе мусор, а старое приложение в своей базе - нет.

перед выполнением обновления новым приложением на новой базе запускаю gstat:

Код: Выделить всё

Database header page information:
	Flags			0
	Checksum		12345
	Generation		2693
	Page size		4096
	ODS version		10.1
	Oldest transaction	2645
	Oldest active		2659
	Oldest snapshot		2659
	Next transaction	2692
	Bumped transaction	1
	Sequence number		0
	Next attachment ID	0
	Implementation ID	16
	Shadow count		0
	Page buffers		0
	Next header page	0
	Database dialect	3
	Creation date		May 4, 2008 5:48:10
	Attributes		force write

    Variable header data:
	*END*


Database file sequence:
File c:\works\1\med.fdb is the only file

Database log page information:
	Creation date
	Log flags:	2
		No write ahead log

	Next log page:	0

    Variable log data:
	Control Point 1:
		File name:	
		Partition offset: 0 	Seqno: 0 	Offset: 0 
	Control Point 2:
		File name:	
		Partition offset: 0 	Seqno: 0 	Offset: 0 
	Current File:
		File name:		
		Partition offset: 0 	Seqno: 0 	Offset: 0 
	*END*

Analyzing database pages ...

addresses (145)
    Primary pointer page: 249, Index root page: 250
    Average record length: 84.17, total records: 153776
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 4749, data page slots: 4749, average fill: 80%
    Fill distribution:
	 0 - 19% = 0
	20 - 39% = 1
	40 - 59% = 0
	60 - 79% = 1432
	80 - 99% = 3316
.......
........
после выполнения обновления новым приложением на новой базе запускаю gsat:

Код: Выделить всё

Database header page information:
	Flags			0
	Checksum		12345
	Generation		2696
	Page size		4096
	ODS version		10.1
	Oldest transaction	2645
	Oldest active		2694
	Oldest snapshot		2694
	Next transaction	2695
	Bumped transaction	1
	Sequence number		0
	Next attachment ID	0
	Implementation ID	16
	Shadow count		0
	Page buffers		0
	Next header page	0
	Database dialect	3
	Creation date		May 4, 2008 5:48:10
	Attributes		force write

    Variable header data:
	*END*


Database file sequence:
File c:\works\1\med.fdb is the only file

Database log page information:
	Creation date
	Log flags:	2
		No write ahead log

	Next log page:	0

    Variable log data:
	Control Point 1:
		File name:	
		Partition offset: 0 	Seqno: 0 	Offset: 0 
	Control Point 2:
		File name:	
		Partition offset: 0 	Seqno: 0 	Offset: 0 
	Current File:
		File name:		
		Partition offset: 0 	Seqno: 0 	Offset: 0 
	*END*

Analyzing database pages ...

addresses (145)
    Primary pointer page: 249, Index root page: 250
    Average record length: 42.20, total records: 308364
    Average version length: 84.17, total versions: 153776, max versions: 1
    Data pages: 9523, data page slots: 9523, average fill: 87%
    Fill distribution:
	 0 - 19% = 0
	20 - 39% = 0
	40 - 59% = 0
	60 - 79% = 1473
	80 - 99% = 8050
.....
....
скажите, в какой части ДНК искать ошибку?)
ЗЫ. извиняюсь за длинный пост. не было времени написать короче)
Последний раз редактировалось SVG 16 май 2008, 00:25, всего редактировалось 1 раз.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 15 май 2008, 16:43

Если логика позволяет, поставь COMMIT после DELETE

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 15 май 2008, 18:42

скажите, в какой части ДНК искать ошибку?
1. научись оформлять код в вопросах тегом code. кроме того, ты можешь редактировать собственные сообщения. Будь любезен.

2. не надо для простого вопроса вываливать портянки. У любого нормального человека после 15-ти строк наступит кома.

3. Average version length: 84.17, total versions: 153776, max versions: 1
есть такая хрень, IBAnalyst. Висит тут же, на форуме.

дальше - ты совсем не в курсе версионности??? Тогда тебе не вопросы задавать надо, а читать статьи по транзакциям на сайте, и не один раз.

4 if DestDb.DefaultTransaction.InTransaction then

опять же. читать, читать и читать. www.ibase.ru/devinfo/ibx.htm
особенно раздел про управление транзакциями

SVG
Сообщения: 10
Зарегистрирован: 15 май 2008, 12:59

Сообщение SVG » 16 май 2008, 00:39

hvlad писал(а):Если логика позволяет, поставь COMMIT после DELETE
логика позволяет конечно. но... оно не слишком то влияет. посмотрел в коде старого приложения. там нет COMMIT после DELETE. при этом работает как часы, и размер базы не растет без меры.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 16 май 2008, 00:53

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

SVG
Сообщения: 10
Зарегистрирован: 15 май 2008, 12:59

Сообщение SVG » 16 май 2008, 01:59

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

2. не надо для простого вопроса вываливать портянки. У любого нормального человека после 15-ти строк наступит кома.
я вообще довольно любезный в общем случае человек. и в принципе неконфликтный. по сему - конечно же поставил теги. надеюсь, удобнее стало? и по поводу отповеди постараюсь скромно заметить, што их я тоже люблю (и, если надо, могу), но полемика в таком разрезе мне не интересна. интересно экспертное мнение. в общем, надеюсь, што владелец такого важного форума, как этот, настолько же заинтересован в вопросах, насколько его посетители в ответах. за портянку, единожды извинившись, извиняюсь еще раз.
3. Average version length: 84.17, total versions: 153776, max versions: 1
есть такая хрень, IBAnalyst. Висит тут же, на форуме.

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

посмотрел IBAnalyst. удобная штука. и объясняется хорошо все там.
4 if DestDb.DefaultTransaction.InTransaction then

опять же. читать, читать и читать. www.ibase.ru/devinfo/ibx.htm
особенно раздел про управление транзакциями
здесь критичное место? плохо, што транзакция одна, вместо двух, как здесь везде рекомендуется? или што завершается она при выполнениении условия? хз... што тут еще может быть.. или што я обращаюсь к ней через свойство базы?


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

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

stix-s
Заслуженный разработчик
Сообщения: 557
Зарегистрирован: 13 дек 2005, 11:52

Сообщение stix-s » 16 май 2008, 07:19

SVG писал(а):

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


спасибо за внимание к моему вопросу. буду очень благодарен, если последует дополнительный комментарий.........
в твоем случае, если ты только перекачиваешь данные, одной транзакции вполне достаточно
Ты к новой базе при перекачке ничем больше не цепляешься? например IBExpert?
Чему равен параметр GCPolicy в firebird.conf?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 16 май 2008, 09:54

в общем, надеюсь, што владелец такого важного форума, как этот, настолько же заинтересован в вопросах, насколько его посетители в ответах.
ошибка. владелец ресурса не заинтересован в вопросах. вообще весь ресурс был сделан для того, чтобы минимизировать вопросы. Но это, действительно, полемика.
я вижу, што с ней не все хорошо. я хочу понять скорее, является ли рост размеров базы при массовом обновлении данных каким то косяком непосредственно в процессе обновления?
получаем статистику из базы 2, получаем из базы 3, сравниваем визуально.
или што я обращаюсь к ней через свойство базы?
ясно - не читал.
то можно наверное и снизойти до простого ответа на простой вопрос?
самый простой ответ - сравнение.
приложение 1 копирует данные из базы 1 в базу 2
приложение 2 копирует данные из базы 2 в базу 3
так?
ну и сравнивай базы 2 и 3 до и после копирования.
а разница скорее всего и правда в commit после delete.

Собственно, да, в базе 3 создаются версии. Что тут такого? Это естественно. И в базе 2 точно так же.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 16 май 2008, 10:36

SVG писал(а):
hvlad писал(а):Если логика позволяет, поставь COMMIT после DELETE
логика позволяет конечно. но... оно не слишком то влияет. посмотрел в коде старого приложения. там нет COMMIT после DELETE. при этом работает как часы, и размер базы не растет без меры.
В том приложении может быть где-то автокоммит у компонент.
Точный ответ даст монитор.

Далее. Как заметил KDV, если есть ещё тр-ции, то они могут удерживать OST и блокировать сборку мусора. Т.к. с 2.fdb никто больше не работает, а с 3.fdb кто-то всё-таки работает, то это вполне может быть.

SVG
Сообщения: 10
Зарегистрирован: 15 май 2008, 12:59

Сообщение SVG » 16 май 2008, 14:15

в твоем случае, если ты только перекачиваешь данные, одной транзакции вполне достаточно
Ты к новой базе при перекачке ничем больше не цепляешься? например IBExpert?
не всегда просто перекачиваю. иногда приходится перед вставкой в 3.fdb што то из нее прочесть. но это, похоже, не суть. вчерашний вечер посвятил разделению транзакций в новом приложении. результат тот же. база растет в размерах после перекачки данных даже в том случае, если транзакции разделены на читающую и пишущую, все они четко стартуются и завершаются и промежуток между StartTransaction и Commit минимальный.

К базе в процессе перекачки цепляется только качающее приложение.
Чему равен параметр GCPolicy в firebird.conf?
GCPolicy не с Firebird 2 появился? я все делаю под 1.5. в firebird.conf такого параметра нет.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Re: транзакции, сборка мусора и проч.

Сообщение hvlad » 16 май 2008, 14:26

SVG писал(а):в таблице table1 порядка 150 тыс записей.
в случае запуска подобной процедуры c 2.fdb в старом приложении получаю 2.fdb такого же размера, как и до обновления (когда количество записей в table1 в 1.gdb и 2.fdb одинаковое) или незначительный прирост (если количество записей в 1.gdb больше). запуская процедуру обновления данных в новом приложении получаю 3.fdb c приростом в размере ~30 Мб.
Каковы размеры 2.fdb и 3.fdb ? Растет ли 3.fdb при повторных обновлениях ?
SVG писал(а):то есть выполняя аналогичные действия с аналогичным количеством записей (с аналогичной исходной таблицей и разными базами - получателями данных), новое приложение по всей видимости накапливает в новой базе мусор, а старое приложение в своей базе - нет.
Откуда такая уверенность ? Статистику 2.fdb до и после обновления смотрел ?

SVG
Сообщения: 10
Зарегистрирован: 15 май 2008, 12:59

Сообщение SVG » 16 май 2008, 14:36

В том приложении может быть где-то автокоммит у компонент.
Точный ответ даст монитор.
нет. автокоммита нет. проверил.
Далее. Как заметил KDV, если есть ещё тр-ции, то они могут удерживать OST и блокировать сборку мусора. Т.к. с 2.fdb никто больше не работает, а с 3.fdb кто-то всё-таки работает, то это вполне может быть.
исходя из показаний gstat такой вывод можно сделать?

Oldest transaction 2645
Oldest active 2659
Oldest snapshot 2659
Next transaction 2692

получается, што транзакция #2645 где то подвисла и мешает сборке мусора в процессе обновления. прально? тогда, по идее, мне надо проверять не приложение, выполняющее обновление, а приложение, с которым на текущий момент работают пользователи. критерием такой проверки должно стать OldestTransaction=NextTransaction-1 (в том случае, когда все клиентские приложения пользователей завершены). так?

SVG
Сообщения: 10
Зарегистрирован: 15 май 2008, 12:59

Re: транзакции, сборка мусора и проч.

Сообщение SVG » 16 май 2008, 15:03

hvlad писал(а): Каковы размеры 2.fdb и 3.fdb ? Растет ли 3.fdb при повторных обновлениях ?
размеры 247 мб и 186 мб соответственно. но 3.fdb может и до 300 мб вырасти, если перекачивать все таблицы, которые надо. на 30 мб она вырастает, если одну таблицу перекачать из 1.gdb.
SVG писал(а):то есть выполняя аналогичные действия с аналогичным количеством записей (с аналогичной исходной таблицей и разными базами - получателями данных), новое приложение по всей видимости накапливает в новой базе мусор, а старое приложение в своей базе - нет.
hvlad писал(а):Откуда такая уверенность ? Статистику 2.fdb до и после обновления смотрел ?
в 1.gdb таблица addresses положим 150 000 записей. в 2.fdb таблица addresses 149500 записей. перекачиваем из 1.gdb в 2.fdb содержимое таблицы старым приложением. получаем прирост размера 2.fdb ну скажем 500 кб (точно не скажу). если в обоих этих базах таблицы с одинаковым количеством записей, то после перекачки данных размер 2.fdb не изменится.

если начать перекачивать из 1.gdb в 3.fdb новым приложением, то прирост размера 3.fdb будет измеряться в десятках Мб даже если в таблицах addresses было одинаковое количество записей.

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Re: транзакции, сборка мусора и проч.

Сообщение WildSery » 16 май 2008, 15:09

SVG писал(а):в 1.gdb таблица addresses положим 150 000 записей. в 2.fdb таблица addresses 149500 записей. перекачиваем из 1.gdb в 2.fdb содержимое таблицы старым приложением. получаем прирост размера 2.fdb ну скажем 500 кб (точно не скажу). если в обоих этих базах таблицы с одинаковым количеством записей, то после перекачки данных размер 2.fdb не изменится.

если начать перекачивать из 1.gdb в 3.fdb новым приложением, то прирост размера 3.fdb будет измеряться в десятках Мб даже если в таблицах addresses было одинаковое количество записей.
SVG писал(а):обе софтины, и старая и новая делают одно и тоже. собссно перекачивают данные) в старой более навороченный алгоритм обработки. в новой алгоритма обработки почти совсем нет, она затачивается на то, штобы делать свою работу по возможности быстрее.
Исходя из этих двух абзацев я телепатирую, что "старое приложение" делает предварительный селект, и апдейтит только отличающиеся записи.
"Новое" приложение тупо делает апдейт. И это, кстати, не быстрее.
Сделаю предположение, что вот это не читал (читал по диагонали, читал но не понял).

SVG
Сообщения: 10
Зарегистрирован: 15 май 2008, 12:59

Re: транзакции, сборка мусора и проч.

Сообщение SVG » 16 май 2008, 15:25

WildSery писал(а): Исходя из этих двух абзацев я телепатирую, что "старое приложение" делает предварительный селект, и апдейтит только отличающиеся записи.
"Новое" приложение тупо делает апдейт. И это, кстати, не быстрее.
)) у меня перед носом код двух приложений. они в общем случае делают одно и тоже. "тупо делают апдейт". в том смысле, што, перекачивая данные из таблицы1 в таблицу2, предварительно удаляют все строки из таблицы2 и вставляют туда все строки из таблицы1.
WildSery писал(а):Сделаю предположение, что вот это не читал (читал по диагонали, читал но не понял).
не читал. щас прочел по диагонали.

SVG
Сообщения: 10
Зарегистрирован: 15 май 2008, 12:59

Сообщение SVG » 16 май 2008, 15:49

kdv писал(а):
или што я обращаюсь к ней через свойство базы?
ясно - не читал.
ну может ткнешь таки носом то? што здесь не так по твоему? еще раз повторю, што прочел здесь некоторое количество документов. они все хороши в том смысле, што обстоятельно и подробно все объясняют. НО. за вечер прочесть например сто страниц документации можно только опуская што то, а што то читая по диагонали, выделяя основное, то, што нужно в данный конкретный момент. если бы у меня был месяц, я бы сел, читал, разбирался, ставил эксперименты и никого вопросами бы не заморачивал. если спрашиваю, значит, прочтя документы, што то либо пропустил, либо недопонял.
kdv писал(а): самый простой ответ - сравнение.
приложение 1 копирует данные из базы 1 в базу 2
приложение 2 копирует данные из базы 2 в базу 3
так?
ну и сравнивай базы 2 и 3 до и после копирования.
а разница скорее всего и правда в commit после delete.

Собственно, да, в базе 3 создаются версии. Что тут такого? Это естественно. И в базе 2 точно так же.
приложение 1 копирует данные из базы 1 в базу 2
приложение 2 копирует данные из базы 1 в базу 3

приложение 2 увеличивает размер базы (видимо за счет версий), а приложение 1 - нет. в обоих приложениях commit после delete не стоит.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Re: транзакции, сборка мусора и проч.

Сообщение hvlad » 16 май 2008, 16:37

SVG писал(а):
hvlad писал(а): Каковы размеры 2.fdb и 3.fdb ? Растет ли 3.fdb при повторных обновлениях ?
размеры 247 мб и 186 мб соответственно. но 3.fdb может и до 300 мб вырасти, если перекачивать все таблицы, которые надо. на 30 мб она вырастает, если одну таблицу перекачать из 1.gdb.
3.fdb растёт при 3-м, 4-ом и т.д. обновлениях, или нет ?

PS что пишется через ч

SVG
Сообщения: 10
Зарегистрирован: 15 май 2008, 12:59

Re: транзакции, сборка мусора и проч.

Сообщение SVG » 16 май 2008, 17:01

hvlad писал(а):3.fdb растёт при 3-м, 4-ом и т.д. обновлениях, или нет ?
растет

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 16 май 2008, 17:29

А если обновлять в монопольном режиме ? Т.е. без коннектов от других приложений

SVG
Сообщения: 10
Зарегистрирован: 15 май 2008, 12:59

Сообщение SVG » 16 май 2008, 17:58

hvlad писал(а):А если обновлять в монопольном режиме ? Т.е. без коннектов от других приложений
а никакие другие приложения и не подключаются к базе в момент обновления.

Ответить