Нет, не верно, 127.0.0.1, он же lo или localhost - это интерфейс-заглушка. В вашем случае должен быть какой-то eth0, ens192 ну или какой-то другой сетевой интерфейс, отличный от lo.
Тогда непонятно, почему вы обращаетесь к 172.17.0.1 - ведь это адрес из подсети докер по умолчанию. Если вы хотите обратиться к локальному постгресу, поднятому у вас на сервере, то указывайте адрес сервера - посмотреть его можно командой ip a или ipconfig, если винда. Заодно проверьте, на каком сетевом интерфейсе он слушает подключение клиентов, потому что по дефолту он слушает только 127.0.0.1
Локальный постгрес - он тоже поднят в докере? или поднят на хосте? у меня ощущение, что вы из своего докера с приложением пытаетесь обратиться к адресу в подсети докера, который либо не существует, либо он не является контейнером с постгресом
А то, что они все в одной подсети - это нормально? просто не сталкивался с такой конфигурацией, обычно подсети у локальной сети и моста разные. Еще что интересно - а с циски виден интерфейс 172.16.3.100? Если да, то почему не его указать в качестве next-hop? tcpdump -i eth1 видит пакеты для 101-го адреса?
Возможно, поскольку я дело с Hyper-V не имел, виртуализировал на KVM и VMware - там таких проблем с производительностью не было. Причем именно в этой связке - Oracle 12c/Linux, правда вместо Oracle Linux 7 был CentOS 7.
На мой взгляд да, проблема между гипервизором и гостевой системой - насколько я знаю, не все дистрибутивы работают нормально на Hyper-V.
Объемы не большие, чтобы так зависать, я все же склоняюсь к мысли, что проблема не в Оракле.
Вот что нашел в гугле - это не ваш случай? Там правда говорится про 2008R2, но мало ли, может проблема и в 2012 такая же.
By default, Windows Server 2008 R2 installs with the Windows Remote Management (WinRM) limited to 15 concurrent operations per user. To check the number of concurrent operations per user, run the following command on Windows host:
> winrm get winrm/config
...
Service
MaxConcurrentOperationsPerUser = 15
...
For some Oracle VDI deployments, this limit is too low and can cause communication problems between Oracle VDI and Hyper-V. When there are communication problems, the cacao logs typically contain the following error message:
SOAP Fault: The WS-Management service cannot process the request. The maximum
number of concurrent operations for this user has been exceeded. Close existing
operations for this user, or raise the quota for this user.
Actor:
Code: s:Receiver
Subcodes: w:InternalError
Detail: The WS-Management service cannot process the request. This user is
allowed a maximum number of 15 concurrent operations, which has been exceeded.
Close existing operations for this user, or raise the quota for this user.
If you see this error message, the solution is to increase the MaxConcurrentOperationsPerUser property to a value that is appropriate for your Oracle VDI deployment. To change the property, run the following command on the Hyper-V host:
> winrm set winrm/config/service @{MaxConcurrentOperationsPerUser="num"}
For example:
> winrm set winrm/config/service @{MaxConcurrentOperationsPerUser="200"}
Только не забудьте прописать похожее правило и на роутере 2 для 1-й подсети, иначе клиенты 2-го роутера не будут знать о существовании клиентов на роутере 1
Ммм.. Входящие же не тарифицируются? А вообще, если судить по этой ссылке - www.multifon.ru/tarifs - то бесплатно можно общаться, если у вас с обоих сторон будет мультифон
Может стоит более развернуто описать, что вам необходимо сделать? Ведь правильно заданный вопрос содержит в себе 70% ответа :)
Из того описания вопроса, что есть сейчас, я вижу только один ответ - знать все адреса клиентов и в цикле отправить им всем сообщение, без всяческих броадкастов. Ну либо знать все сети и отправлять всем адресам в этих сетях в таком же цикле
Это не тот кластер, который отвечает за отказоустойчивость, это такой тип, который объединяет несколько таблиц, у которых есть общий столбец. Согласно описанию, этот объект обновляется SMON каждые 5 минут и хранит timestamp и текущий SCN, нужен для связки времени и SCN. А падает это из-за запуска какого-то job-а раз в час.
Вообще-то с такими ошибками надо обращаться на техсаппорт Oracle, могу посоветовать, но это на ваш страх и риск, как говорится.
В вашем случае можно попробовать следующее
1. Сделать бекап.
2. Пересоздать требуемый кластер и зависимые от него таблицы и индексы. У меня сейчас под рукой нет Express, но в 11.2 SE это находится в скрипте $ORACLE_HOME/rdmb/admin/dtxnspc.bsq в конце скрипта. Можете посмотреть в $ORACLE_HOME/rdmb/admin/sql.bsq.
Согласен — учитывая небольшой объем базы и то что простой некритичен — можно сделать миграцию через экспорт/импорт. Другие решения требуют более глубоких знаний Оракла
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
ss -telnep | grep 5432