Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Куда могут пропадать данные?  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 909
сделал программу клиент Delphi + MSSQL 2005 Express
пользователи жалуются, что периодически пропадают данные....
то есть, что-то заносят, проверяют, делают отчёты... а на следующий день...
половины из того что занесли - нет в базе...

уже обернул UPDATы и INSERTы в хранимках в, конструкцию
  WHILE (@retry > 0)
  BEGIN
     BEGIN TRY
       BEGIN TRANSACTION;    
       ----------------------
       -- выполнение модификации базы... с хинтами
       ----------------------
       SET @retry = -5;
       COMMIT TRANSACTION;
     END TRY BEGIN CATCH 
        SET @err_msg = admin_ch.get_error_info();
        IF((ERROR_NUMBER() = 1205)OR(ERROR_NUMBER() = 1222))  
             SET @retry = @retry - 1;-- если из за блк или тайм аут то дадим ещё шанс            
        ELSE SET @retry = -1;-- если что-то другое то просто выходим
        IF XACT_STATE() <> 0 ROLLBACK TRANSACTION;
     END CATCH;
  END; 
  IF @retry <> -5 BEGIN 
     RAISERROR(@err_msg,16,1); EXEC admin_ch.proc_add_log_error @err_msg; RETURN;
  END; 
всё что надо блокирую... запускал тесты, одновременно с нескольких клиентов циклами эти процедурки.. всё работает как часы..
в клиенте, после каждой модификации в базе
вызываю процедуру
CREATE PROCEDURE admin_ch.proc_check_error_blocked @proc_name VARCHAR(255) 
AS
BEGIN
  DECLARE @err_msg VARCHAR(500);
  IF @@TRANCOUNT > 0 BEGIN -- если есть висящая транзакция
     SET @err_msg = 'После выполнения процедуры "'+@proc_name+
         '" обнаружена зависшая транзакция, которая была отменена.'+
         +CHAR(13)+CHAR(10)+
         +'Номер ошибки:'+ CONVERT(VARCHAR, ERROR_NUMBER())
         +CHAR(13)+CHAR(10)+
         'Проверьте последние введённые данные.'
     RAISERROR (@err_msg,16,1);
     -- откатываем
     ROLLBACK;
     -- делаем запись в логах
     EXEC admin_ch.proc_add_log_rec 3, @err_msg; 
  END;
END
также перед каждым пуком проверяю есть ли коннект, или если нет, то сперва восстанавливаю, и только потом даю работать дальше... везде try...except...finally..
я уж не знаю что ещё можно сделать "более надёжным"...
но тем не менее, даже по логам работы, видно, что выпадают "куски" времени... 20мин..1 час...
как раз те моменты, когда вводили потерянные данные (со слов пользователей)...
но опять, по тем же логам, не вылазиет ни одной ошибки из-за незавершенной транзакции, или взаимоблокировки...
у клиента свои логи в файло... там тоже ничего подозрительного (
на руках бумажки с распечатками отчётов, по которым видно что данные были в базе.
и удалять данные из базы нельзя, они там только помечается удалённым...

по рассказам пользователей, создаётся впечатление, что происходит, прям какой-то таинственный rollback за 20...30 минут работы... выявляется после перезапуска клиента (и/или перезагрузки сервера)

пару раз, по пол дня сидел у них, пытался поймайть... какую-нить висящую блокировку (через монитор студии для sqlexpress)... ничего подозрительного...

в чём может быть причина подобного полтергейста?
18 авг 09, 20:33    [7553691]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
а "что надо блокирую" - это что?
Delphi то точно отправляет данные? а не в кеше гденибудь там хранится?
чудес не бывает таких..

для спящего время бодрствования равносильно сну
18 авг 09, 20:38    [7553698]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 21494
Кифирчик,

Попробуйте делать бэкапы базы с определенным интервалом (например раз в 15 минут). Потом, определив пропавший интервал времени, можно посмотреть по этим срезам - а был ли он вообще в базе или это только кажется :)

Потом можно думать дальше.
18 авг 09, 20:44    [7553710]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3197
Небось с клиента транзакциями рулите, да закрывать забываете, в результате чего закрытие или падение проги, равно как обрыв коннекта (по любой из вагона причин) дает роллбэк всего, что было сделано в этой сессии.
18 авг 09, 20:48    [7553717]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3197
Да, а еще есть такая очень подлая штука, как
set implicit_transactions on
Смотреть профайлером свойства соединений из вашего клиента.
18 авг 09, 20:50    [7553722]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 909
в делфи никаких кэшев нет... да и зачем... с прогой 3 человека работают... база.. объёмы смешные... 150 метров..
примерно такая схема работы..

     sp := TADOStoredProc.Create(nil);
     sp.Connection := conn;
     try
       sp.ProcedureName := '[men_ch].[proc_add_men2]';
        sp.Parameters.CreateParameter('score_charnum'  ,ftString  , pdInput,  10 , score_item.score_charnum );
        sp.Parameters.CreateParameter('score_descr'    ,ftString  , pdInput, 100 , score_item.score_descr);
        ....
        sp.Open;
        score_id := sp.FieldByName('score_id').AsInteger;
        sp.Close;
     finally
       // фукнция вызывает admin_ch.proc_check_error_blocked описанную в 1-м посте
       CheckForLostTransaction(conn, sp.ProcedureName);
       sp.Free;
     end;

блокирую что надо - ну.. это примерно...
когда перед модификацией таблицы
SELECT * FROM men_ch.men_transact_list WITH(TABLOCK)

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

и, если предположить что дело в блокировках, то почему они не выявляются блоком TRY CATCH, @@TRANCOUNT равен нулю... и пользователи успешно пол часа продолжают вбивать данные... этож вроде не версионник...

если всё-таки дело в блокировке... то выходит то что я применяю для их отлова - не эффективно? какие другие есть способы?
18 авг 09, 20:53    [7553731]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 909
Ennor Tiegael
Небось с клиента транзакциями рулите, да закрывать забываете, в результате чего закрытие или падение проги, равно как обрыв коннекта (по любой из вагона причин) дает роллбэк всего, что было сделано в этой сессии.

не.. все транзакции исключительно в процедурах... (
18 авг 09, 20:55    [7553735]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 909
Shocker.Pro
Кифирчик,

Попробуйте делать бэкапы базы с определенным интервалом (например раз в 15 минут). Потом, определив пропавший интервал времени, можно посмотреть по этим срезам - а был ли он вообще в базе или это только кажется :)

Потом можно думать дальше.

хм...
так завтра и сделаю... щас накатаю скрипты чтоб каждые 15 минут бэкап базы делать и жать его...
18 авг 09, 21:02    [7553748]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
1. навесьте триггер на таблицу INSTEAD OF DELETE и фсе. там уж точняк если есть удаления - никуда не уйдут.
2. или навесить паблик запрет удалений. будет вываливаться с ошибкой.

для спящего время бодрствования равносильно сну
18 авг 09, 21:03    [7553751]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
flexgen
Member

Откуда: Город на песке
Сообщений: 765
Триггеры на таблицах имеются? Если да - что именно делают? Может, jobs имеются, которые данные удаляют?
18 авг 09, 23:29    [7554061]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Ennor Tiegael
Небось с клиента транзакциями рулите...
Это смертный грех, я так понимаю?
18 авг 09, 23:59    [7554101]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 909
flexgen
Триггеры на таблицах имеются? Если да - что именно делают? Может, jobs имеются, которые данные удаляют?

Триггер только один, и появился только вчера... обновляет табличку с "оперативными данными".
джобов нет
19 авг 09, 08:29    [7554366]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3197
Senya_L
Ennor Tiegael
Небось с клиента транзакциями рулите...
Это смертный грех, я так понимаю?
У нас сейчас висит как раз такой кейс. Дельфевый клиент, писаный черти когда еще под BDE, в котором черт ногу сломит. И вот этот продукт эволюции иногда (очень редко, но метко) вставляет клиентский begin tran. Раньше он был написан в этом стиле, когда система была на 2000, сейчас сервер 2005 и я все процедуры переписал на try/catch. Но дельфей я не знаю и код проги не вижу, поэтому там пофиксить не могу.
В результате периодически возникают ситуации, когда 2-3 часа напряженной работы человека уходят в роллбэк, потому как принудительный коммит в его сессию снаружи не подсунуть.
19 авг 09, 09:52    [7554606]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Ennor Tiegael
Senya_L
Ennor Tiegael
Небось с клиента транзакциями рулите...
Это смертный грех, я так понимаю?
У нас сейчас висит как раз такой кейс. Дельфевый клиент, писаный черти когда еще под BDE, в котором черт ногу сломит. И вот этот продукт эволюции иногда (очень редко, но метко) вставляет клиентский begin tran. Раньше он был написан в этом стиле, когда система была на 2000, сейчас сервер 2005 и я все процедуры переписал на try/catch. Но дельфей я не знаю и код проги не вижу, поэтому там пофиксить не могу.
В результате периодически возникают ситуации, когда 2-3 часа напряженной работы человека уходят в роллбэк, потому как принудительный коммит в его сессию снаружи не подсунуть.
Это частный случай. А в-общем и целом, если нет возможности изменять клиента, то мало что поможет при изменениях структуры БД: не будет возможности поправить/оптимизировать запросы, внедренные в код. Много чего нельзя, не только в управление транзакциями.

Я никоим образом не критикую управление транзакциями на стороне сервера. Но как Вы поступаете, когда транзакция многоступенчатая и одной ХП с блоком BEGIN TRY ... все операции "обернуть" не получается. Пример, мне сделать batch update и "пачками" обновить несколько записей. Что делать в этом случае? Запихать все изменения в XML и передать в ХП?

ЗЫ. Интересно в плане обмена опыта, а не на предмет флейма. Кстати, на подобную тему (где управлять транзакциями) флейм уже был в "Сравнении СУБД", емнип.
19 авг 09, 12:03    [7555528]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
invm
Member

Откуда: Москва
Сообщений: 9207
Ennor Tiegael
У нас сейчас висит как раз такой кейс. Дельфевый клиент, писаный черти когда еще под BDE, в котором черт ногу сломит. И вот этот продукт эволюции иногда (очень редко, но метко) вставляет клиентский begin tran. Раньше он был написан в этом стиле, когда система была на 2000, сейчас сервер 2005 и я все процедуры переписал на try/catch. Но дельфей я не знаю и код проги не вижу, поэтому там пофиксить не могу.
В результате периодически возникают ситуации, когда 2-3 часа напряженной работы человека уходят в роллбэк, потому как принудительный коммит в его сессию снаружи не подсунуть.

Если BDE используется только этим приложением, то можно попробовать заменить в MS SQL драйвере BDE (sqlmss32.dll) вхождение BEGIN TRAN на комментарий
19 авг 09, 13:00    [7555894]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 21494
invm

Если BDE используется только этим приложением, то можно попробовать заменить в MS SQL драйвере BDE (sqlmss32.dll) вхождение BEGIN TRAN на комментарий


нельзя, приложение может использовать легальные откаты транзакций
19 авг 09, 13:03    [7555923]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3197
Senya_L
Пример, мне сделать batch update и "пачками" обновить несколько записей. Что делать в этом случае? Запихать все изменения в XML и передать в ХП?
Да, так все и сделал. В результате получился многократный выигрыш по времени выполнения, т.к. каналы узкие и с большой задержкой, соответственно вызов 10 процедур с клиента шел гораздо дольше (а значит, и блокировки удерживались дольше), нежели доп. накладные расходы на парсинг XML.
19 авг 09, 14:38    [7556674]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Ennor Tiegael
Senya_L
Пример, мне сделать batch update и "пачками" обновить несколько записей. Что делать в этом случае? Запихать все изменения в XML и передать в ХП?
Да, так все и сделал. В результате получился многократный выигрыш по времени выполнения, т.к. каналы узкие и с большой задержкой, соответственно вызов 10 процедур с клиента шел гораздо дольше (а значит, и блокировки удерживались дольше), нежели доп. накладные расходы на парсинг XML.
+ OFFTOP
Я так не пробовал делать, но подумывал над такой архитектурой (с бизнес-логикой полностью на сервере и пакетным обновлением через XML). Потому и интересен чужой опыт. Простите за оффтоп, но еще один вопрос: как следите за изменением версий XML-схем? Клиент остался старый, а БД изменилась. Например в ХП при парсинге ищется тода 'Node9', а клиент передает только до Node8.
В классическом случае ХП с параметрами я получу сообщение об ошибке, мол, такой-то параметр ХП не указан. В случае с XML в тихую получим NULL. Как тут быть?
19 авг 09, 14:49    [7556774]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3197
Senya_L
+ OFFTOP
Я так не пробовал делать, но подумывал над такой архитектурой (с бизнес-логикой полностью на сервере и пакетным обновлением через XML). Потому и интересен чужой опыт. Простите за оффтоп, но еще один вопрос: как следите за изменением версий XML-схем? Клиент остался старый, а БД изменилась. Например в ХП при парсинге ищется тода 'Node9', а клиент передает только до Node8.
В классическом случае ХП с параметрами я получу сообщение об ошибке, мол, такой-то параметр ХП не указан. В случае с XML в тихую получим NULL. Как тут быть?
+ RE: OFFTOP
Странный вопрос. Такое ощущение, что контролировать схему БД вы еще как-то в состоянии, но вот версии клиентского софта остаются полностью на их усмотрение. Типа, не хочу обновляться - и не буду?
Ну да, получит NULL (либо будут отсутствовать строки в методе .nodes(), но так схему лучше не проектировать, это не дает никаких особых преимуществ, а выйти боком может в любой момент). В зависимости от того, обязательна новая функциональность или опциональна, в БД оный NULL может быть принят (переходный период, соотв. поле nullable, или есть дефолт), либо не принят, и тогда сообщение об ошибке будет, конечно, несколько неочевидным.
У нас клиенты - наши же сотрудники, все они под контролем, поэтому при появлении обязательного функционала диспетчеры дают им команду обновиться - у них это занимает от силы несколько минут, после чего они продолжают работу без проблем. В любом случае, можно придумать какой-либо механизм уведомления о новых версиях, потому что иногда, действительно, обновления сервера и клиента приходится делать синхронно.
19 авг 09, 21:26    [7558760]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Ennor Tiegael
Странный вопрос. Такое ощущение, что контролировать схему БД вы еще как-то в состоянии, но вот версии клиентского софта остаются полностью на их усмотрение. Типа, не хочу обновляться - и не буду?
Ну да, получит NULL (либо будут отсутствовать строки в методе .nodes(), но так схему лучше не проектировать, это не дает никаких особых преимуществ, а выйти боком может в любой момент). В зависимости от того, обязательна новая функциональность или опциональна, в БД оный NULL может быть принят (переходный период, соотв. поле nullable, или есть дефолт), либо не принят, и тогда сообщение об ошибке будет, конечно, несколько неочевидным.
У нас клиенты - наши же сотрудники, все они под контролем, поэтому при появлении обязательного функционала диспетчеры дают им команду обновиться - у них это занимает от силы несколько минут, после чего они продолжают работу без проблем. В любом случае, можно придумать какой-либо механизм уведомления о новых версиях, потому что иногда, действительно, обновления сервера и клиента приходится делать синхронно.[/spoiler]
Для Вас странный, потому что у Вас все экземпляры клиентов под контролем, я так понимаю. А если они разбросаны географически и юридически?
В любом случае, подход интересный. Просто подумалось, что и подводные камни есть. А указанный пример - это единственное, что пришло на ум в тот момент. Ладно, надо самому попробовать.
19 авг 09, 21:59    [7558827]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 21494
Senya_L
Для Вас странный, потому что у Вас все экземпляры клиентов под контролем, я так понимаю. А если они разбросаны географически и юридически?


У меня этот вопрос решается просто, если возникло критическое обновление БД, номер версии БД увеличивается и, клиент просто отказывается запускаться без обновления.
20 авг 09, 00:49    [7559118]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 21494
А последнее время использую еще и такую технологию. При подготовке критического обновления базы, заранее готовится клиент, который может работать и со старой версией и с новой. Ветка выбирается в зависимости от определенного флага в базе. У пользователей есть время обновить клиента, который продолжает работать со старой базой. При обновлении базы флаг меняется и начинает работать другая ветка в клиенте. Старая ветка вычищается в очередной версии клиента (уже не к спеху).
20 авг 09, 00:54    [7559129]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
toto9
Guest
Пропадают данные в одной таблице или в нескольких?
20 авг 09, 02:24    [7559198]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
toto9
Guest
Триггеры есть?
Раньше подобное случалось? Недоброжелателей-админов нет?
Приведите пару примеров процедур.
20 авг 09, 02:27    [7559202]     Ответить | Цитировать Сообщить модератору
 Re: Куда могут пропадать данные?  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18323
А зачем разделили процедурки изменений и проверку на @@TRANCOUNT? А если у вас сессия на клиенте новая откроется и проверка на транкаунт уже будет там? А старая сессия с не закрытой транзакцией подвиснет до закрытия программы.

Пишите в начале каждой процедуры
if @@TRANCOUNT>0 ROLLBACK TRAN;
Если конечно вы не используете вложенные транзакции.

И вы полностью уверены в Try Catch? Мне кажется был баг в том что при некоторых ошибках процедура останавливалась не переходя в Catch.
Я по старинке делаю set Xact_Abort on - не красиво, но надежно.
20 авг 09, 11:10    [7560331]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить