Короче, через 2 часа срубил я процесс бекапа. Размер файла бекапа так и оставался 7.3 МБ, gbak висел на все той же строчке writing data for table H_TOVAR.
Dimitry Sibiryakovmiwaonlineshow table h_tovar;
Покажи ещё gstat -i -r -t H_TOVAR
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.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
miwa@worknote:~$ sudo fbstat -i -r -t H_TOVAR localtest1
Database "/usr/database/localtest1.fdb"
Database header page information:
Flags 0
Checksum 12345
Generation 816
Page size 8192
ODS version 11.2
Oldest transaction 765
Oldest active 766
Oldest snapshot 766
Next transaction 787
Bumped transaction 1
Sequence number 0
Next attachment ID 23
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Nov 11, 2013 10:11:44
Attributes force write
Variable header data:
Sweep interval: 20000
*END*
Database file sequence:
File /usr/database/localtest1.fdb is the only file
Analyzing database pages ...
H_TOVAR (206)
Primary pointer page: 507, Index root page: 508
Average record length: 0.00, total records: 555643
Average version length: 60.90, total versions: 555643, max versions: 1
Data pages: 6881, data page slots: 8585, average fill: 94%
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 6880
Index H_TOVAR_IDX1 (0)
Depth: 3, leaf buckets: 778, nodes: 555644
Average data length: 0.31, total dup: 528434, max dup: 3241
Fill distribution:
0 - 19% = 3
20 - 39% = 254
40 - 59% = 380
60 - 79% = 134
80 - 99% = 7
Index H_TOVAR_IDX2 (1)
Depth: 3, leaf buckets: 768, nodes: 555644
Average data length: 0.20, total dup: 528429, max dup: 3241
Fill distribution:
0 - 19% = 5
20 - 39% = 218
40 - 59% = 435
60 - 79% = 102
80 - 99% = 8
Index H_TOVAR_IDX3 (2)
Depth: 2, leaf buckets: 751, nodes: 555644
Average data length: 0.05, total dup: 532486, max dup: 121404
Fill distribution:
0 - 19% = 1
20 - 39% = 304
40 - 59% = 349
60 - 79% = 91
80 - 99% = 6
Index H_TOVAR_IDX6 (3)
Depth: 2, leaf buckets: 347, nodes: 555644
Average data length: 0.01, total dup: 555638, max dup: 106072
Fill distribution:
0 - 19% = 2
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 344
Index PK_H_TOVAR (4)
Depth: 2, leaf buckets: 415, nodes: 555644
Average data length: 1.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 413
kdvА то может у тебя на одном из столбцов те самые 2млн записей имеют одно значение. А значит сервер при сборке мусора будет мучительно гонять эти страницы туда-сюда, в мелком кэше классика.
Нет, данные должны быть разные. Разве что в поле CHANGE_TIMESTAMP в случае синтетического наполнения таблицы будет только 10 разных значений из-за того, что для его наполнения используется current_timestamp, а сама таблица h_tovar наполняется как десятикраный повтор запроса insert into h_tovar ... select ... from m_tovar.
kdvЯ бы еще посмотрел на количество операций I/O этого процесса. База хоть и 225 мб, а вот судя по длительности сборки мусора, там ввода-вывода могут оказаться гигабайты.
Разве что позже - сейчас "для чистоты експеримента" наново набью теми же данными ту же таблицу и запущу бекап параллельно с iotop.
Хотя, вот нашел в одной из консолей; запускалось в случайные моменты времени с целью посмотреть дисковую активность:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
miwa@worknote:~$ sudo iotop -b -o -n 1
Total DISK READ: 0.00 B/s | Total DISK WRITE: 261.45 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
18797 be/4 root 0.00 B/s 522.89 K/s 0.00 % 0.68 % gbak -v -b -user sysdba -pass ********* localtest1 lt1.gbk
miwa@worknote:~$ sudo iotop -b -o -n 1
Total DISK READ: 0.00 B/s | Total DISK WRITE: 281.63 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
18797 be/4 root 0.00 B/s 281.63 K/s 0.00 % 0.35 % gbak -v -b -user sysdba -pass ********* localtest1 lt1.gbk
miwa@worknote:~$ sudo iotop -b -o -n 1
Total DISK READ: 0.00 B/s | Total DISK WRITE: 219.75 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
18797 be/4 root 0.00 B/s 219.75 K/s 0.00 % 0.29 % gbak -v -b -user sysdba -pass ********* localtest1 lt1.gbk
Завтра будут более упорядоченные результаты, хотя общая картина (доли, максимум единицы процентов IO) изменится вряд ли.
