Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Одновременный COMMIT в SQLServer и AS
|
|||
|---|---|---|---|
|
#18+
Триггером собираются данные в таблице для инкрементального апдейта куба. Выполняется ДТС пакет, в котором производится: - подготовка данных для процессинга - инкрементальный процессинг - удаление обработанных данных Как сделать одновременное подтверждение транзакции так, чтобы если данные успешно закачались в куб, то они и гарантированно удалились бы из таблицы, а если по какой-то причине нет возможности удалить обработанные строки (разрыв соединения или др.), то транзакция на AS тоже откатилась бы. Ведь если не удалить обработанные данные, то в следующий раз они закачаются повторно и будет всё плохо... Или как по-другомы выйти из этой ситуации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2004, 15:55 |
|
||
|
Одновременный COMMIT в SQLServer и AS
|
|||
|---|---|---|---|
|
#18+
ИМХО данными средствами низя. Разве что через DSO. После 3-го SP там есть транзакции на clsDataBase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2004, 20:44 |
|
||
|
Одновременный COMMIT в SQLServer и AS
|
|||
|---|---|---|---|
|
#18+
В догонку еще вариант. Не парится с этими транзакциями, а просто иметь табличку из которй идет inc.update и перед подготовкой данных\процессом делать ей truncate (n-ое кол-во раз для надежности). Так не должно быть дубликатов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2004, 21:11 |
|
||
|
Одновременный COMMIT в SQLServer и AS
|
|||
|---|---|---|---|
|
#18+
А вы не пробовали установить Join transaction if present для Workflow Properties всех заданий? Вроде как именно для этого и предназначено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2004, 23:43 |
|
||
|
Одновременный COMMIT в SQLServer и AS
|
|||
|---|---|---|---|
|
#18+
... с другой стороны транзакции, особенно distributed, желательно иметь как можно короче. Я делаю следующим образом: 1. Чищу временные таблицы в Data Warehouse 2. Закачиваю в них изменения из OLTP 3. Удаляю данные в OLTP, если дизайном там был предусмотрен буфер для дневных изменений (похоже это ваш случай) 4. Конвертирую/преобразовываю данные во временных таблицах 5. Заливаю из временных таблиц в DWH star schema 6. Обновляю OLAP (Incremental использует фильтр на fact по audit dimension) Каждый шаг протоколиуется (Audit dimension в DWH; одна запись на весь процесс). Если что-то сбилось, то во временных таблицах есть все необходимое, чтобы разобраться что произошло и исправить. В зависимость от ваших объемов, объединение 2 и 3 одной транзакцией может быть очень накладным и даже нежелательным (например блокировка на таблицу не позволит триггеру записать новые изменения, и триггер откатит транзакцию). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2004, 10:56 |
|
||
|
Одновременный COMMIT в SQLServer и AS
|
|||
|---|---|---|---|
|
#18+
Андрей НикифоровА вы не пробовали установить Join transaction if present для Workflow Properties всех заданий? Вроде как именно для этого и предназначено. Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2004, 11:53 |
|
||
|
Одновременный COMMIT в SQLServer и AS
|
|||
|---|---|---|---|
|
#18+
Я такую задачу решал, подготавливая для инкрементального апдейта табличку в которую копировал те, записи, которые еще не добавлялись в кубю Последние данные из куба брал путем выполнения openquery с mdx запросом к кубу. Конкретно у меня время в таблице вактов монотонно возрастало, поэтому я брал по аремени, в других случаях, возможно, можно попробовать использовать автоинкрементное поле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2004, 12:23 |
|
||
|
|
start [/forum/topic.php?fid=49&msg=32706875&tid=1872211]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
131ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 278ms |
| total: | 514ms |
| 0 / 0 |
