ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Informix [игнор отключен] [закрыт для гостей] / Help Long Transaction 9.40 ?
20 сообщений из 20, страница 1 из 1
Help Long Transaction 9.40 ?
    #32476486
Vitaliy D
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vitaliy D
Участник
Hi All !
Слетел сервак 9.30 под виндой. Поставил новый 9.40ТС1 (Вин Сервер 2000 SP4)

при залити базы dbimport-ом вылетело вот на этом :

create unique index "informix".pk_ats_call_o on "informix".ats_call_o
(noma,call_beg) using btree ;
*** execute sqlobj
458 - Long transaction aborted.
12204 - Unknown error message -12204.

Что за "%;№% ? Помогите.

ats_call_o - табличка на 116507235 записей по 38 байт каждая .
БД без журнализации ( и откуда ей быть при начальном залитии )
Временные спайсы 2 по 2 Гб.

Я включил режим больших чанков (в 9.40 появилось УРА! )
Пока грешу на это или на временные спайсы.

Какие будут советы . Без индексов - ТРУБА мне :((

С уважением Виталий.
...
Рейтинг: 0 / 0
10.04.2004, 16:20
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32476509
Чемберлен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Чемберлен
Гость
Длинная транзакция - это когда в логических журналах транзакцией занято много места (параметр LTXHWM в 9.40, видимо, по умолчанию имеет значение 80, как и в 9.30, т.е. "много" значит - 80% журналов). Создание индекса - это всегда транзакция (DDL!), независимо от режима журнализации базы. Твой индекс может иметь размер, грубо, порядка (38 (замени на размер ключа) +5 ) * количество_строк, т.е. несколько гигабайт, правда? И все его страницы надо "запомнить" в журналах... Это помимо временных пространств для создания индекса, которых тоже тебе может не хватить...

Отсюда вывод:

Пришли результаты выполнения опций:

onstat -d
onstat -l

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

С наилучшими пожеланиями,

В.К.
http://ln.com.ua/~openxs
...
Рейтинг: 0 / 0
10.04.2004, 17:02
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32476515
Vitaliy D
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vitaliy D
Участник
Спасибо за отклик .

DYNAMIC_LOGS 2
LTXHWM 70
LTXEHWM 80

=============================================
Informix Dynamic Server Version 9.40.TC1 -- On-Line (CKPT REQ) -- Up 21:31:2
1 -- 288768 Kbytes
Blocked:CKPT

Dbspaces
address number flags fchunk nchunks flags owner name
13B0C7D8 1 0x60002 1 1 M B informix rootdbs
13C28D18 2 0x42001 2 1 N TB informix tmp2
13C28E68 3 0x42001 3 1 N TB informix tmp1
3 active, 2047 maximum

Chunks
address chunk/dbs offset size free bpages flags pathname
13B0C928 1 1 0 7250000 3909058 PO-B \\.\I:
13B0CAA0 1 1 0 7250000 0 MO-B \\.\J:
13C28A28 2 2 0 524287 410784 PO-B \\.\t:
13C28BA0 3 3 0 524287 410812 PO-B \\.\s:
3 active, 32766 maximum

Expanded chunk capacity mode: always
========================================

Informix Dynamic Server Version 9.40.TC1 -- On-Line -- Up 21:32:47 -- 288768
Kbytes

Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-2 5 8 3234614 470542 6.87
phybegin physize phypos phyused %used
1:263 500 293 34 6.80

Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-2 0 8 54846 11418 10662 4.8 1.1
Subsystem numrecs Log Space used
OLDRSAM 54846 5487596

address number flags uniqid begin size used %used
13C288A8 1 U-B---- 25 1:763 500 500 100.00
13C288E8 2 U---C-L 26 1:1263 500 378 75.60
13C28928 3 U-B---- 21 1:1763 500 500 100.00
13C28968 4 U-B---- 22 1:2263 500 500 100.00
13C289A8 5 U-B---- 23 1:2763 500 500 100.00
13C289E8 6 U-B---- 24 1:3263 500 500 100.00
6 active, 6 total
...
Рейтинг: 0 / 0
10.04.2004, 17:14
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32476532
Чемберлен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Чемберлен
Гость
Итак, что мы имеем:

- немерянный зеркалированный rootdbs (свободно 3 909 058 страниц
по 4 Кбайта, т.е. ~15 Гбайт, правильно?) из одного огромного чанка...
- два временных DB-пространства по 2 Гбайта (будем надеяться, что они используются, т.к. не все страницы свободны)
- таблицу размером в несколько гигабайт, по которой строится индекс
- и (!) 6 логических журналов по 500 страниц (т.е. в сумме - 12 Мбайт
журнального пространства)... Как поставил "мастер установки", так и осталось

Я не буду комментировать размещение всего в rootdbs (это плохо, но
длинная транзакция не с этим связана...)

Судя по этому:

DYNAMIC_LOGS 2

журналы, при необходимости, должны были выделяться у вас динамически, размером по 2 Мбайта, пока не забили бы весь rootdbs. Хотелось бы увидеть результат onstat -l в тот момент, когда было выдано сообщение о длинной транзакции (кстати, содержимое журнала сообщений за этот период хотелось бы увидеть)... Судя по оставшимся 6 журналам, либо этого (динамического выделеления журналов) почему-то не произошло (что странно), либо динамически выделенные журналы кто-то удалил... (9.30 этого не делал... Может, это вы сделали, но я не верю... Может, 9.40 теперь такой умный...)

В ожидании содержимого журнала сообщений (местонахождение задается параметром конфигурации MSGPATH), могу посоветовать следующее:

Создайте много (скажем, 1000) логических журналов заранее, размером, по 10 Мбайт, например, что даст суммарное журнальное пространство в 10 Гбайт.
Вот после этого, по любому, ваша транзакция длинной не должна быть (если в это время в базе больше никто ничего не меняет)

Сделать это можно с помощью команды:

onparams -a -d rootdbs -s 10000

повторенной 1000 раз :)

И попробовать загрузить базу еще раз.

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

Это так, для начала. Для журналов, по хорошему, надо отдельное DB-пространство делать, на отдельном диске, и добавлять их уже там... Но вам, видимо, не до того.

В.К.
...
Рейтинг: 0 / 0
10.04.2004, 18:10
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32476540
Vitaliy D
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vitaliy D
Участник
Спасибо за советы.
Буду создавать логи. Я так понял надо логические логи.
А Физические логи надо менять в onconfig.myserver ?

То что логи надо создавать на другом диске я знаю.
Но у меня без журнализации же БД. А индексы я редко создаю :)


Вот логи:

22:27:23 Maximum server connections 1
22:27:23 Checkpoint Completed: duration was 0 seconds.
22:27:23 Checkpoint loguniq 13, logpos 0x62098, timestamp: 206440610

22:27:23 Maximum server connections 1
22:27:24 Checkpoint Completed: duration was 0 seconds.
22:27:24 Checkpoint loguniq 13, logpos 0x63098, timestamp: 206442294

22:27:24 Maximum server connections 1
22:27:24 Checkpoint Completed: duration was 0 seconds.
22:27:24 Checkpoint loguniq 13, logpos 0x64098, timestamp: 206443978

22:27:24 Maximum server connections 1
22:27:25 Aborting Long Transaction: tx 0x13C1A758 username: informix uid: 1
22:32:31 Checkpoint Completed: duration was 7 seconds.
22:32:31 Checkpoint loguniq 13, logpos 0x65018, timestamp: 207018342
...
Рейтинг: 0 / 0
10.04.2004, 18:31
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32476548
Чемберлен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Чемберлен
Гость
Физический журнал (он в Informix один!) тоже надо бы увеличить (он у вас - 500 страниц, вроде):

onparams -p -s 20000

т.е. до размера хоть Мбайт 20, но для этого раньше (в 9.30) надо было
сервер в Quiescent mode переводить и перезапускать, т.е. пользователей
отключать...

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

Журнал сообщений надо за более ранний период. Ищите в нем сообщения о динамическом добавлении Logical Log - должны быть...

Но мы же пока занимаемся быстрым решением проблемы, связанной с созданием индекса, а не настройкой вашей (видимо, запущенной) конфигурации?

И значение параметра DBSPACETEMP, так, на свякий случай, укажите, пожалуйста...

В.К.
...
Рейтинг: 0 / 0
10.04.2004, 18:42
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32476729
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Как вариант, создать индекс до залития записей?
удалить записи, создать индекс, потом записи загрузить load, конечно 116 млн, вливаться с индексом будут гораздно дольше чем без него, и индекс получится не очень.
...
Рейтинг: 0 / 0
11.04.2004, 09:30
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32478039
Vitaliy D
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vitaliy D
Участник
Отож :))
...
Рейтинг: 0 / 0
12.04.2004, 17:34
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32478048
Vitaliy D
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vitaliy D
Участник
Индекс создан !!!

Я просто добавил по совету Гуру, логические логи и перенес их в свой ДВСПАЙС. Физ. Лог тоже был увеличен и перенесен в отдельный личный раздел.
Хотел еще и ТМП спайсов добавить , но не пришлось.

Спасибо за заботу.

P.S.
Если у г. Чемберлена будет желание, можно понастраивать мой запущенный сервак. Буду рад познать правильную настройку сервака. :)

Еще раз спасибо .
С уваженем Виталий (ICQ 19198252)
...
Рейтинг: 0 / 0
12.04.2004, 17:41
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32478791
Чемберлен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Чемберлен
Гость
Ну, вот и хорошо...

Понастраивать? Можно попробовать. Давай, для начала, опубликуем здесь
файл параметров конфигурации (оно же выдается по команде onstat -c).
Глядишь, и настоящие Гуру подтянуться после выходных, им тоже будет интересно...

Дальше будет видно. Но можно уже готовиться выполнять onstat -a в середине напряженного рабочего дня, перенаправлять в файл, паковать результат и слать на почту (hightown@ukr.net). Потом то же самое делать с результатами onstat -g all. Только паковать - обязательно!

Сюда кидать не надо - объем большой, а существенными моментами я поделюсь.

С наилучшими пожеланиями,

В.К.
...
Рейтинг: 0 / 0
13.04.2004, 11:57
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32480867
Vitaliy D
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vitaliy D
Участник
Ok
Доберусь до работы отправлю.
...
Рейтинг: 0 / 0
14.04.2004, 13:02
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32482680
gvf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gvf
Гость
Смотри описание багов #164745, #164873 !!!
Рекомендую использовать версию IBM IDS 9.40.TC3 или выше .....

Попробуй выполнить:
1) { onmode -C disable }.
2) Drop index ...
3) Create index ....

Желаю удачи !!!!
...
Рейтинг: 0 / 0
15.04.2004, 13:44
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32486848
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
В описании утилиты видим, что:

onmode
-C {start #|stop #|high|low|threshold} Tune Btree scanner resources.

т.е. опция "disable" отсутствует.
А что ты хотел этим сказать ?
...
Рейтинг: 0 / 0
19.04.2004, 18:02
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32487256
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Перечитал в шестой раз, мне кажется в утверждениях есть неточности.

авторСоздание индекса - это всегда транзакция (DDL!), независимо от режима журнализации базы. Твой индекс может иметь размер, грубо, порядка (38 (замени на размер ключа) +5 ) * количество_строк, т.е. несколько гигабайт, правда? И все его страницы надо "запомнить" в журналах...
Кто сказал что страницы индекса надо запомнить в журналах? В физлоге да, но логический лог при создании индекса увеличится байт на 10, в не зависимости от размера индекса.

Это помимо временных пространств для создания индекса, которых тоже тебе может не хватить... Временных пространств не может не хватить, в зависимоти от количества свободного места в них, будет выбран разный метод создания индекса и в online.log будет ворнинг "WARNING: Not enough temp space for parallel index build."
...
Рейтинг: 0 / 0
20.04.2004, 10:00
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32487839
Чемберлен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Чемберлен
Гость
Кто сказал что страницы индекса надо запомнить в журналах? В физлоге да, но логический лог при создании индекса увеличится байт на 10, в не зависимости от размера индекса.


Поставим эксперимент:

1. Создаем базу данных без журнализации:

create database test;

2. Создаем таблицу:

create table t1 (c1 serial, c2 char(300));

3. Наполняем таблицу данными:

insert into t1 valyes(0, '1');
insert into t1 (c2) select c2 from t1;
... несколько раз ...

4. Пусть в результате в таблице 1024 строки:

select count(*) from t1

5. onmode -c (чтобы не задумываться про Fuzzy Checkpoint). onstat -l (переходим на новый журнал)

6. Состояние журналов в этот момент (onstat -l)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
Physical Logging
Buffer bufused  bufsize  numpages numwrits pages/io
  P -2    0          8          401        53         7  .57 
      phybegin physize  phypos   phyused  %used
       100107     500        350        0          0  .00 

Logical Logging
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io
  L -1    0          8          7823       238        48         32  .9         5  .0 
        Subsystem    numrecs  Log Space used
        OLDRSAM       7823       905108 

address  number   flags    uniqid   begin        size     used    %used
ca376a8   1         U-B ----  13       1002fb        500        3     0.60
 
ca376e0   2         U-B ----  14       1004ef        500      482    96.40
 
ca37718   3         U-B ---L  15       1006e3        500        7     1.40
 
ca37750   4         U ---C--  16       1008d7        500        1     0.20
 
ca37788   5         U-B ----  11       100acb        500        3     0.60
 
ca377c0   6         U-B ----  12       100cbf        500        2     0.40
 
  6  active,  6  total

7. Создаем индекс:

create index t1_i1 on t1(c1)

8. Состояние журналов в этот момент (onstat -l)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
Physical Logging
Buffer bufused  bufsize  numpages numwrits pages/io
  P -1    6          8          401        54         7  .43 
      phybegin physize  phypos   phyused  %used
       100107     500        358        14         2  .80 

Logical Logging
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io
  L -2    0          8          7825       241        51         32  .5         4  .7 
        Subsystem    numrecs  Log Space used
        OLDRSAM       7825       905192 

address  number   flags    uniqid   begin        size     used    %used
ca376a8   1         U-B ----  13       1002fb        500        3     0.60
 
ca376e0   2         U-B ----  14       1004ef        500      482    96.40
 
ca37718   3         U-B ---L  15       1006e3        500        7     1.40
 
ca37750   4         U ---C--  16       1008d7        500        2     0.40
 
ca37788   5         U-B ----  11       100acb        500        3     0.60
 
ca377c0   6         U-B ----  12       100cbf        500        2     0.40
 
  6  active,  6  total

т.е. стало использовано на одну страницу больше. Судя по Log Space used - 84 байта добавилось (не 10).

Кстати, индекс состоит из пяти страниц (oncheck -pT test:t1):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Index Usage Report for index t1_i1 on test:openxs.t1

                    Average    Average
    Level    Total No. Keys Free Bytes
     ----- -------- -------- ----------
 
         1          1          4         4024 
         2          4        256          740 
     ----- -------- -------- ----------
 
    Total         5        205         1396

9. Удалим индекс и увеличим таблицу:

drop index t1_i1

onstat -l:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
Physical Logging
Buffer bufused  bufsize  numpages numwrits pages/io
  P -2    5          8          415        56         7  .41 
      phybegin physize  phypos   phyused  %used
       100107     500        372        13         2  .60 

Logical Logging
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io
  L -2    0          8          7846       243        53         32  .3         4  .6 
        Subsystem    numrecs  Log Space used
        OLDRSAM       7846       907080 

address  number   flags    uniqid   begin        size     used    %used
ca376a8   1         U-B ----  13       1002fb        500        3     0.60
 
ca376e0   2         U-B ----  14       1004ef        500      482    96.40
 
ca37718   3         U-B ----  15       1006e3        500        7     1.40
 
ca37750   4         U ---C-L  16       1008d7        500        5     1.00
 
ca37788   5         U-B ----  11       100acb        500        3     0.60
 
ca377c0   6         U-B ----  12       100cbf        500        2     0.40
 
  6  active,  6  total

Добавилось, но тут еще контрольная точка обработалась...

insert into t1 (c2) select c2 from t1;
... несколько раз ...

Пусть в результате в таблице - 8192 строки.

10. Создал индекс и не заметил небольшой некорректности эксперимента...

Давайте снова удалим индекс:

drop index t1_i1

onstat -l:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
Physical Logging
Buffer bufused  bufsize  numpages numwrits pages/io
  P -1    1          8          807        106        7  .61 
      phybegin physize  phypos   phyused  %used
       100107     500        255        17         3  .40 

Logical Logging
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io
  L -1    0          8          8368       256        63         32  .7         4  .1 
        Subsystem    numrecs  Log Space used
        OLDRSAM       8368       930184 

address  number   flags    uniqid   begin        size     used    %used
ca376a8   1         U-B ----  13       1002fb        500        3     0.60
 
ca376e0   2         U-B ----  14       1004ef        500      482    96.40
 
ca37718   3         U-B ----  15       1006e3        500        7     1.40
 
ca37750   4         U ---C-L  16       1008d7        500       16     3.20
 
ca37788   5         U-B ----  11       100acb        500        3     0.60
 
ca377c0   6         U-B ----  12       100cbf        500        2     0.40
 
  6  active,  6  total

create index t1_i1 on t1(c1)

onstat -l:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
Physical Logging
Buffer bufused  bufsize  numpages numwrits pages/io
  P -2    6          8          807        107        7  .54 
      phybegin physize  phypos   phyused  %used
       100107     500        264        14         2  .80 

Logical Logging
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io
  L -3    0          8          8370       257        64         32  .6         4  .0 
        Subsystem    numrecs  Log Space used
        OLDRSAM       8370       930284 

address  number   flags    uniqid   begin        size     used    %used
ca376a8   1         U-B ----  13       1002fb        500        3     0.60
 
ca376e0   2         U-B ----  14       1004ef        500      482    96.40
 
ca37718   3         U-B ----  15       1006e3        500        7     1.40
 
ca37750   4         U ---C-L  16       1008d7        500       18     3.60
 
ca37788   5         U-B ----  11       100acb        500        3     0.60
 
ca377c0   6         U-B ----  12       100cbf        500        2     0.40
 
  6  active,  6  total

т.е. стало использовано на две страницы больше. Судя по Log Space used - 100 байтов добавилось (не 10).
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Index Usage Report for index t1_i1 on test:openxs.t1

                    Average    Average
    Level    Total No. Keys Free Bytes
     ----- -------- -------- ----------
 
         1          1         30         3712 
         2         30        273          518 
     ----- -------- -------- ----------
 
    Total        31        265          621

Эксперимент был не совсем чистым - там еще фоном Fuzzy Checkpoint обрабатывались, но суть понятна. Можете попытаться проверить более точно.

Итак: действительно, я был неправ в своих расчетах. В базе данных без журнализации в журнал при создании индекса, похоже, если что и записывается, то это - информация об изменениях в таблицах системного каталога (sysindexes, например) и информация о выделении экстентов (chunk freelist). Судя по эксперименту, и теоретически, объем этой информации таки зависит от размера таблицы, по которой строится индекс (и от размера самого создаваемого индекса). Видимо, как раз за счет изменения chunk freelist.


Временных пространств не может не хватить, в зависимоти от количества свободного места в них, будет выбран разный метод создания индекса и в online.log будет ворнинг "WARNING: Not enough temp space for parallel index build."


Мне кажется, что, даже если индекс и не строится с распараллеливанием, отсортировать ключи таки придется. И, при большой таблице, места в оперативной памяти для этого может не хватить. Соответственно, потребуется временное пространство, и его может не хватать...

Так мне кажется.
...
Рейтинг: 0 / 0
20.04.2004, 14:19
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32487949
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Итак: действительно, я был неправ в своих расчетах. В базе данных без журнализации в журнал при создании индекса, похоже, если что и записывается, то это - информация об изменениях в таблицах системного каталога (sysindexes, например) и информация о выделении экстентов (chunk freelist). Судя по эксперименту, и теоретически, объем этой информации таки зависит от размера таблицы, по которой строится индекс (и от размера самого создаваемого индекса). Видимо, как раз за счет изменения chunk freelist.

Ну я слегка утрировал говоря про 10 байт, как обычно (да и некоторая склонность к преувеличению у меня тоже есть) :)

А если таблицу создать с первичным EXTENT SIZE 10000, то я думаю что количество записей в логическом логе при построении индекса, сильно уменьшится.
...
Рейтинг: 0 / 0
20.04.2004, 15:08
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32487977
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
авторМне кажется, что, даже если индекс и не строится с распараллеливанием, отсортировать ключи таки придется. И, при большой таблице, места в оперативной памяти для этого может не хватить. Соответственно, потребуется временное пространство, и его может не хватать...

Будет записыватся промежуточный результат в индексное пространство.

Со времен ленточных устройств с последовательным доступом, нам достались очень медленные алгоритмы сортировки позволяющие сортировать при очень ограниченном объеме ОЗУ за малое число проходов.
...
Рейтинг: 0 / 0
20.04.2004, 15:15
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32488013
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Итак: действительно, я был неправ в своих расчетах. В базе данных без журнализации в журнал при создании индекса, похоже, если что и записывается, то это - информация об изменениях в таблицах системного каталога (sysindexes, например) и информация о выделении экстентов (chunk freelist).

С журнализацией база или без фиолетово.

А в логический лог при создании индекса будет записываться много чего, можно посмотреть onlog, но в любом случае это небольшой объем по сравнению с размерами индекса.
...
Рейтинг: 0 / 0
20.04.2004, 15:29
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32488272
Чемберлен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Чемберлен
Гость
В любом случае, стандартных 6 журналов по 500 страниц товарищу не хватало... Расчет неправильный, но вывод - верный. Увидел Long Transaction - добавляй журналы.

Про временное пространство - надо подумать и посмотреть...
...
Рейтинг: 0 / 0
20.04.2004, 16:54
| Ответить | Цитировать | Написать  
Help Long Transaction 9.40 ?
    #32488367
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
В любом случае, стандартных 6 журналов по 500 страниц товарищу не хватало... Расчет неправильный, но вывод - верный. Увидел Long Transaction - добавляй журналы.
Конечно правильный вывод, может индекс по такой огромной таблице строился часа 3, там одними чекпоинтами, лог заполнится ;)

Я просто к некоторым фразам придрался, т.к. сам разбираюсь в этом как свинья в апельсинах, а тема мне интересна, особенно в разрезе передачи индекса на секондари (имею некоторые проблемы с созданием многогибайтных индексов в hdr).
...
Рейтинг: 0 / 0
20.04.2004, 17:15
| Ответить | Цитировать | Написать  
20 сообщений из 20, страница 1 из 1
Форумы / Informix [игнор отключен] [закрыт для гостей] / Help Long Transaction 9.40 ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]