restore только метаданных, результир. файл=90210304 байт: затыки по 100 сек. Why ? / Firebird, InterBase

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / restore только метаданных, результир. файл=90210304 байт: затыки по 100 сек. Why ?

8 сообщений из 8, страница 1 из 1

restore только метаданных, результир. файл=90210304 байт: затыки по 100 сек. Why ?

#38560094

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

hi all

Дано:
1) LI-T3.0.0.30876
2) база продакшена, восстанавливаемая из .fbk (созданного в 2.5) через сервисы:

Код: plaintext

1.
2.
3.

$fb30home/bin/gbak $meta $verb -rep -se localhost/$fb30port:service_mgr \
$tgt30/$fbk $tgt30/production30.fdb \
-user sysdba -password masterke

при этом:

Код: plaintext

$meta = -m
$verb = -v

Вывод дублировал в лог с показом меток времени с пом. supertee -tn

3) Изменённые параметры конфига FB-3:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

AuthClient = Legacy_Auth,Srp,Win_Sspi
AuthServer = Legacy_Auth,Srp
BugcheckAbort = 1
DefaultDbCachePages = 1024 K 
ExternalFileAccess = Restrict /var/db/fb30
FileSystemCacheThreshold = 65536K
RemoteServicePort = 3333
TempBlockSize = 128M
TempCacheLimit = 4250000000
TempDirectories = /dev/shm;/tmp # ram drive
UserManager = Legacy_UserManager
WireCrypt = Disabled

Рестор шёл с явными затыками, некоторые были явно больше 1 минуты.
Решил затащить лог в базу (create table external) и, выполнив соотв-щий cast моментов времени, в обычную таблицу с PK = id int - номерами строк лога.

Далее делаю выборку из этой таблицы самых одиозных затыков:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

SQL> select id,txt,t1,t2,datediff(second from t1 to t2) ts 
CON> from  (  select id,left(text,30) txt, dts t1, lead(dts)over(order by id) t2 from fb3rest  )  
CON> where datediff(second from t1 to t2)>=2 
CON>  order by ts desc,id asc ;

          ID TXT                                 T1                        T2                    TS
============ ============ ========================= ========================= =====================
       58248 Thu Feb 13 1 2014-02-13 16:00:42.0000  2014-02-13 16:02:29.0000                    107
      102574 Thu Feb 13 1 2014-02-13 16:03:33.0000  2014-02-13 16:05:08.0000                     95
       58438 Thu Feb 13 1 2014-02-13 16:02:38.0000  2014-02-13 16:03:01.0000                     23
       57955 Thu Feb 13 1 2014-02-13 16:00:21.0000  2014-02-13 16:00:35.0000                     14
       58753 Thu Feb 13 1 2014-02-13 16:03:07.0000  2014-02-13 16:03:19.0000                     12
       58340 Thu Feb 13 1 2014-02-13 16:02:29.0000  2014-02-13 16:02:38.0000                      9
       58054 Thu Feb 13 1 2014-02-13 16:00:35.0000  2014-02-13 16:00:40.0000                      5
       58642 Thu Feb 13 1 2014-02-13 16:03:03.0000  2014-02-13 16:03:07.0000                      4
       58150 Thu Feb 13 1 2014-02-13 16:00:40.0000  2014-02-13 16:00:42.0000                      2
       58540 Thu Feb 13 1 2014-02-13 16:03:01.0000  2014-02-13 16:03:03.0000                      2
      101881 Thu Feb 13 1 2014-02-13 16:03:23.0000  2014-02-13 16:03:25.0000                      2

Строкам с id = 58248, 102574 и 58438 соответствуют следующие "эпсилон-окрестности" лога рестора:

58243...58252

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

$ cat -n fb3rest.log | tail --lines=+58243 | head -10
 58243  Thu Feb 13 16:00:42 2014: gbak:    restoring index PK_TMP_NAB                   13.02.2014 16:00:42
 58244  Thu Feb 13 16:00:42 2014: gbak:    restoring index PK_TMP_EXP                   13.02.2014 16:00:42
 58245  Thu Feb 13 16:00:42 2014: gbak:    restoring index TMP$EXP_P123                 13.02.2014 16:00:42
 58246  Thu Feb 13 16:00:42 2014: gbak:    restoring index TMP$EXP_XCONCEPT             13.02.2014 16:00:42
 58247  Thu Feb 13 16:00:42 2014: gbak:    restoring index TMP$EXP_XPACKET              13.02.2014 16:00:42
  58248  Thu Feb 13 16:00:42 2014: gbak:    restoring index TMP$EXP_XTEXT1               13.02.2014 16:00:42 
 58249  Thu Feb 13 16:02:29 2014: gbak:    restoring index PK_TMP_LIB                   13.02.2014 16:02:29
 58250  Thu Feb 13 16:02:29 2014: gbak:    restoring index TMP$LIB_LCLN                 13.02.2014 16:02:29
 58251  Thu Feb 13 16:02:29 2014: gbak:    restoring index NAG_LIDS2_IDX1               13.02.2014 16:02:29
 58252  Thu Feb 13 16:02:29 2014: gbak:    restoring index NAG_LIDS2_IDX2               13.02.2014 16:02:29

102569...102578

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

$ cat -n fb3rest.log | tail --lines=+102569 | head -10
102569  Thu Feb 13 16:03:33 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 16:03:33
102570  Thu Feb 13 16:03:33 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 16:03:33
102571  Thu Feb 13 16:03:33 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 16:03:33
102572  Thu Feb 13 16:03:33 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 16:03:33
102573  Thu Feb 13 16:03:33 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 16:03:33
 102574  Thu Feb 13 16:03:33 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 16:03:33 
102575  Thu Feb 13 16:05:08 2014: gbak:    activating and creating deferred index FK_NAB13.02.2014 16:05:08
102576  Thu Feb 13 16:05:08 2014: gbak:    activating and creating deferred index FK_NAB13.02.2014 16:05:08
102577  Thu Feb 13 16:05:08 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 16:05:08
102578  Thu Feb 13 16:05:08 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 16:05:08

58433...58442

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

$ cat -n fb3rest.log | tail --lines=+58433 | head -10
 58433  Thu Feb 13 16:02:38 2014: gbak:    restoring index PK_CFGTREATMENT              13.02.2014 16:02:38
 58434  Thu Feb 13 16:02:38 2014: gbak:    restoring index CFGTREATMENT_ID_USR          13.02.2014 16:02:38
 58435  Thu Feb 13 16:02:38 2014: gbak:    restoring index FK_CFGTREATMENT_1            13.02.2014 16:02:38
 58436  Thu Feb 13 16:02:38 2014: gbak:    restoring index CFGTREATMENT_UNQ             13.02.2014 16:02:38
 58437  Thu Feb 13 16:02:38 2014: gbak:     83310 records ignored                       13.02.2014 16:02:38
  58438  Thu Feb 13 16:02:38 2014: gbak:    restoring index PK_PHONES                    13.02.2014 16:02:38 
 58439  Thu Feb 13 16:03:01 2014: gbak:    restoring index PHONES_IDX1                  13.02.2014 16:03:01
 58440  Thu Feb 13 16:03:01 2014: gbak:     92299 records ignored                       13.02.2014 16:03:01
 58441  Thu Feb 13 16:03:01 2014: gbak:    restoring index PK_CFGMESSAGES               13.02.2014 16:03:01
 58442  Thu Feb 13 16:03:01 2014: gbak:    restoring index CFGMESSAGES_STAMP            13.02.2014 16:03:01

Файл рестора (88 Мб) - мизер с точки зрения что файлового кеша линуха, что в сравнении с размером страничного кеша (1024К * 16384) и TempCacheLimit'a.

Объясните, плз, обо что так долго (107 сек!) можно было спотыкаться ?

PS. dimitr, hvlad: ссылку на отресторенную базу могу выслать.

...

Рейтинг:

0 / 0

13.02.2014, 16:52:40

| Ответить | Цитировать | Написать

restore только метаданных, результир. файл=90210304 байт: затыки по 100 сек. Why ?

#38560115

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

PPS. Влияние вывода сообщений и записи их в лог - крайне незначительное.
Вот отметки времени старта и финиша при ресторе с -v и натравкой на него supertee:

Код: 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.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.

$ head fb30_restore_via_svcmgr.log.1 ; tail -30 fb30_restore_via_svcmgr.log.1
20140213_160005 - start restore via service_mgr, fb 3.0
Thu Feb 13 16:00:14 2014: gbak:opened file /var/db/fb30/kuntsevomain_from60.fbk
Thu Feb 13 16:00:14 2014: gbak:transportable backup -- data in XDR format
Thu Feb 13 16:00:14 2014: gbak:         backup file is compressed
Thu Feb 13 16:00:14 2014: gbak:backup version is 9
Thu Feb 13 16:00:14 2014: gbak:created database /var/db/fb30/production30.fdb, page_size 16384 bytes
Thu Feb 13 16:00:14 2014: gbak:started transaction
Thu Feb 13 16:00:14 2014: gbak:restoring domain RDB$1703
Thu Feb 13 16:00:14 2014: gbak:restoring domain RDB$1704
Thu Feb 13 16:00:14 2014: gbak:restoring domain RDB$1705
. . .
Thu Feb 13 16:05:08 2014: gbak:    activating and creating deferred index CFGELEMENT_FK2
Thu Feb 13 16:05:08 2014: gbak:    activating and creating deferred index ZZZ_DETL_FK
Thu Feb 13 16:05:08 2014: gbak:committing metadata
Thu Feb 13 16:05:08 2014: gbak:fixing system generators
Thu Feb 13 16:05:08 2014: gbak:finishing, closing, and going home
20140213_160508 - finish restore via service_mgr, fb 3.0

Database "/var/db/fb30/production30.fdb"
Database header page information:
        Flags                   0
        Generation              738
        System Change Number    0
        Page size               16384
        ODS version             12.0
        Oldest transaction      1
        Oldest active           2
        Oldest snapshot         2
        Next transaction        730
        Sequence number         0
        Next attachment ID      6
        Implementation          HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        1
        Creation date           Feb 13, 2014 16:00:09

    Variable header data:
        Sweep interval:         0
        *END*

А вот что без этого всего (без -v и без supertee), регистрация длительности через time gbak ...:

Код: plaintext

1.
2.
3.

real    4m55.813s
user    0m0.004s
sys     0m0.004s

...

Рейтинг:

0 / 0

13.02.2014, 17:07:26

| Ответить | Цитировать | Написать

restore только метаданных, результир. файл=90210304 байт: затыки по 100 сек. Why ?

#38560181

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

попробуй тоже самое, но без сервисов. Будет медленнее, но будут ли неожиданные задержки?

...

Рейтинг:

0 / 0

13.02.2014, 17:39:57

| Ответить | Цитировать | Написать

restore только метаданных, результир. файл=90210304 байт: затыки по 100 сек. Why ?

#38560305

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

dimitrпопробуй тоже самое, но без сервисов. Будет медленнее, но будут ли неожиданные задержки?Да, они есть и в варианте рестора БЕЗ сервисов. Хотя и выглядят чуть-чуть "добрее":

Код: sql

1.
2.
3.
4.
5.
6.

select id,txt,t1,t2,cast(datediff(second from t1 to t2) as numeric(3)) ts 
from ( select id,substring(text from 36 for 44) txt, cast(dts as time) t1, 
              cast(lead(dts)over(order by id) as time) t2 from fb3rest 
     ) 
where datediff(second from t1 to t2)>=2 
order by ts desc,id asc;

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

    ID TXT                                                     T1            T2      TS
====== ============================================ ============= ============= =======
102577 activating and creating deferred index FK_RE 18:29:33.0000 18:31:07.0000      94
 58270  58913 records ignored                       18:27:12.0000 18:28:31.0000      79
 58467 restoring index PK_FIN_POSTINGS              18:28:39.0000 18:29:02.0000      23
 58677 restoring index IDX_XECDATE1                 18:29:04.0000 18:29:14.0000      10
 57969 restoring index REG_CRM_SRV_TO_REG_DATE_EXTR 18:26:57.0000 18:27:06.0000       9
 58362  7 records ignored                           18:28:31.0000 18:28:39.0000       8
 57893 restoring parameter CONTACT_FULL_NAME for st 18:26:53.0000 18:26:57.0000       4
 58070 restoring index LIB_CONTACTS_LID1            18:27:06.0000 18:27:10.0000       4
 58793 restoring index LIB_LTEXT1                   18:29:14.0000 18:29:18.0000       4
 58169 restoring index PK_NAB_CARS                  18:27:10.0000 18:27:12.0000       2
 58569 restoring index PK_CFGBLOCKING               18:29:02.0000 18:29:04.0000       2
101870 restoring privilege for user REPL            18:29:22.0000 18:29:24.0000       2

Эпсилон-окрестности первых двух затыков:

102572...102581

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

$ cat -n fb3rest.log | tail --lines=+102572 | head -10
102572  Thu Feb 13 18:29:32 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 18:29:32
102573  Thu Feb 13 18:29:32 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 18:29:32
102574  Thu Feb 13 18:29:32 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 18:29:32
102575  Thu Feb 13 18:29:32 2014: gbak:    activating and creating deferred index FK_NAB13.02.2014 18:29:32
102576  Thu Feb 13 18:29:32 2014: gbak:    activating and creating deferred index FK_NAB13.02.2014 18:29:32
 102577  Thu Feb 13 18:29:33 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 18:29:33 
102578  Thu Feb 13 18:31:07 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 18:31:07
102579  Thu Feb 13 18:31:07 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 18:31:07
102580  Thu Feb 13 18:31:07 2014: gbak:    activating and creating deferred index RDB$FO13.02.2014 18:31:07
102581  Thu Feb 13 18:31:07 2014: gbak:    activating and creating deferred index FK_REG13.02.2014 18:31:07

58265...58274

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

$ cat -n fb3rest.log | tail --lines=+58265 | head -10
 58265  Thu Feb 13 18:27:12 2014: gbak:    restoring index NAG_LIDS_IDX2                13.02.2014 18:27:12
 58266  Thu Feb 13 18:27:12 2014: gbak:    restoring index NAG_LIDS_IDX3                13.02.2014 18:27:12
 58267  Thu Feb 13 18:27:12 2014: gbak:    restoring index NAG_LIDS_IDX4                13.02.2014 18:27:12
 58268  Thu Feb 13 18:27:12 2014: gbak:     2741 records ignored                        13.02.2014 18:27:12
 58269  Thu Feb 13 18:27:12 2014: gbak:    restoring index PK_LOG_LNKA                  13.02.2014 18:27:12
 58270  Thu Feb 13 18:27:12 2014: gbak:     58913 records ignored                       13.02.2014 18:27:12
 58271  Thu Feb 13 18:28:31 2014: gbak:    restoring index LOG_LNK_IDX1                 13.02.2014 18:28:31
 58272  Thu Feb 13 18:28:31 2014: gbak:    restoring index PK_LOG_LNK                   13.02.2014 18:28:31
 58273  Thu Feb 13 18:28:31 2014: gbak:     104729 records ignored                      13.02.2014 18:28:31
 58274  Thu Feb 13 18:28:31 2014: gbak:    restoring index LOG_LIN_EID                  13.02.2014 18:28:31

Общее время рестора без сервисов в ФБ-3 осталось почти таким же, как с ними:

Код: 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.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.

$ head fb30_restore_via_svcmgr.log ; tail -30 fb30_restore_via_svcmgr.log
20140213_182642 - start restore via service_mgr, fb 3.0
Thu Feb 13 18:26:46 2014: gbak:opened file /var/db/fb30/kuntsevomain_from60.fbk
Thu Feb 13 18:26:46 2014: gbak:transportable backup -- data in XDR format
Thu Feb 13 18:26:46 2014: gbak:         backup file is compressed
Thu Feb 13 18:26:46 2014: gbak:backup version is 9
Thu Feb 13 18:26:46 2014: gbak:created database /var/db/fb30/production30.fdb, page_size 16384 bytes
Thu Feb 13 18:26:46 2014: gbak:started transaction
Thu Feb 13 18:26:46 2014: gbak:restoring domain RDB$1703
Thu Feb 13 18:26:46 2014: gbak:restoring domain RDB$1704
Thu Feb 13 18:26:46 2014: gbak:restoring domain RDB$1705
. . .
Thu Feb 13 18:31:07 2014: gbak:    activating and creating deferred index CFGELEMENT_FK2
Thu Feb 13 18:31:07 2014: gbak:    activating and creating deferred index ZZZ_DETL_FK
Thu Feb 13 18:31:07 2014: gbak:committing metadata
Thu Feb 13 18:31:07 2014: gbak:fixing system generators
Thu Feb 13 18:31:07 2014: gbak:finishing, closing, and going home
20140213_183107 - finish restore via service_mgr, fb 3.0

Database "/var/db/fb30/production30.fdb"
Database header page information:
        Flags                   0
        Generation              738
        System Change Number    0
        Page size               16384
        ODS version             12.0
        Oldest transaction      1
        Oldest active           2
        Oldest snapshot         2
        Next transaction        730
        Sequence number         0
        Next attachment ID      6
        Implementation          HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        1
        Creation date           Feb 13, 2014 18:26:46

    Variable header data:
        Sweep interval:         0
        *END*

Я также мониторил размер создаваемого .fdb-файла всё это время (к сож-ю, забыл в лог направить, остался только "хвост" вывода).
Для окрестности момента 18:31:07 (затык номер 1) размер если и увеличивался, то скромными темпами:

Код: 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.
27.
28.
29.
30.

20140213_183040 size = 87064576
20140213_183041 size = 87064576
20140213_183042 size = 87064576
20140213_183043 size = 88113152
20140213_183044 size = 88113152
20140213_183045 size = 88113152
20140213_183046 size = 88113152
20140213_183047 size = 88113152
20140213_183048 size = 88113152
20140213_183049 size = 89161728
20140213_183050 size = 89161728
20140213_183051 size = 89161728
20140213_183052 size = 89161728
20140213_183053 size = 89161728
20140213_183054 size = 89161728
20140213_183055 size = 89161728
20140213_183056 size = 89161728
20140213_183057 size = 90210304
20140213_183058 size = 90210304
20140213_183059 size = 90210304
20140213_183100 size = 90210304
20140213_183101 size = 90210304
20140213_183102 size = 90210304
20140213_183103 size = 90210304
20140213_183104 size = 90210304
20140213_183105 size = 90210304
20140213_183106 size = 90210304
 20140213_183107 size = 90210304 
20140213_183108 size = 90210304
20140213_183109 size = 90210304
20140213_183110 size = 90210304

...

Рейтинг:

0 / 0

13.02.2014, 19:01:17

| Ответить | Цитировать | Написать

restore только метаданных, результир. файл=90210304 байт: затыки по 100 сек. Why ?

#38560432

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

я вот что тут нарыл: каким-то мистическим образом влияет размер .fbk, т.е. с данными он или только с метаданными.
Влез сейчас на хост продакшена (там LI-V2.5.3.26546), создал бекап с него, но только метаданных: gbak -b -g -m production.fdb prodmeta.fbk
Затем перенёс файлик prodmeta.fbk (20 Мб) на тестовую тряпку, где делаю эксперименты, и отресторил его силами ФБ-3, с использованием service_mgr.
Ну так вот: затыков НЕ было, рестор прокатил ровно за две минуты:

Код: 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.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.

$ head fb30_restore_via_svcmgr.log ; tail -30 fb30_restore_via_svcmgr.log
20140213_215053 - start restore via service_mgr, fb 3.0
Thu Feb 13 21:50:57 2014: gbak:opened file /var/db/fb30/prodmeta.fbk
Thu Feb 13 21:50:57 2014: gbak:transportable backup -- data in XDR format
Thu Feb 13 21:50:57 2014: gbak:         backup file is compressed
Thu Feb 13 21:50:57 2014: gbak:backup version is 9
Thu Feb 13 21:50:57 2014: gbak:created database /var/db/fb30/production30.fdb, page_size 16384 bytes
Thu Feb 13 21:50:57 2014: gbak:started transaction
Thu Feb 13 21:50:57 2014: gbak:restoring domain RDB$1703
Thu Feb 13 21:50:57 2014: gbak:restoring domain RDB$1704
Thu Feb 13 21: 50:57  2014: gbak:restoring domain RDB$1705
. . .
Thu Feb 13 21: 52:57  2014: gbak:    activating and creating deferred index CFGELEMENT_FK2
Thu Feb 13 21:52:57 2014: gbak:    activating and creating deferred index ZZZ_DETL_FK
Thu Feb 13 21:52:57 2014: gbak:committing metadata
Thu Feb 13 21:52:57 2014: gbak:fixing system generators
Thu Feb 13 21:52:57 2014: gbak:finishing, closing, and going home
20140213_215257 - finish restore via service_mgr, fb 3.0

Database "/var/db/fb30/production30.fdb"
Database header page information:
        Flags                   0
        Generation              738
        System Change Number    0
        Page size               16384
        ODS version             12.0
        Oldest transaction      1
        Oldest active           2
        Oldest snapshot         2
        Next transaction        730
        Sequence number         0
        Next attachment ID      6
        Implementation          HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        1
        Creation date           Feb 13, 2014 21:50:56

    Variable header data:
        Sweep interval:         0
        *END*

Затык в 107 сек тогда можно объяснить только одним: страницы с метаданными размазаны по "большому" .fbk (который с данными и занимает на диске 30'922'183'680 байт).
В этом случае при затыке в 107 сек ФБ ищет их со скоростью = 30922183680 / 107 / 1024 / 1024 = ~275 Mb/sec - очень похоже на скорость последовательного чтения файла.

Только вся эта гипотеза разбивается о реальность: лог backup'a показывает, что сначала создаются ВСЕ таблицы, и только после в них заливаются данные.

Код: 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.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.

gbak:readied database /var/db/firebird/test.fdb for backup
gbak:creating file /var/db/firebird/test.fbk
gbak:starting transaction
gbak:database /var/db/firebird/test.fdb has a page size of 4096 bytes.
gbak:writing domains
gbak:    writing domain RDB$1
gbak:    writing domain RDB$2
gbak:    writing domain RDB$3
gbak:    writing domain RDB$6
gbak:    writing domain RDB$7
gbak:    writing domain RDB$8
gbak:    writing domain RDB$9
gbak:    writing domain RDB$10
gbak:    writing domain RDB$11
gbak:    writing domain RDB$12
gbak:    writing domain RDB$13
gbak:    writing domain RDB$14
gbak:    writing domain RDB$18
gbak:    writing domain RDB$19
gbak:    writing domain RDB$20
gbak:writing shadow files
gbak:writing character sets
gbak:writing collations
gbak:writing functions
 gbak:writing tables
gbak:    writing table T2
gbak:         writing column ID
gbak:         writing column F01
gbak:         writing column F02
gbak:    writing table T
gbak:         writing column ID
gbak:         writing column F01
gbak:         writing column F02 
gbak:writing types
gbak:writing filters
gbak:writing id generators
gbak:    writing generator G value 3000000
gbak:writing stored procedures
. . .
gbak:writing exceptions
gbak:    writing index T_F01
gbak:    writing index T_F02
gbak:    writing index RDB$PRIMARY2
 gbak:    writing data for table T 
gbak:20000 records written
gbak:40000 records written
gbak:60000 records written
gbak:80000 records written
gbak:100000 records written
gbak:120000 records written
gbak:140000 records written

...

Рейтинг:

0 / 0

13.02.2014, 22:14:09

| Ответить | Цитировать | Написать

restore только метаданных, результир. файл=90210304 байт: затыки по 100 сек. Why ?

#38560437

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

Таблоидлог backup'a показывает, что сначала создаются ВСЕ таблицы, и только после в них заливаются данные
а еще он показывает, что индексы пишутся вперемешку с данными. Есс-но, ресторится все в том же порядке, пропуская данные.

...

Рейтинг:

0 / 0

13.02.2014, 22:21:21

| Ответить | Цитировать | Написать

restore только метаданных, результир. файл=90210304 байт: затыки по 100 сек. Why ?

#38560446

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

dimitrТаблоидлог backup'a показывает, что сначала создаются ВСЕ таблицы, и только после в них заливаются данныеа еще он показывает, что индексы пишутся вперемешку с данными. Есс-но, ресторится все в том же порядке, пропуская данные.Тогда затыки при ресторе из одного и того же "большого" .fbk должны быть в одних и тех же местах. Так ?

...

Рейтинг:

0 / 0

13.02.2014, 22:37:13

| Ответить | Цитировать | Написать

restore только метаданных, результир. файл=90210304 байт: затыки по 100 сек. Why ?

#38560452

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

Таблоид,

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

...

Рейтинг:

0 / 0

13.02.2014, 22:45:42

| Ответить | Цитировать | Написать

8 сообщений из 8, страница 1 из 1

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=40&msg=38560115&tid=1563890]:	0ms
get settings:	9ms
get forum list:	10ms
check forum access:	2ms
check topic access:	2ms
track hit:	300ms
get topic data:	10ms
get forum data:	4ms
get page messages:	28ms
get tp. blocked users:	1ms
others:	221ms

total:	587ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы