Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как оценить?
|
|||
|---|---|---|---|
|
#18+
ASE 12.5 Извините за глупый вопрос, я не волшебник, я только учусь. Есть база, в которой есть Таблица1 и Таблица2, ну и др. таблицы. Хочу добавить: в Таблицу1 - примерно 5млн операций, в Таблицу2 - примерно 20 млн. Сейчас идет запрос на добавление в Таблицу1. Вопрос - как мне понять , что эффективней - последовательное добавление в эти таблицы или параллельное, т.е. стоит ли сейчас запускать запрос на добавление в Таблицу2. Куда мне нужно посмотреть для этого? Или и так понятно, что лучше последовательно? Почему? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 10:49 |
|
||
|
Как оценить?
|
|||
|---|---|---|---|
|
#18+
А как добавляются записи (bcp, select into,insert into и тд и тп)? Т е операция logged или non logged. Если logged, то однозначно последовательное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 10:56 |
|
||
|
Как оценить?
|
|||
|---|---|---|---|
|
#18+
Если точнее, то сначала Таблица1 и Таблица2 создаются на основе разных источников - select into (чтобы быстрее запихать основную массу операций), а потом добавляется по относительно небольшому кусочку операций и туда, и туда, т.е. примерно так. select into в Таблицу1 (4,3 млн операций) insert into в Таблицу1 (0.5 млн) select into в Таблицу2 (13 млн операций) insert into в Таблицу2 (2 млн) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 11:05 |
|
||
|
Как оценить?
|
|||
|---|---|---|---|
|
#18+
Все таки IMHO последовательно (иначе по идее лог можно переполнить) PS Ну и раз таблицы созданы select into - то на них очевидно еще не повешаны индексы и всяческие констрейнты, наличие которых "затормаживало" операцию вставки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 11:11 |
|
||
|
Как оценить?
|
|||
|---|---|---|---|
|
#18+
voooВсе таки IMHO последовательно (иначе по идее лог можно переполнить) Это абсолютно все равно для лога. Главное - транзакции закрывать. Лучше всего BCP-ить внутрь, при этом в режиме FAST BCP, без индексов и триггеров на таблице. Таблицу чтобы распарралелить BCP надо распартицировать на столько партиций, сколько будет процессов BCP. Обычно делают по числу Engine. Или по кол-ву файлов с данными (их тоже надо поделить на N частей). И нужно указывать еще парамерт спец. для BCP. Я не понял вашу схему заполнения данных, зачем там еще insert, если уже есть select into ... Но если нужно ускорить вставку данных и вы хотите распарралелить это дело, то нужно создать партиции на APL, или иметь таблицу как DOL. Но по-моему распартицированный APL будет побыстрее, поскольку там поиск последней страницы идет через sysindexes , а не через OAM. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 12:31 |
|
||
|
Как оценить?
|
|||
|---|---|---|---|
|
#18+
Это абсолютно все равно для лога. Главное - транзакции закрывать. это чтож - закоммичивание транзакций гарант от непереполнения лога.....? а если она большая? нет - может переполниться....видел такое ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 14:09 |
|
||
|
Как оценить?
|
|||
|---|---|---|---|
|
#18+
vooo Это абсолютно все равно для лога. Главное - транзакции закрывать. это чтож - закоммичивание транзакций гарант от непереполнения лога.....? а если она большая? нет - может переполниться....видел такое Скорее, наоборот. Незакоммичивание гарантирует переполнение. Конечно, надо еще лог чистить, либо автоматическую очистку поставить в базе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 15:45 |
|
||
|
|
start [/forum/topic.php?fid=55&tid=2013127]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 260ms |
| total: | 383ms |
| 0 / 0 |
