|
|
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
без. а зачем там параметры? и как это влияет на производительность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 15:06 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
А попробуй :)) Стандартная вставка: берем TIBSQL, сразу пишем в него запрос вида insert into Table (Field1, Field2, ...) values (:param1, :param2, ...); Открываем транзакцию, делаем препаре (один раз), потом присвоение параметров и выполнение запроса в цикле. ЗАкрываем транзакцию. Все. Самое быстрое ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 15:34 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
да, в 4 раза быстрей стало :-) спасибо а еще? может еще что нужно учесть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 15:47 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
итого, около 20 минут весь процесс. по поводу сборки. стоит делать после всего select count*)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 15:48 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
раза три-четыре обновил таблицы, база стала 500 метров. сделал select count(*) from blackiplist сделалось быстро, секунд за 30. сделал select count(*) from blackiplistmp - до сих пор делается. оно и понятно, 3 миллиона записей удалил. вот теперь думаю. может сделать как-то так: create table blackiplisttmp(ip integer not null unique, flag integer) где флаг означает - 0, хз, 1 - добавился, 2 - не изменился. сначала все пометить как 0. каждый ip из файла ищщется в базе. если такой есть, то помечается как 2(не изменился) если нету, добавляется с флагом 1. вот те которые 0 (хз), удалять. остальные реплицировать в рабочую таблицу. таким образо муменьшится фрагментация базы. что думаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 03:19 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Цели и задачи! Нафига count по служебной таблице делать? Если хочешь знать, какие записи (и сколько) добавились в рабочую таблицу - добавь в неё поле CREATE_DATETIME TIMESTAMP DEFAULT 'NOW' NOT NULL. Построй по нему обычный индекс и анализируй когда, сколько и какие записи добавились. Либо сделай LOG рабочей таблицы. И вали в него триггерами то, что потом будешь анализировать. НО НЕ ТРОГАЙ СЛУЖЕБНУЮ. Она - КОНТЕЙНЕР ДЛЯ РЕПЛИКАЦИИ. И не более того. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 08:26 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
да нет :-) мне число строк не нужно. я просто хотел принудительную сборку мусора сделать, чтобы она не началась сама. или я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 08:34 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
А BackUp с флагом сборки мусора не тоже самое? Двух зайцев поймаешь - и мусор собран, и база зарезервирована. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 08:41 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
мне мусор мешает в рабочей версии базы, а не в резервной. для того чтобы избавится таким образом от мусора в рабочей версии базы, мне нужно сделать помле бэкапа еще и восстановление. а это прерывание технологического процесса. не очень хорошо, хотя и возможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 09:03 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
— Backup БД IB может осуществлятся одновременно с работой обычных клиентских программ — Во время backup происходит считывание каждой записи из каждой таблицы в БД. Таким образом, происходит сборка мусора в БД: версии записей или их фрагменты, которые не являются актуальными, уничтожаются. Место из-под удалённых версий освобождается, и оставшиеся данные переупаковываются. — В процессе резервного копирования во время посещения всех записей происходит пересчёт статистики по индексам, что улучшает производительность операций, которые используют эти индексы. Ковязин, Востриков - "Мир InterBase" 2-е издание страница 308. Я думаю, что во время Backup сборка мусора и балансировка индексов происходит как раз в рабочей базе! К тому же Backup гораздо быстрее, чем твой сount, который до сих пор делается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 09:45 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
ну а потом-то что? ну сделаю я бэкап и что? мусор то останется в базе, его тоолько в бэкапе не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 10:14 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
так нельзя ресторе делать. процессы куда конектится будут, пока идет рестор? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 10:34 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Мне вот интересно, ты статеечку таки прочитал, или так и будешь до посинения тр@х@ться?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 12:03 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
тут мне как-то dimitr говорил, что флаг "гарбэйдж коллекшен" иничиирует сборку мусора в рабочей базе, а бэкап в любом случае без мусора будет, так что для сборки мусора в базе достаточно бэкапа с флагом сборки мусора (не нужен рестор), ну и Ковязин зря писать не будет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 12:16 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Мим, вопрос с производительностью при заливке решён. Он никак не врубится в оптимизацию после заливки. Сборка мусора и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 12:18 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Лучше сборку мусора при backup выключать. Процесс backup при сборке мусора очень долгий, ну а если он прервется, то может побиться база. Лучше уж count(*). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 12:24 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
2 FreemanZAV а как база может побиться? бэкап делается как ещё один процесс (типа отдельный запрос), поэтому побьётся снимаемая копия, но не сама база... или я опять чего-то не догоняю?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 12:39 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
to VF. Нет, я про другое говорю. Если прервется не сам процесс backup, а сервер IB/FB по каким-то причинам остановится. Если backup со сборкой мусора в это время происходит то жди беды. Луше сделать быстрый backup (с ключом g), а потом собрать мусор (gfix -sweep к примеру). Вообще говоря, я пробовал прерывать процесс backup со сборкой мусора и база у меня побилась. Больше я не эксперементировал. Попробуй сам несколько раз так сделать и расскажи всем о результатах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 13:05 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Было у меня прерывание процесса backup. Запустился заново - действительно, после этого backup со сборкой мусора не захотел делаться. Так я его отключил и сделал backup без сборки мусора, с игнорированием контрольных сумм и Ignore transaction in Limbo. Но тогда уже restore обязателен. Эта ситуёвина с аварийным прерыванием настолько редка, что напрягаться из-за неё не имеет смысла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 13:26 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
>Эта ситуёвина с аварийным прерыванием настолько редка, что напрягаться из-за неё не имеет смысла. Тогда вообще зачем делать b/r. Ведь ситуация, когда что-то ломается настолько редка... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 13:39 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
FreemanZAVТогда вообще зачем делать b/r. Для оптимизации и повышения производительности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 13:47 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Значит резервные копии - это пережиток прошлого? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 14:01 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Если она делается одновременно с оптимизаций, ну и пусть себе делается, хлеба не просит - может когда-нибудь пригодиться. Так себе - профилактика от гриппа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2004, 14:07 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=32473427&tid=1578868]: |
0ms |
get settings: |
7ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
265ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
91ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 609ms |

| 0 / 0 |
