Вставлю свои пять копеек по DG. Можно сказать именно этот продукт окончательно подтолкнул меня на переход к подписке на все продукты (раньше была только Idea с кучей установленных плагинов):
Остались такие вопросы \ пожелания:
Как я понял, что получилось в 2017.1 побороть размытость шрифтов в Database Console в окне просмотра результата запроса под Ubuntu? Все утро пытаюсь и так и сяк и не воспроизводится баг но не получается (и это хорошо!)
Есть какой-нибудь Best Practice по синхронизации проектов DG между различными хостами? Для меня это немного больная тема, так как некоторые базы мне затратно синхронизировать на каждом отдельном хосте.
Больше на интерес пробило меня, в итоге скачал образ и подключился без проблем
Вывод консоли
23:00:56 ~
$ ssh osboxes@localhost -p 4422
The authenticity of host '[localhost]:4422 ([127.0.0.1]:4422)' can't be established.
ECDSA key fingerprint is SHA256:STXIEoIBOaHeTKu5dzBigsfWri6TmRCeAlZ+JeA4GtM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:4422' (ECDSA) to the list of known hosts.
osboxes@localhost's password:
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 4.4.0-31-generic x86_64)
* Documentation: https://help.ubuntu.com/
0 packages can be updated.
0 updates are security updates.
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
osboxes@osboxes:~$ echo $(id -u)
1000
А как же чувство спортивного интереса? Я бы еще предположил, что в вашем образе пользователь по умолчанию — root (с какого-то времени по умолчанию стал запрет на подключения root-ом по паролю), интересен уже вывод :
Но сразу подключиться из-под Visual Studio у меня не удалось, так как система почему то не пускала меня под единственным пользователем. Пришлось создать другого. Это можно сделать в System Settings->User Account.
А у пользователя есть пароль? По умолчанию запрещено подключаться по SSH к пользователю без пароля, можно поменять соответствующую настройку PermitEmptyPasswords
$ sudo -e /etc/ssh/sshd_config
Хотя это действие и не рекомендуется (лучше все же поставить пароль), однако на поиграться можно.
если проблема не в этом, тогда надо смотреть вывод лога после попытки подключения:
Конфигурационные файлы для renew сертификата лежат в директории (актуально для Ubuntu, возможно в других дистрибутивах путь может быть другой) /etc/letsencrypt/renewal в них есть все параметры, которые указываются ключами для certbot ( и которые описаны в man'е)
А не хотите попробовать "засахарить" с помощью COALESCE
SELECT
COALESCE(-gdol.Mass, gdl.Mass, g1.Mass, sc.Mass, CASE WHEN pol.Operation = 0 THEN -gpol.Mass END, 0)
, COALESCE(-gdol.MetallMass, gdl.MetallMass, g1.MetallMass, sc.MetallMass, CASE WHEN pol.Operation = 0 THEN -gpol.MetallMass END, 0)
FROM ...
Поигравшись с настройками:
Load Sources --> None
Auto Sync --> Снял чекбокс (почему сразу я не отключил — непонятно)
Запустил обновляться схему и… опять все повисло на этапе Applying Changes, полез в логи и обратил внимание, что раз в 5 секунд создаются файлы threadDump (пример)
В принципе рабочий workround уже для меня был:
запустить синхронизацию
остановить ее после индексов
Так как данная база — это коробочный продукт (АБС банка), в котором структура не так часто меняется, то меня вполне устроят подсказки по полям таблиц/представлений.
Однако интерес заставил поэкспериментировать, а именно поиграться с JDK. Поменял на версию от Oracle и о чудо — синхронизация завершилась. Решил продолжить:
Снес подключение (для чистоты эксперимента)
Создал новое подключение
Настроил Load Sources / Auto Sync
Добавил две схемы
Нажал синхронизировать и ушел по делам
по возвращении в Event Log нашел следующую запись:
Oracle JDK:
DataGrip 2016.3
Build #DB-163.7744.4, built on November 18, 2016
JRE: 1.8.0_112-b15 amd64
JVM: Java HotSpot(TM) 64-Bit Server VM by Oracle Corporation
Bundled openJDK
DataGrip 2016.3
Build #DB-163.7744.4, built on November 18, 2016
JRE: 1.8.0_112-release-408-b2 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Мне трудно судить по скорости работы, потому как сейчас работаю только с двумя базами, у одной простая структура, там изначально проблем не было, а вторая — эта вот эта:
С ней трудно вести подсчеты по времени, полная синхронизация этой схемы прошла только один раз: на Win 10, 2016.3 (x64), Oracle JDK 8u111.
Вчера ночью запустил на Ubuntu 16.04, 2016.03, утром все еще выполнялся Applying Changes, после завершении работы "интраинспектора" интерфейс DG повис
Нравятся ваши продукты, особенно DG, как всегда есть нюанс — синхронизация огромных схем.
Работаю с базой, в одной схеме которой есть 50к+объектов: 6к таблиц, 12к представлений, 25к пакетов и остального понемножку. Полная синхронизация почти всегда заканчивается с одним результатом — DG зависнет на Applying Changes.
Но это полбеды, если начать синхронизироваться с другой схемой внутри одного подключения (к примеру SYS), то после завершения Intoinspector примется за полную синхронизацию той огромной
Используют, очень редко, но используют. Минусы upstart в RHEL, что версия уж очень древняя, некоторые вещи сделать нетривиально и легче делать через SysV чем городить костыли, ну и в конечном итоге на смену в семерке ему пришел systemd
Однако основной мой посыл был в том, что поведение service более предсказуемое в RHEL, чем в Ubuntu
Это недокументированная возможность, хотя в коде это есть
Выдержка из /usr/sbin/service
is_systemd=
if [ -d /run/systemd/system ]; then
is_systemd=1
fi
# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]
then
UNIT="${SERVICE%.sh}.service"
# avoid deadlocks during bootup and shutdown from units/hooks
# which call "invoke-rc.d service reload" and similar, since
# the synchronous wait plus systemd's normal behaviour of
# transactionally processing all dependencies first easily
# causes dependency loops
if ! systemctl --quiet is-active multi-user.target; then
sctl_args="--job-mode=ignore-dependencies"
fi
case "${ACTION}" in
restart|status)
exec systemctl $sctl_args ${ACTION} ${UNIT}
;;
start|stop)
# Follow the principle of least surprise for SysV people:
# When running "service foo stop" and foo happens to be a service that
# has one or more .socket files, we also stop the .socket units.
# Users who need more control will use systemctl directly.
for unit in $(systemctl list-unit-files --full --type=socket 2>/dev/null | sed -ne 's/\.socket\s*[a-z]*\s*$/.socket/p'); do
if [ "$(systemctl -p Triggers show $unit)" = "Triggers=${UNIT}" ]; then
systemctl $sctl_args ${ACTION} $unit
fi
done
exec systemctl $sctl_args ${ACTION} ${UNIT}
;;
reload)
_canreload="$(systemctl -p CanReload show ${UNIT} 2>/dev/null)"
if [ "$_canreload" = "CanReload=no" ]; then
# The reload action falls back to the sysv init script just in case
# the systemd service file does not (yet) support reload for a
# specific service.
run_via_sysvinit
else
exec systemctl $sctl_args reload "${UNIT}"
fi
;;
force-stop)
exec systemctl --signal=KILL kill "${UNIT}"
;;
force-reload)
_canreload="$(systemctl -p CanReload show ${UNIT} 2>/dev/null)"
if [ "$_canreload" = "CanReload=no" ]; then
exec systemctl $sctl_args restart "${UNIT}"
else
exec systemctl $sctl_args reload "${UNIT}"
fi
;;
*)
# We try to run non-standard actions by running
# the init script directly.
run_via_sysvinit
;;
esac
fi
По сути, если есть папка /run/systemd/system то дальнейшая работа передается systemd
В любом случае в системе с systemd взаимодействовать со скриптами инициализации стоит все же через systemctl.
В CentOS — ванильная версия service от Red Hat которая используется только для запуска SysV скриптов, однако в Ubuntu используется модифицировання версия от Canonical которая запускает SysV и\или Upstart
$ sudo initctl restart tomcat8
sudo: initctl: command not found
$ sudo restart tomcat8
sudo: restart: command not found
Во-первых судя по тому, что command not found у Вас не установлен upstart: apt list --installed upstart
Во-вторых непонятно что вы хотите получить, запуская initctl или restart — эти комманды запустят только upstart job-ы которые расположены в /etc/init/
$ lsb_release -i -r
Distributor ID: CentOS
Release: 6.8
$ service --version
service ver. 0.91
$ init --version
init (upstart 0.6.5)
Copyright (C) 2010 Canonical Ltd.
This is free software; see the source for copying conditions. There is NO warranty; not even
for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ls -l /etc/init/tomcat6.conf
-rw-r--r--. 1 root root 493 Sep 13 00:07 /etc/init/tomcat6.conf
$ sudo service tomcat6 restart
tomcat6: unrecognized service
$ sudo initctl restart tomcat6
tomcat6 start/running, process 9679
$ sudo restart tomcat6
tomcat6 start/running, process 9729
service в Ubuntu — угадай что надо запустить SysV или upstart, а может и не угадать и тогда нас ждет веселье. И такой он был сделан на "переходный период" в Ubuntu. В RHEL\Centos 6 пошли другим путем и service используется только для запуска SysV, для upstart используется initctl.
В итоге в Ubuntu мы имеем: /etc/init.d/ — SysV initctl — upstart service — "общая команда" для SysV и upstart systemctl — systemd
Случайно это не является ли универсальным способом, не зависимым от системы инициализации?
Короткий ответ нет. Более длинный кроется в man service
man service
service(8) System Managers Manual service(8)
NAME
service - run a System V init script
DESCRIPTION
service runs a System V init script or upstart job in as predictable an
environment as possible, removing most environment variables and with
the current working directory set to /.
Правильно будет использовать ту систему инициализации, которая является основной в Вашей системе. Если говорим про Ubuntu, то для 15.04+ то это systemd, если ранние версии то upstart. Конечно отдельное спасибо надо сказать мейнтейнерам Debian, которые так и не осилили переписать скрипты на соответствующие системы инициализации.
Еще надо не забывать, что функции
GREATESTиLEAST, в отличии от реализации в Oracle и DB2 LUW, игнорируют NULL.или через format:
Вставлю свои пять копеек по DG. Можно сказать именно этот продукт окончательно подтолкнул меня на переход к подписке на все продукты (раньше была только Idea с кучей установленных плагинов):
Остались такие вопросы \ пожелания:
Больше на интерес пробило меня, в итоге скачал образ и подключился без проблем
А как же чувство спортивного интереса? Я бы еще предположил, что в вашем образе пользователь по умолчанию —
root(с какого-то времени по умолчанию стал запрет на подключения root-ом по паролю), интересен уже вывод :А у пользователя есть пароль? По умолчанию запрещено подключаться по SSH к пользователю без пароля, можно поменять соответствующую настройку
PermitEmptyPasswordsХотя это действие и не рекомендуется (лучше все же поставить пароль), однако на поиграться можно.
если проблема не в этом, тогда надо смотреть вывод лога после попытки подключения:
С двухсторонней лентой попробуйте 3M 4905 или 4910
Для Java софта лечится (проверено на Idea, DG, PyCharm, Pentaho DI) с помощью следующего workround
Конфигурационные файлы для
renewсертификата лежат в директории (актуально для Ubuntu, возможно в других дистрибутивах путь может быть другой)/etc/letsencrypt/renewalв них есть все параметры, которые указываются ключами дляcertbot( и которые описаны в man'е)По сути у Dell не глобальная гарантия, а есть возможность сделать Warranty and Ownership Transfer на отдельные виды продукции.
Странно, что его физически нет, однако его всегда можно посмотреть:
wmic bios get serialnumberdmidecode -s system-serial-numberА не хотите попробовать "засахарить" с помощью COALESCE
Поигравшись с настройками:
Load Sources --> None
Auto Sync --> Снял чекбокс (почему сразу я не отключил — непонятно)
Запустил обновляться схему и… опять все повисло на этапе Applying Changes, полез в логи и обратил внимание, что раз в 5 секунд создаются файлы threadDump (пример)
В принципе рабочий workround уже для меня был:
Так как данная база — это коробочный продукт (АБС банка), в котором структура не так часто меняется, то меня вполне устроят подсказки по полям таблиц/представлений.
Однако интерес заставил поэкспериментировать, а именно поиграться с JDK. Поменял на версию от Oracle и о чудо — синхронизация завершилась. Решил продолжить:
по возвращении в Event Log нашел следующую запись:
Oracle JDK:
DataGrip 2016.3
Build #DB-163.7744.4, built on November 18, 2016
JRE: 1.8.0_112-b15 amd64
JVM: Java HotSpot(TM) 64-Bit Server VM by Oracle Corporation
Bundled openJDK
DataGrip 2016.3
Build #DB-163.7744.4, built on November 18, 2016
JRE: 1.8.0_112-release-408-b2 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Мне трудно судить по скорости работы, потому как сейчас работаю только с двумя базами, у одной простая структура, там изначально проблем не было, а вторая — эта вот эта:
С ней трудно вести подсчеты по времени, полная синхронизация этой схемы прошла только один раз: на Win 10, 2016.3 (x64), Oracle JDK 8u111.
Вчера ночью запустил на Ubuntu 16.04, 2016.03, утром все еще выполнялся Applying Changes, после завершении работы "интраинспектора" интерфейс DG повис
Нравятся ваши продукты, особенно DG, как всегда есть нюанс — синхронизация огромных схем.
Работаю с базой, в одной схеме которой есть 50к+объектов: 6к таблиц, 12к представлений, 25к пакетов и остального понемножку. Полная синхронизация почти всегда заканчивается с одним результатом — DG зависнет на Applying Changes.
Но это полбеды, если начать синхронизироваться с другой схемой внутри одного подключения (к примеру SYS), то после завершения Intoinspector примется за полную синхронизацию той огромной
Используют, очень редко, но используют. Минусы
upstartв RHEL, что версия уж очень древняя, некоторые вещи сделать нетривиально и легче делать через SysV чем городить костыли, ну и в конечном итоге на смену в семерке ему пришелsystemdОднако основной мой посыл был в том, что поведение
serviceболее предсказуемое в RHEL, чем в UbuntuЭто недокументированная возможность, хотя в коде это есть
По сути, если есть папка /run/systemd/system то дальнейшая работа передается systemd
В любом случае в системе с systemd взаимодействовать со скриптами инициализации стоит все же через systemctl.
P.S.: Еще есть возможность запуска OpenRC.
В CentOS — ванильная версия
serviceот Red Hat которая используется только для запуска SysV скриптов, однако в Ubuntu используется модифицировання версия от Canonical которая запускает SysV и\или UpstartВо-первых судя по тому, что command not found у Вас не установлен upstart:
apt list --installed upstartВо-вторых непонятно что вы хотите получить, запуская initctl или restart — эти комманды запустят только upstart job-ы которые расположены в /etc/init/
serviceв Ubuntu — угадай что надо запустить SysV или upstart, а может и не угадать и тогда нас ждет веселье. И такой он был сделан на "переходный период" в Ubuntu. В RHEL\Centos 6 пошли другим путем иserviceиспользуется только для запуска SysV, для upstart используетсяinitctl.В итоге в Ubuntu мы имеем:
/etc/init.d/— SysVinitctl— upstartservice— "общая команда" для SysV и upstartsystemctl— systemdКороткий ответ нет. Более длинный кроется в
man serviceПравильно будет использовать ту систему инициализации, которая является основной в Вашей системе. Если говорим про Ubuntu, то для 15.04+ то это
systemd, если ранние версии тоupstart. Конечно отдельное спасибо надо сказать мейнтейнерам Debian, которые так и не осилили переписать скрипты на соответствующие системы инициализации.