drop database (около 2 гб ) длится уже более 10 часов / PostgreSQL

ReSQL.ru

2.0.61

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

Гость

Войти | Профиль | Очистить

Нов. | Гор. | Избр.

Написать

Автор*:

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

Тема*:

Сообщение

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

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

Автор:

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

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

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

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

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

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

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

Действия ...

Доб. в избранное
Игнор. тему
Прикреп. тему
Пометить прочит. / непрочит.
Фильтр:
Сообщения автора темы
Сообщение содержит вложения
Сообщение содержит картинки
Сообщение содержит видеоклипы
Сообщение содержит аудиоклипы
Сообщение содержит картинки или видео 18+

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / drop database (около 2 гб ) длится уже более 10 часов / 25 сообщений из 48, страница 1 из 2

все

15.04.2014, 20:56:44

#38615866

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

есть виртуалка (вмварь), на core i5 ноуте.
ей выделено 2 гб озу
в ней psql 8.1.23 (server 9.0.4)
делю дроб базы, база в пару гиг.
дроп идет уже 10 часов.
подключений к ней нету, 100%. так как виртуалка - это клон другого сервера. просто готовлю вм для тестов.
как быть, куда копать?
также тут есть база в 190гб, сейчас чищу таблицы, идет тоже очень медленно. там есть таблицы, где есть 7-9 млн записей статистики, я оставляю несколько тыс записей, но при этом размер базы на диске - меньше не становится, автовакум при этом срабатывал.
я так понимаю надо еще vacum full делать - он поможет?

...

Рейтинг:

0 / 0

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

16.04.2014, 07:17:46

#38616008

дык думать надо

Гость

drop database (около 2 гб ) длится уже более 10 часов

Alexandr Zlobin,

вы таки посмотрите pg_stat_activity

по2: вы бы скинули сколько вам надо в новую "буферную" табличку, транкейтнули старую, потом залили туда из вашей буферной
ну и т.п.

...

Рейтинг:

0 / 0

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

16.04.2014, 09:11:30

#38616060

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

дык думать надоAlexandr Zlobin,
вы таки посмотрите pg_stat_activity

как раз через него и смотрел - к базе которая удаляется - только один запрос - drop database
прошло 18 часов - так и не дропнуло - я ребутнул виртуалку, дальше нет сил ждать.
честно говоря не понимаю что не так.
дык думать надоAlexandr Zlobin,
вы таки посмотрите pg_stat_activity
по2: вы бы скинули сколько вам надо в новую "буферную" табличку, транкейтнули старую, потом залили туда из вашей буферной
ну и т.п.
пробовал, удаление или TRUNCATE - тоже идет очень долго.

...

Рейтинг:

0 / 0

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

16.04.2014, 09:56:35

#38616118

daevy

Гость

drop database (около 2 гб ) длится уже более 10 часов

Alexandr Zlobin,

когда делается drop database, посмотрите в top есть ли там какая активность (CPU%, user, iowait)?

по п.2 попробуйте pgcompactor , обойдется без vacuum full

...

Рейтинг:

0 / 0

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

16.04.2014, 09:58:19

#38616120

daevy

Гость

drop database (около 2 гб ) длится уже более 10 часов

Alexandr Zlobin,

и покажите postgresql.conf той машины где база в 190GB

...

Рейтинг:

0 / 0

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

16.04.2014, 10:56:36

#38616187

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

в top скачет активность по процу
cat с оригинала:

Код: sql

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.

cat orig | grep -v '^#' | grep -v '^;' |sed '/^$/d' | more
                                        # (change requires restart)
                                        # (change requires restart)
                                        # (change requires restart)
max_connections = 1600                  # (change requires restart)
shared_buffers = 10000MB                # min 128kB
temp_buffers = 1024MB
work_mem = 512MB
maintenance_work_mem = 256MB
max_stack_depth = 2MB                   # min 100kB
wal_level = hot_standby                 # minimal, archive, or hot_standby
checkpoint_segments = 100
checkpoint_timeout = 10min
                                # (change requires restart)
archive_command = 'cp %p /opt/postgresql_9/xlog_archive/%f'     # command to use to archive a logfile segment
                                # number of seconds; 0 disables
cpu_tuple_cost = 0.001
cpu_index_tuple_cost = 0.0005
effective_cache_size = 10000MB
log_destination = 'stderr'
logging_collector = on                  # Enable capturing of stderr and csvlog
log_directory = '../log'                # directory where log files are written,
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern,
log_rotation_size = 100MB               # Automatic rotation of logfiles will
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'
                                        #   debug5
                                        #   info
log_connections = off
log_line_prefix = '%m:*:%r:**:%d:***:%u:****: ' # special values:
log_statement = 'none'                  # none, ddl, mod, all
autovacuum_max_workers = 100            # max number of autovacuum subprocesses
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'                     # locale for system error message
lc_monetary = 'en_US.UTF-8'                     # locale for monetary formatting
lc_numeric = 'en_US.UTF-8'                      # locale for number formatting
lc_time = 'en_US.UTF-8'                         # locale for time formatting
default_text_search_config = 'pg_catalog.english'
escape_string_warning = off

с моего

Код: sql

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.

max_connections = 100
shared_buffers = 256MB
effective_cache_size = 768MB
work_mem = 1310kB
maintenance_work_mem = 64MB
checkpoint_segments = 64
checkpoint_completion_target = 0.9
wal_buffers = 7864kB
default_statistics_target = 100

temp_buffers = 128MB
max_stack_depth = 2MB                   # min 100kB
wal_level = hot_standby                 # minimal, archive, or hot_standby
checkpoint_timeout = 10min
                                # (change requires restart)
archive_command = 'cp %p /opt/postgresql_9/xlog_archive/%f'     # command to use to archive a logfile segment
                                # number of seconds; 0 disables
cpu_tuple_cost = 0.001
cpu_index_tuple_cost = 0.0005
log_destination = 'stderr'
logging_collector = on                  # Enable capturing of stderr and csvlog
log_directory = '../log'                # directory where log files are written,
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern,
log_rotation_size = 100MB               # Automatic rotation of logfiles will
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'
                                        #   debug5
                                        #   info
log_connections = off
log_line_prefix = '%m:*:%r:**:%d:***:%u:****: ' # special values:
log_statement = 'none'                  # none, ddl, mod, all
###autovacuum_max_workers = 100            # max number of autovacuum subprocesses
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'                     # locale for system error message
lc_monetary = 'en_US.UTF-8'                     # locale for monetary formatting
lc_numeric = 'en_US.UTF-8'                      # locale for number formatting
lc_time = 'en_US.UTF-8'                         # locale for time formatting
default_text_search_config = 'pg_catalog.english'
escape_string_warning = off

подключился ems sql managerом - там есть конфигурация сервера - и куча параметров. - где они хранятся и могли ли их накрутить?
топ:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4207 postgres 25 0 345m 17m 15m R 98.2 0.9 4:25.49 postmaster

select * from pg_stat_activity;

Код: sql

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

 16389 | voipdb    |    4024 |       10 | postgres | EMS | 91.201.21.1 |       27717 | 2014-04-16 07:06:49.657684+01 | | 2014-04-16 07:21:14.634232+01 | f       | <IDLE>
 16389 | voipdb    |    4207 |       10 | postgres | | |          -1 | 2014-04-16 07:20:06.215493+01 | 2014-04-16 07:47:22.55362+01  | 2014-04-16 07:47:22.55362+01  | f       | DROP DATABASE jiradb_v4 ;
     1 | template1 |    4123 |       10 | postgres | EMS | 91.201.21.1 |       27733 | 2014-04-16 07:13:32.840298+01 | | 2014-04-16 07:33:46.498962+01 | f       | <IDLE>
     1 | template1 |    5035 |       10 | postgres |  ||          -1 | 2014-04-16 07:52:55.513781+01 | 2014-04-16 07:52:58.494665+01 | 2014-04-16 07:52:58.494665+01 | f       | select * from pg_stat_activity;
     1 | template1 |    4284 |       10 | postgres | EMS | 91.201.21.1 |       28007 | 2014-04-16 07:33:49.051944+01 | | 2014-04-16 07:35:47.371176+01 | f       | <IDLE>
(5 rows)

...

Рейтинг:

0 / 0

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

16.04.2014, 11:02:44

#38616197

дык думать надо

Гость

drop database (около 2 гб ) длится уже более 10 часов

Alexandr Zlobinкак раз через него и смотрел - к базе которая удаляется - только один запрос - drop database
прошло 18 часов - так и не дропнуло - я ребутнул виртуалку, дальше нет сил ждать.
честно говоря не понимаю что не так.
смотрите активность,
смотрите логи
чем-то она у вас занимается

как вариант - мог предположить, что модный триггер на ddl пользуете
но вот это автор8.1.23 (server 9.0.4) при обоих вариантах рановато для такого.
вы кстати расскажите, что именно у вас стоит. это легко выясняется с помощью SELECT version();
Alexandr Zlobinпробовал, удаление или TRUNCATE - тоже идет очень долго.
посмотрите ещё триггера. если где-то стояла триггер-репликация, она может и транкейты обвешивать своими триггерами. НУ а прочие событие - по дефолту

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

...

Рейтинг:

0 / 0

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

16.04.2014, 11:10:38

#38616204

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

SELECT version(); version
-------------------------------------------------------------------------------------------------------------------
PostgreSQL 9.0.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50), 64-bit
(1 row)

я , увы, не дба, я админ, все время работал либо с мускулом либо с мсскл, а с постгресом столкнулся недавно

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

[quot дык думать надо]Alexandr Zlobinи не надо пробовать удалять, если времена транкейтов вас не устраивают.
лучше пойдите, прикупите духовое ружьё, бельишко там поменяйте,
короче с достоинством как-то
по мужски
этого стеба не понял. я вижу явную проблему либо настроек - так как перенесено с более мощной конфигурации на более слабую
либо проблемы с самой базой

времена транкейтов - долго - также как удаление, я пробовал очистить таблицу в 1,5 гб весом - тукже не дождался... прошло часов 8...
или это не долго?

...

Рейтинг:

0 / 0

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

16.04.2014, 12:01:32

#38616280

Maxim Boguk

Участник

Откуда: Melbourne, Австралия
Сообщения: 5 148
Рейтинг: 0 / 0

drop database (около 2 гб ) длится уже более 10 часов

[quot Alexandr Zlobin]SELECT version(); version
-------------------------------------------------------------------------------------------------------------------
PostgreSQL 9.0.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50), 64-bit
(1 row)

я , увы, не дба, я админ, все время работал либо с мускулом либо с мсскл, а с постгресом столкнулся недавно

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

дык думать надопропущено...

этого стеба не понял. я вижу явную проблему либо настроек - так как перенесено с более мощной конфигурации на более слабую
либо проблемы с самой базой

времена транкейтов - долго - также как удаление, я пробовал очистить таблицу в 1,5 гб весом - тукже не дождался... прошло часов 8...
или это не долго?

Это все очень долго... у вас какие то проблемы с операционкой или железом
или просто дикая перегрузка по диску... что drop database что truncate занимают секунды (минуты в самом плохом случае)
для начала посмотрите на утилизацию IO на хост системе (я что то думаю что ноутбучный винт штука не быстрая весьма)

...

Рейтинг:

0 / 0

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

16.04.2014, 12:08:33

#38616289

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

я верю что долго.
только что проверил на паре других таблиц truncate - отработало нормально + было заметно как освобождается место
с дропом - таки непонятно, была еще одна тесовая база в 700 мб - удалилась мгновенно.

сейчас делаю полное восстановление папки data (204 гб, на данный винт, проходит за часов 5 вроде, это с учетом того, что на нем же и лежит)
потом поиграюсь еще

есть какие-то варианты проверки всей базы на валидность (побились файлы например или еще что то? )
могут ли влиять параметы внутри сервера? то что показывает ems ? как их увидеть и поменять запросом? (в мускуле я так понимаю это те параметры: mysqladmin variables -uroot -p ) - и какие среди них надо менять, если сервер стал слабее?

...

Рейтинг:

0 / 0

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

16.04.2014, 12:12:44

#38616299

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

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

...

Рейтинг:

0 / 0

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

16.04.2014, 17:16:04

#38616757

Misha Tyurin

Участник

Откуда: Тюмень
Сообщения: 2 279
Рейтинг: 0 / 0

drop database (около 2 гб ) длится уже более 10 часов

Alexandr Zlobin,

коннект у вас висит вероятно к базе этой

...

Рейтинг:

0 / 0

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

16.04.2014, 17:27:26

#38616777

landy

Участник

Сообщения: 1 531
Рейтинг: 0 / 0

drop database (около 2 гб ) длится уже более 10 часов

запустите БД в single mode и вообще на другом порту
Чтобы наверняка у вас никто подключен не был
и попробуйте drop

...

Рейтинг:

0 / 0

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

16.04.2014, 17:40:35

#38616795

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

я без сети запускал - не дропается.
видимо какие-то тригерры или еще какие то внутренние скрипты -как это выловить?

...

Рейтинг:

0 / 0

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

16.04.2014, 17:42:12

#38616799

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

Кстати, если делаешь дамп базы - все тригерры и вставки и тд (насколько знаю - тут в 200гб базе есть вставки на питоне и перле вроде, как мне сказали - что это и где искать - тоже не знаю.) сохраняются?

...

Рейтинг:

0 / 0

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

17.04.2014, 19:52:17

#38618020

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

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

...

Рейтинг:

0 / 0

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

18.04.2014, 04:05:21

#38618212

Maxim Boguk

Участник

Откуда: Melbourne, Австралия
Сообщения: 5 148
Рейтинг: 0 / 0

drop database (около 2 гб ) длится уже более 10 часов

Alexandr Zlobinвчера, по техническим причинам пришлось отложить восстановление.
сейчас начал
подскажите, как проверить есть ли в базе тригерры?
есть ли какие то скрипты\таски во внутреннем кроне?
как проверить есть ли какие то вставки на питоне\перле и тд, к базе?
спасибо

ничего из этого не может мешать drop database
внутреннего крона у postgresql нет (штатного)

...

Рейтинг:

0 / 0

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

18.04.2014, 09:30:00

#38618314

buddy_ekb

Гость

drop database (около 2 гб ) длится уже более 10 часов

Alexandr Zlobinесть виртуалка (вмварь)
Alexandr Zlobinвиртуалка - это клон другого сервера.

скажите, пожалуйста, а ваша виртуалка-клон не linked ли случаем?

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

...

Рейтинг:

0 / 0

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

18.04.2014, 10:25:50

#38618398

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

Maxim Bogukничего из этого не может мешать drop database
внутреннего крона у postgresql нет (штатного)
понял.
когда я делал shell скрипт, который запускался через watch каждые 10 сек, и выполнял обновление в mysql базе.
потом мне дба сказал что будет запускать его в самом мускуле, я не уточнял как, было это давно и было не до этого.
но насколько я понял - есть какой то внутренний механизм запуска подобных вещей в мускуле, и может и в постргнессе - не подскажете как он называется?

buddy_ekbскажите, пожалуйста, а ваша виртуалка-клон не linked ли случаем?

также интересует, примерно сколько у вас в дропаемой базе таблиц и индексов.
не linked, так как это клон физической машины.
индексов - не знаю как посмотреть, таблиц - 107

может есть какой то дебаг режим, что бы отловить почему долго дропается и грузит при этом проц?

сам сервер клонировал с помощью rsync, базу - т.е. папку data мне дали загзипованую, насколько мне обяснили - брали ее с рабочего сервера, не останавливая его, методом rsync-а тоже, в ней лежит в т.ч. файл backup_label
человек который это все делал, уже уволился и проконсультироваться с ним нет возможности

я же запускал по одному из нагугленных мануалов:
chmod -R postgres:postgres /postgresql/data/
pg_controldata /postgresql/data/ | grep "Latest checkpoint" (брал нижние цифры)
pg_resetxlog -o18766860 -x 16674550 -f /postgresql/data/
может тут неправильно?
может есть какой то чек базы, который можно запустить и пусть идет себе ?

...

Рейтинг:

0 / 0

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

18.04.2014, 20:03:35

#38619214

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

я удалять базы пробовал от суперпользователя postgres
попробовал его сделать ownerом на удаляемую базу - не помогло (

...

Рейтинг:

0 / 0

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

18.04.2014, 21:52:04

#38619276

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

добавил лог

log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'

буду думать далее

...

Рейтинг:

0 / 0

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

18.04.2014, 22:03:53

#38619281

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

пофигу... ничего нужного не обнаружил, дроп опять висит

в логе:

2014-04-18 18:54:26.226 BST:*::**::***::****: LOG: database system was not properly shut down; automatic recovery in progress
2014-04-18 18:54:26.365 BST:*::**::***::****: LOG: consistent recovery state reached at 1417/B00BC468
2014-04-18 18:54:26.365 BST:*::**::***::****: LOG: record with zero length at 1417/B00BC468
2014-04-18 18:54:26.365 BST:*::**::***::****: LOG: redo is not required
2014-04-18 18:54:26.473 BST:*::**::***::****: LOG: autovacuum launcher started
2014-04-18 18:54:26.474 BST:*::**::***::****: LOG: database system is ready to accept connections
2014-04-18 18:57:53.367 BST:*:[local]:**:template1:***:postgres:****: LOG: statement: select GLOBAL autovacuum;
2014-04-18 18:57:53.368 BST:*:[local]:**:template1:***:postgres:****: ERROR: column "global" does not exist at character 9
2014-04-18 18:57:53.368 BST:*:[local]:**:template1:***:postgres:****: STATEMENT: select GLOBAL autovacuum;
2014-04-18 18:58:07.404 BST:*:[local]:**:template1:***:postgres:****: ERROR: syntax error at or near "autovacuum" at character 12
2014-04-18 18:58:07.404 BST:*:[local]:**:template1:***:postgres:****: STATEMENT: SET GLOBAL autovacuum = off
;
2014-04-18 18:58:19.692 BST:*:[local]:**:template1:***:postgres:****: LOG: statement: SELECT pg_catalog.quote_ident(datname) FROM pg_catalog.pg_database WHERE substring(pg_catalog.quote_ident(datname),1,1)='j'
LIMIT 1000
2014-04-18 18:58:21.699 BST:*:[local]:**:template1:***:postgres:****: LOG: statement: SELECT pg_catalog.quote_ident(datname) FROM pg_catalog.pg_database WHERE substring(pg_catalog.quote_ident(datname),1,9)='db_1'
LIMIT 1000
2014-04-18 18:58:23.157 BST:*:[local]:**:template1:***:postgres:****: LOG: statement: DROP DATABASE db_1;

...

Рейтинг:

0 / 0

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

19.04.2014, 04:49:41

#38619359

Alexandr Zlobin

Гость

drop database (около 2 гб ) длится уже более 10 часов

попробовал установить postgres заново с rpm - не помогло.
есть еще какие то идеи? помогите, плиз неделю уже мучаюсь.

...

Рейтинг:

0 / 0

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

19.04.2014, 13:01:13

#38619463

дык думать надо

Гость

drop database (около 2 гб ) длится уже более 10 часов

Alexandr Zlobinпопробовал установить postgres заново с rpm - не помогло.
есть еще какие то идеи? помогите, плиз неделю уже мучаюсь.
вы этта, вы CREATE DATABASE на том же инстансе попробуйте. Посмотрите, как оно на DROP новой отреагирует.

а так как в том анеке:
-- сдохли они, ребе.
-- жаль, а у меня ещё столько идей

вы, надеюсь, SELECT * from pg_locks; тоже смотрели в момент "зависания" ?

и да, погоняйте всё это из консоли --т.е. psql, а не из под непойми каких приблуд. может быть вы какой-то notice/warning пропускаете

...

Рейтинг:

0 / 0

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

19.04.2014, 13:17:56

#38619471

Maxim Boguk

Участник

Откуда: Melbourne, Австралия
Сообщения: 5 148
Рейтинг: 0 / 0

drop database (около 2 гб ) длится уже более 10 часов

Alexandr Zlobinпопробовал установить postgres заново с rpm - не помогло.
есть еще какие то идеи? помогите, плиз неделю уже мучаюсь.

1)поробуйте checkpoint; сделать перед drop database и посмотрите сколько времени он займет и не сработает ли drop database после этого

2)попробуйте сделать пустую базу и drop ее

3)во время drop откройте еще одну консоль к базе и проверьте что нет НИКАКИХ соединений с той базой которую вы пробуете drop

...

Рейтинг:

0 / 0

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

все

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

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

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

start [/forum/topic.php?fid=53&mobile=1&tid=1998720]:	0ms
get settings:	7ms
get forum list:	11ms
check forum access:	3ms
check topic access:	3ms
track hit:	8365ms
get topic data:	6ms
get forum data:	2ms
get page messages:	37ms
get tp. blocked users:	1ms
others:	184ms

total:	8619ms

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