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

Откуда:
Сообщений: 1068
Коллеги, помогите методологически, т.с.

Задача следующая:
Имеется некая БД (на MSSQL 2005, но это не важно). ~ 20 операторов одновременно вносят в нее файлы. Исходно файл dbf, но по некоторым причинам на клиенте он конвертируется в xml, в таком виде отдается через in параметр хранимой процедуре и уже через opendataset вносится в целевую таблицу.
Далее, кусок данных внесенных оператором (вносится от ~1 до ~100 тыс. записей) подвергается различным проверкам в частично интерактивном режиме. Т.е. пользователь, в зависимости от результатов проверки запускает те или иные хранимые процедуры, которые помечают данные как пригодные или непригодные к дальнейшей обработке. Через интерфейс, разумеется.
Вплоть до того, что одной из проверок является "посмотреть записи глазами, произвольно решить, что некоторые из них должны быть импортированы не смотря ни на что".
Проверяются таким образом некие не формальные, а фактические ошибки, т.с.
Окончательно, по сигналу оператора, выборка фиксируется. Т.е. каждой записи в таблице проставляется признак "принят/не принят" + еще порождается куча записей в смежных таблицах (таблица с кодами ошибок, таблица с перечнем запущенных проверок и т.д.)

Теперь, собственно вопрос:
Идеально, наверное, было бы разместить куски данных, с которыми работает данный конкретный оператор в tempdb. Но тогда нужно будет поддерживать connect с базой на всём протяжении такой интерактивной работы, иначе при разрыве соединения таблица в tempdb сотрётся, что не очень хорошо.
С другой стороны, это очень нужная фишка, т.к. если оператор аварийно разорвет соединение, необходимо уничтожить всё "черновые" данные, + те, которые были порождены при проверках.
Писать все данные в некую единую целевую таблицу, общую для всех операторов, и живущую постоянно - тем более плохое решение, т.к. замучишься разгребать дедлоки.
С третьей стороны, проверка может быть очень длительной, и должна быть возможность досрочно прекратить ее на определенном шаге, а потом продолжить ее позже (что как бы намекает, что данные должны храниться где-то постоянно).

Короче, помогите советом, как это правильно организовать.
Клиент написан на VB.NET, но это не принципиально, т.к. меня интересует именно общие принципы организации таких операций.
10 май 11, 14:43    [10629577]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
iljy
Member

Откуда:
Сообщений: 8711
uaggster,

большой xml передавать в процедуру довольно затратно, гораздо проще использовать SQLXmlBulkLoad.
Саму схему я бы сделал примерно так: создал постоянную таблицу, в которую заносил записи с указанием оператора и даты. Для каждой записи можно держать флаги типа проверено-не проверено и т.п. При дисконекте из постоянной таблицы зафиксированные изменения не потеряются, если сделать ИД оператора кластерным ключем - дедлоков тоже не будет. Затем после окончания проверок все подтвержденные записи заносятся куда вам там надо, все неподтвержденные удаляются. На сервере на всякий случай вешается задание, которое эту таблицу чистит (например раз в час удаляет все записи, старше суток). Таблицу можно держать в отдельной базе с простым режимом восстановления для снижения нагрузки на журнал и при резервном копировании. Можно даже в tempdb.
10 май 11, 14:54    [10629690]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
Glory
Member

Откуда:
Сообщений: 104751
uaggster
Теперь, собственно вопрос:
Идеально, наверное, было бы разместить куски данных, с которыми работает данный конкретный оператор в tempdb. Но тогда нужно будет поддерживать connect с базой на всём протяжении такой интерактивной работы, иначе при разрыве соединения таблица в tempdb сотрётся, что не очень хорошо.

С чего вдруг "сотрется" НЕвременная таблица ?

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

Взаимоблокировки и мертные блокировки - это разные вещи
10 май 11, 14:56    [10629703]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
uaggster
Member

Откуда:
Сообщений: 1068
iljy, спасибо, обдумаю.

Glory, спасибо. Взаимная блокировка, конечно.

Гм... А как это. Если я создаю таблицу в tempdb, как она может быть не временной?
Вроде ж любые данные, заносимые в tempdb уничтожаются при разрыве коннекта, или я чего то не знаю? Сорри за чайничество.

iljy>если сделать ИД оператора кластерным ключем - дедлоков тоже не будет.
Да нет. Как Glory справедливо указал, я про взаимную блокировку.
Когда у меня оператор (точнее, хп, запущенная им), пытается апдейтить большое количество данных (типа простановки флага "проверка пройдена"), или внесения данных с кодом ошибки в дочернюю связанную таблицу, в случае, когда все операторы пишут в одну постоянную таблицу (со сборкой мусора. Я делаю примерно так, как ты описал, разница в нюансах) - то они постоянно друг друга блокируют, потому что SQLSERVER эскалирует блокировку с уровня строк-страниц на уровень таблицы. Т.к. обновляться может большое количество данных.
10 май 11, 16:51    [10630674]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
iljy
Member

Откуда:
Сообщений: 8711
uaggster
Гм... А как это. Если я создаю таблицу в tempdb, как она может быть не временной?
Вроде ж любые данные, заносимые в tempdb уничтожаются при разрыве коннекта, или я чего то не знаю? Сорри за чайничество.

С какого перепугу? Уничтожаются локальные временные таблицы и табличные переменные. А если таблицу создать как CREATE TABLE ttt, то будет самая обычная таблица. С единственным отличием - tempdb полностью очищается при перезапуске сервера.


uaggster
iljy>если сделать ИД оператора кластерным ключем - дедлоков тоже не будет.
Да нет. Как Glory справедливо указал, я про взаимную блокировку.
Когда у меня оператор (точнее, хп, запущенная им), пытается апдейтить большое количество данных (типа простановки флага "проверка пройдена"), или внесения данных с кодом ошибки в дочернюю связанную таблицу, в случае, когда все операторы пишут в одну постоянную таблицу (со сборкой мусора. Я делаю примерно так, как ты описал, разница в нюансах) - то они постоянно друг друга блокируют, потому что SQLSERVER эскалирует блокировку с уровня строк-страниц на уровень таблицы. Т.к. обновляться может большое количество данных.

Взаимная блокировка - это не настолько страшно. Если по ИД оператора сделать кластерный, то пересечений не будет, а эскалацию можно запретить. Другое дело, что это может работу не ускорить, а замедлить, но это уже надо смотреть реализацию.
Нет, вы конечно можете создавать для каждого оператора собственную таблицу, но скорее всего геморроя из-за динамики вы получите больше.
10 май 11, 17:35    [10630986]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
uaggster
Member

Откуда:
Сообщений: 1068
Спасибо, буду думать.

Никогда не создавал таблиц в tempdb без префикса # или ##. Спасибо, почитаю :-)
11 май 11, 08:30    [10632823]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
bibiskula
Member

Откуда: Пöндус(Инöстрäнный öгент)
Сообщений: 52988
Glory
Взаимоблокировки и мертные блокировки - это разные вещи
В чем же их разность заключаеться?
11 май 11, 12:01    [10634046]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
uaggster
Member

Откуда:
Сообщений: 1068
Я не Glory, но отвечу.
Формально - дедлок - это либо самоблокировка процесса, либо взаимная блокировка 2 или нескольких процессов по кольцу, так, что первый процесс блокирует второй, а второй одновременно с этим - первый.

Нет, у меня всё по-честному. Один блокирует (избыточно), остальные ждут.
Я уже где возможно грязное чтение понапихал...

Коллеги, подскажите, использование уровня изоляции snapshot много ли ресурсов для своей организации потребляет?
(я с MSSQL еще на 2000 прекратил общаться, сейчас вот опять пришлось. Увидел много интересных гитик :-))
12 май 11, 18:30    [10643779]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
iljy
Member

Откуда:
Сообщений: 8711
uaggster
Нет, у меня всё по-честному. Один блокирует (избыточно), остальные ждут.
Я уже где возможно грязное чтение понапихал...

Очень зря. Лучше уменьшить количество блокировок.
uaggster
Коллеги, подскажите, использование уровня изоляции snapshot много ли ресурсов для своей организации потребляет?

Все зависит от интенсивности модификаций.
12 май 11, 18:44    [10643836]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
uaggster
Member

Откуда:
Сообщений: 1068
iljy
Очень зря. Лучше уменьшить количество блокировок.

Вопрос в том как?
13 май 11, 18:27    [10650030]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
iljy
Member

Откуда:
Сообщений: 8711
uaggster
iljy
Очень зря. Лучше уменьшить количество блокировок.

Вопрос в том как?

Как обычно - накладывать только реально необходимые и на минимальное время.
13 май 11, 18:48    [10650140]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
uaggster
Member

Откуда:
Сообщений: 1068
iljy, это совет в стиле "Мыши! Станьте ежиками :-)"
27 май 11, 13:58    [10719574]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно организовать импорт данных в базу?  [new]
iljy
Member

Откуда:
Сообщений: 8711
uaggster
iljy, это совет в стиле "Мыши! Станьте ежиками :-)"

Нет, в стиле "злейший враг человека - это он сам".
27 май 11, 20:02    [10722676]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить