Здравствуйте, AlexGin, Вы писали:
S>>Не знаю, может скорость AG>Скорость — в смысле за счёт ухода от промежуточного слоя ODBC подсистемы?
Ну это чисто предположение, если все уже работает и все устраивает, то менять вряд ли что-то стоит.
Здравствуйте, уважаемый m2l, Вы писали:
m2l>Я думаю тебе проше будет сделать так:
Проделывал это раз 100 за сегодня — и на работе и на моём ноуте! Ситуация повторяется!
m2l>1. Штатно устанавливаешь PostgreSQL её инсталятором. m2l>2. Выполняешь первый запуск. m2l>3. Останавливаешь сервер СУБД. m2l>4. В директории куда установил СУБД папку data меняешь на свою директорию (старую Data переименовываешь, новую копируешь на её место). m2l>5. Сравниваешь права ntfs старой и новой data — и делаешь у новой такие же, как у сделанной инсталятором. m2l>6. Штатно запускаешь СУБД — СЕРВЕР НЕ ЗАПУСКАЕТСЯ!!!
Вот такая картинка:
P.S. Возвращение к исходной папке данных (переименованием папок) — позволяет запустить сервер БД.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, уважаемый m2l, Вы писали:
m2l>>Я думаю тебе проше будет сделать так: AG>Проделывал это раз 100 за сегодня — и на работе и на моём ноуте! Ситуация повторяется!
1. Ты точно уверен, что версия PostgreSQL совпадает с исходной? Это не Оракл, тут версии при переносе каталога data должны быть один в один.
2. Ты точно воссоздал права всё права на NTFS или рекуррентно заменил существующие на полный доступ для всех?
3. Смотри, возможно таланты, что дали тебе такой бэкап ещё что-то намудрили. Замени оригинальный data своим, а потом из оригинального (копия того, что сделал инсталятор) возьми файлы postgresql.conf, pg_ident.conf, pg_hba.conf — и ими подмени файлы из бэкапа в data. Это глобальные настройки СУБД, они непосредственно к базе данных не привязаны. Поэтому ты возьмешь их рабочие экземпляру из копии инсталятора и заменишь экземпляры в неизместном состоянии от своего бэкапа.
4. Надо читать лог и смотреть, на что ругается. У тебя есть файлы в "C:\Program Files\PostgreSQL\9.4\data\pg_log"?
AG>Вот такая картинка: Смотри, такая картинка происходит
Попробуй проверить права, заместить *.conf файлы внутри data, а потом посмотреть, что за ошибки пишутся в лог.
AG>P.S. Возвращение к исходной папке данных (переименованием папок) — позволяет запустить сервер БД.
Ну так для этого мы её и переименовали, а не удалили
Здравствуйте, AlexGin, Вы писали:
m2l>>Я думаю тебе проше будет сделать так: AG>Проделывал это раз 100 за сегодня — и на работе и на моём ноуте! Ситуация повторяется! AG>Вот такая картинка: AG>P.S. Возвращение к исходной папке данных (переименованием папок) — позволяет запустить сервер БД.
Попробуй выполнить что я написал выше, но ещё подумай о варианте взять нормальную копию базы данных.
Перенос холодного бэкапа — это один из нескольких штатных способов для Oracle. Это штатной, но не очень рекомендуемый способ для SQL Server. Но даже в них эта операция требует чуть больших знаний и опыта, чем простые impdp/expdp или backup database/restore. А для PostgreSQL переноса каталога data для копирования БД вообще-то не предполагается в принципе. Этот способ обычно используют когда исходный сервер СУБД вышел из строя, бэкапов нет, а данные спасти надо. И потенциально можно поиметь очень много граблей в этом деле. Поэтому оцени — возможно потребовать выгрузку исходной базы данных через pg_dump будет проще? Так сказать действовать административными, а не техническими методами.
В общем, посвятив день борьбе с проблемой установки этого "чуда" на Windows, могу с уверенностью предположить — что эта СУБД неудачная
По крайней мере — для Windows систем.
Ситуация повторялась с точностью один в одни как на стационарном компе, так и на ноуте (Windows 10 x64 Pro — в обоих местах).
1) Остановив службу и заменив директорий "data" на мой (переименовав старый), — получаем НЕзапускаемый сервер с невразумительной ошибкой: http://rsdn.org/forum/db/7439201.1
2) На единственном месте, где (чудом) удалось пару недель назад эту БД запустить, выполнение бекапа командой:
pg_dump -U postgres -d AICM -f d:/TEMP/aicm.sql
всё-таки создаёт файл aicm.sql (в папке d:/TEMP). Это — единственный положительный момент
Вот только восстановить данную базу — к сожалению, нигде НЕ возможно
a) Выполнение команды:
psql -U postgres -f d:/TEMP/aicm.sql
(при работающей службе postgresql-9.4) — проводит некоторую работу, которая так и НЕ создаёт никакой новой базы.
b) Выполнение команды:
pg_restore -U postgres -f d:/TEMP/aicm.sql
хоть при работающей службе, хоть при остановленной — вызывает "зависание" данной команды.
Только "Ctrl + C" с клавиатуры — вызывает выход из этой команды.
3) Выполнение команды:
pg_ctl -D "D:\PSG_SQL\data" restart
с целью переноса рабочей папки
при работающей службе postgresql-9.4 — вызывает такое вот сообщение и зависание:
Опять "Ctrl + C" с клавиатуры
Кто может — укажите, пожалуйста, где кривость моих рук и есть ли здесь она?
Здравствуйте, m2l, Вы писали:
m2l>1. Ты точно уверен, что версия PostgreSQL совпадает с исходной? Это не Оракл, тут версии при переносе каталога data должны быть один в один.
Да, так как в одном месте — чудо случилось (пару недель назад) и у меня как-то
получилось запустить на pg sql 9.4.
Ну и наши бойцы (которые дали мне БД) говорили и писали про версию 9.4 (x86).
m2l>2. Ты точно воссоздал права всё права на NTFS или рекуррентно заменил существующие на полный доступ для всех?
Копировал в Total-Comander — с установкой соответствующего check-box-а.
m2l>3. Смотри, возможно таланты, что дали тебе такой бэкап ещё что-то намудрили. Замени оригинальный data своим, а потом из оригинального (копия того, что сделал инсталятор) возьми файлы postgresql.conf, pg_ident.conf, pg_hba.conf — и ими подмени файлы из бэкапа в data. Это глобальные настройки СУБД, они непосредственно к базе данных не привязаны. Поэтому ты возьмешь их рабочие экземпляру из копии инсталятора и заменишь экземпляры в неизместном состоянии от своего бэкапа.
Заменил файлы postgresql.conf, pg_ident.conf, pg_hba.conf — теми, что в запускаемой (рабочей) конфигурации, вернулся к моей конфигурации — ситуация та же, что описывал ранее
m2l>4. Надо читать лог и смотреть, на что ругается. У тебя есть файлы в "C:\Program Files\PostgreSQL\9.4\data\pg_log"?
нашел этот лог — просматриваю...
Если служба НЕ стартовала, лог пустой — что в общем и следует ожидать.
Здравствуйте, AlexGin, Вы писали:
AG>В общем, посвятив день борьбе с проблемой установки этого "чуда" на Windows, могу с уверенностью предположить — что эта СУБД неудачная AG>По крайней мере — для Windows систем.
Скорей просто несколько не user friendly))
AG>1) Остановив службу и заменив директорий "data" на мой (переименовав старый), — получаем НЕзапускаемый сервер с невразумительной ошибкой:
PostgreSql не рассчитан на перенос данных простым копированием data. Без проблем это возможно только для идентичных программных окружений. В некоторых случаях вообще невозможно.
И невразумительное ошибку даёт менеджер служб. Постгрес свои ошибки, в зависимости от настроек postgresql.conf пишет в файл/консоль/event log. И соответственно их надо там читать.
AG>2) На единственном месте, где (чудом) удалось пару недель назад эту БД запустить, выполнение бекапа командой: AG>
AG>всё-таки создаёт файл aicm.sql (в папке d:/TEMP). Это — единственный положительный момент AG>Вот только восстановить данную базу — к сожалению, нигде НЕ возможно AG>a) Выполнение команды: AG>
AG> psql -U postgres -f d:/TEMP/aicm.sql
AG>
AG>(при работающей службе postgresql-9.4) — проводит некоторую работу, которая так и НЕ создаёт никакой новой базы.
Во первых есть параметр --verbose , с которым скорей всего будет видно место ошибки.
Во вторых aicm.sql это действительно просто последовательность sql запросов — ты можешь выполнить их и без pg_restore. Отдавать места ошибок и подкорректировать руками.
AG>хоть при работающей службе, хоть при остановленной — вызывает "зависание" данной команды.
Если честно, возможно это одно из мест, где проявляются косяки порта postgresql под windows — не очень он любит штатную консоль. Как раз, такие моменты я имел ввиду, когда писал, что под win, желательно другие СУБД использовать. Как обходной путь попробуй pgAdmin для восстановления из бэкапа.
AG>Только "Ctrl + C" с клавиатуры — вызывает выход из этой команды.
AG>3) Выполнение команды: AG>
AG> pg_ctl -D "D:\PSG_SQL\data" restart
AG>
AG>с целью переноса рабочей папки AG>при работающей службе postgresql-9.4 — вызывает такое вот сообщение и зависание: AG>Image: pg_sql_problem2.jp AG>Опять "Ctrl + C" с клавиатуры
Каталог data категорически нельзя трогать при работающем экземпляре СУБД.
AG>Кто может — укажите, пожалуйста, где кривость моих рук и есть ли здесь она?
Ну, тут скорей складываются отсутствие у тебя опыта, общая неинтуитивность постгреса/СУБД и косяки его порта под Винду.
Имхо задача принципиально решаемая. Просто надо включать расширенное логирование, вытягивать коды/тексты ошибок того что происходит и корректировать свои действия под них. И да, эти тексты ошибок там действительно есть)) Ну кроме твоего варианта pg_ctl полагаю.
Здравствуйте, AlexGin, Вы писали:
AG>Да, так как в одном месте — чудо случилось (пару недель назад) и у меня как-то AG>получилось запустить на pg sql 9.4. AG>Ну и наши бойцы (которые дали мне БД) говорили и писали про версию 9.4 (x86).
Ок.
m2l>>2. Ты точно воссоздал права всё права на NTFS или рекуррентно заменил существующие на полный доступ для всех? AG>Копировал в Total-Comander — с установкой соответствующего check-box-а.
Я не уверен, что в процессе не закралась маленькая неточность) Давай, для data добавим Acl для пользователя everyone/все, с правами полный доступ и и поставим галочку заменить права дочерних объектов.
AG>Заменил файлы postgresql.conf, pg_ident.conf, pg_hba.conf — теми, что в запускаемой (рабочей) конфигурации, вернулся к моей конфигурации — ситуация та же, что описывал ранее
Ок, тогда логи.
m2l>>4. Надо читать лог и смотреть, на что ругается. У тебя есть файлы в "C:\Program Files\PostgreSQL\9.4\data\pg_log"? AG>нашел этот лог — просматриваю...
Куда, с какой детализацией и пишется ли вообще зависит от настроек в postgresql.conf из data. Возможно их надо подправить. AG>Если служба НЕ стартовала, лог пустой — что в общем и следует ожидать.
Вот тут ты не прав. Последовательность иная — диспетчер служб стартует процесс, он загружает настройки postgresql.conf и начинает писать логи, пытается подхватить саму базу, фейлится, пишет об этом и почему в лог, завершает работу не возвращая диспетчеру код успешного запуска. Диспетчер говорит тебе, что не смог запустить службу.
Т.е. при правильной настройке лога и правах на запись в него, там будут ошибки из-за которых служба не стартовала.
Здравствуйте, m2l, Вы писали:
m2l>Имхо задача принципиально решаемая. Просто надо включать расширенное логирование, вытягивать коды/тексты ошибок того что происходит и корректировать свои действия под них. И да, эти тексты ошибок там действительно есть)) Ну кроме твоего варианта pg_ctl полагаю.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, m2l, Вы писали:
m2l>>Имхо задача принципиально решаемая. Просто надо включать расширенное логирование, вытягивать коды/тексты ошибок того что происходит и корректировать свои действия под них. И да, эти тексты ошибок там действительно есть)) Ну кроме твоего варианта pg_ctl полагаю.
AG>pg_ctl — вот описан: AG>https://stackoverflow.com/questions/36629963/how-to-start-postgresql-on-windows
AG>Кстати, именно им (и ещё какой-то матерью) мне удалось пару недель назад как-то установить это "чудо" на одном из компов
Здравствуйте, AlexGin, Вы писали:
m2l>>Имхо задача принципиально решаемая. Просто надо включать расширенное логирование, вытягивать коды/тексты ошибок того что происходит и корректировать свои действия под них. И да, эти тексты ошибок там действительно есть)) Ну кроме твоего варианта pg_ctl полагаю.
AG>pg_ctl — вот описан: AG>https://stackoverflow.com/questions/36629963/how-to-start-postgresql-on-windows
Обрати внимание на параметр -l/--log он влёт решает твою проблему с кодировками. Еще при установке можно было указать английскую локаль (или подправить её в postgresql.conf) и сообщения будут на латинице — проблема кодировки исчезнет. Ещё можно выполнить chcp 1251 перед выполнением команды. Удостоверься, что консоль запущена с правами администратора. По самой команде, лучше делать restart fast.
AG>Кстати, именно им (и ещё какой-то матерью) мне удалось пару недель назад как-то установить это "чудо" на одном из компов
pg_ctl по сути просто обертка над https://postgrespro.ru/docs/postgresql/9.4/app-postgres (и ещё initdb).
Но я призываю тебя, все-же получить логи в файлах/eventlog/настроенной консоли. Ну ведь реально, постгресс не уникален в своих бедах с кодировкой в виндовом терминале, совсем чуть-чуть и у тебя список ошибок на которые он жалуется. Эти ошибки вставляешь в stackoverflow, советы перепроверять по postgrespro.ru/docs и выполняешь. Это действительно просто.
Доброе время суток, уважаемые коллеги!
Наконец-то удвлось запустить PostgreSQL 9.4.22 на Win-10 Pro
Опишу подробно все мои действия:
0) Удалил всё то, что ставил вчера днем и вечером;
1) На сайте PostgreSQL — имеется архив БИНАРНИКОВ: https://www.enterprisedb.com/download-postgresql-binaries
я решил не ставить через *.msi файл, не брать инсталлятор сервера (один большой *.exe), а просто скачать бинарник: postgresql-9.4.22-1-windows-binaries.zip;
2) Сделал папку: C:\PSG_SQL — в которую и распаковал все содержимое вышеуказанного архива.
Эту папку — расшарил на режим "everyone: read/write";
3) В эту же папку поместил мою "многострадальную" папку "data"
эту папку — также расшарил на режим "everyone: read/write";
4) В папке "data" в файле pg_hba.conf — установлена опция "trust":
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
эта опция установлена в двух строках;
5) В переменных окружения — (user variables) я добавил новую переменную: PGDATA = C:\PSG_SQL\data
после этого добавления — перезагрузился (чтобы оно вступило в силу);
6) Запустив консоль cmd.exe с правами Администратора, и перейдя в директорий C:\PSG_SQL\bin выполнил:
pg_ctl start
выдав немного аброкадабры и латиницы, приложение осталось работать (вроде без ошибок);
7) Установил приложение pgAdmin III v 1.22.2 (файлом pgadmin3.msi) и подключился к серверу,
там увидел все требуемые мне таблицы;
8) Установил драйвер ODBC (файлом psqlodbc_x86.msi), создал ODBC — DSN для 32-х разрядного режима,
убедившись, что cjnnect к серверу БД работает;
9) Запустив мой проект из Visual Studio — убедился что требуемый результат получен
P.S. Моя служба postgresql-9.4 теперь НЕ видна в общем окне списка служб Windows, но тем не менее — она работает!
В окошке pgAdmin-a (в SQL Editor) ввожу:
SHOW data_directory;
Получаю верный путь: C:/PSG_SQL/data
здесь разделители — в стиле Linux
Здравствуйте, AlexGin, Вы писали:
AG>...имеется архив БИНАРНИКОВ: AG>https://www.enterprisedb.com/download-postgresql-binaries AG>я решил не ставить через *.msi файл, не брать инсталлятор сервера (один большой *.exe), а просто скачать бинарник: AG>postgresql-9.4.22-1-windows-binaries.zip;
Может это не совсем правильно, так как при установке из файла *.msi и "натравливании" инсталлятора на мою "многострадальную" папку "data" C:\PSG_SQL\data
для версии 9.4.22-1 было сообщение, о несовместимости данных.
В то же время, для версии 9.4.21-1 — всё проходит отлично!
Возможно, корректнее было бы устанавливать архив: postgresql-9.4.21-1-windows-binaries.zip;
