SE: аномалия 'bcheck -y' - PullRequest
Новая
       2

SE: аномалия 'bcheck -y'

1 голос
/ 03 августа 2010

ISQL-SE 4.10.DD6 (DOS 6.22):

Мое приложение имеет следующий сценарий SQL (ОБЗОР КОДА), который мои пользователи выполняют в конце рабочего дня для переоформления таблицы транзакций: 

DATABASE dbfiles;

UNLOAD TO "U:\UNL\ACTIVES.UNL"
   SELECT * FROM transaction
    WHERE trx_type IN ("E","I","C","P")
 ORDER BY trx_cust_fullname,
          trx_last_pymt;

UNLOAD TO "U:\UNL\INACTIVES.UNL"
   SELECT * FROM transaction
    WHERE trx_type IN ("F","R","T","X","V")
 ORDER BY trx_cust_fullname,
          trx_last_pymt DESC;

DROP TABLE transaction;

CREATE TABLE transaction
    (
     trx_store CHAR(2),
     trx_cust_fullname CHAR(30),
     trx_type CHAR(1),
     trx_num SERIAL,
     [...]
    );

LOAD FROM "U:\UNL\ACTIVES.UNL"   INSERT INTO transaction;
LOAD FROM "U:\UNL\INACTIVES.UNL" INSERT INTO transaction;

CREATE CLUSTER INDEX custn_idx ON transaction (trx_cust_fullname);

CREATE UNIQUE INDEX trxn_idx ON transaction (trx_num);

[3 more indexes...]

UPDATE STATISTICS FOR transaction;

После запуска этого сценария: размер TRANS103.DAT составил 882 832 байта, но Размер TRANS103.IDX был всего 22 089 байт!

Хотя этот размер файла IDX мне не понравился, я запросил все строки в таблице транзакций с помощью экрана «Выполнить», все 1083 строки были отображаемыми, некоторые обновлены, добавлены другие и удалены без проблем, завершены вернулся снова и не столкнулся ни с какими проблемами! Затем я все равно запустил 'bcheck -y TRANS103' и получил следующий результат: 

S:\DBFILES.DBS> bcheck –y TRANS103 

BCHECK  C-ISAM B-tree Checker version 4.10.DD6   

C-ISAM File: s:\dbfiles.dbs\trans103 

Checking dictionary and file sizes. 
Index file node size = 512 
Current C-ISAM index file node size = 512 
Checking data file records. 
Checking indexes and key descriptions. 
Index 1 = unique key   
    0 index node(s) used -- 1 index b-tree level(s) used 
Index 2 = duplicates  (2,30,0)  
    42 index node(s) used -- 3 index b-tree level(s) used 
Index 3 = unique key  (32,5,0)  
    29 index node(s) used -- 2 index b-tree level(s) used 
Index 4 = duplicates  (242,4,2)  
    37 index node(s) used -- 2 index b-tree level(s) used 
Index 5 = duplicates  (241,1,0)  
    36 index node(s) used -- 2 index b-tree level(s) used 
Index 6 = duplicates  (46,4,2)  
    38 index node(s) used -- 2 index b-tree level(s) used 
Checking data record and index node free lists. 

ERROR: 177 missing index node pointer(s) 
Fix index node free list ? yes 

Recreating index node free list. 
Recreating index 6. 
Recreating index 5. 
Recreating index 4. 
Recreating index 3. 
Recreating index 2. 
Recreating index 1. 
184 index node(s) used, 177 free -- 1083 data record(s) used, 0 free

Таким образом, после bcheck его размер .IDX увеличился до 122 561 байта, что говорит о правильном размере, поэтому я вернулся к «Выполнению», повторяя предыдущие тесты без проблем. Из любопытства я снова запустил bcheck, и он повторил те же результаты, что и первый bcheck, который я запускал! .. как если бы 1-й bcheck никогда не ремонтировал стол! восстановлен "? .. Может ли это быть как-то связано с индексом кластера?

Ответы [ 2 ]

0 голосов
/ 08 августа 2010

Итак, чтобы обойти проблемы, упомянутые выше, я не создавал кластеризованные индексы, а создал некластеризованные.Теперь все таблицы выглядят нормально, когда я их проверяю, но мне нужны кластерные индексы! .. Хорошо ли запускать bcheck для всех файлов данных из сценария sql в isql> query-language> run или какОпция меню sysmenuitems, когда работает механизм SE и открыты файлы каталога? .. Раньше я запускал bcheck для всех файлов .DAT, включая системные каталоги, из приглашения ОС, пока двигатель не выгружался.

0 голосов
/ 06 августа 2010

Я работал с Informix несколько лет назад, но не недавно. Вы пробовали bcheck на столе, когда у вас есть только один индекс? Это обсуждение и еще одно здесь заставляют меня думать, bcheck исправляет один (сломанный?) Индекс за раз. Надеюсь, это поможет.

...