Akina

1. На проблемном сервере:
   
   • Создать папки баз.
     
   • Запустить сервер в режиме восстановления (InnoDB Recovery Modes).
     
   • Дропнуть базы.
     
   
   
2. Если не удаётся запуститься даже в режиме восстановления:
   
   • Восстановить БД из бэкапа на другом инстансе сервера
     
   • Скопировать каталоги баз на проблемный сервер
     
   • См. п. 1.
     
   
   

n_flag может быть 0..5
num_status 0..20
...
запись, где n_flag=0 и num_status>=10.

Указанным условиям при равномерном распределении значений соответствует ~9% записей, т.е. 18 млн. Причём отбор по n_flag более селективен.
Чисто теоретически оптимальным без использования фич Постгресса будет индекс (n_flag, update_date, num_status).

DEMO fiddle. Правда, 200 млн. записей я генерить как-то не решился... но для 1 млн. записей запрос показывает 40-50 мс - по-моему, вменяемо.

PS. Индекс называется на "комплексный", а композитный. Кроме того, этот индекс - покрывающий, т.е. для обработки запроса серверу не требуется обращаться к таблице.

Начните с формализации данных. Хотя бы введите единообразие наименований (наименование должно выбираться из списка, а не вводиться в свободной форме, либо должна заполняться форма со всеми возможными наименованиями) и формата представления данных. Это задача 1.
Задача 2 - решить, в каком виде будет заполняться ежедневная форма. Веб-форма тут в общем вполне подойдёт. На гугле свет клином не сошёлся - есть те же яндекс-документы, например...
Задача 3 - передача готовой формы. Тут я бы рекомендовал выгрузку в локальный CSV и отправку по электронной почте. Это контролируемый и протоколируемый канал, бесполезно говорить, что письмо было отправлено вовремя, если его нет в отправленных или если дата отправки - безнадёжно просроченная.
Задача 4 - загрузка полученных данных в единое хранилище. Тут уже можно думать о приличной СУБД. Ну а её штатных клиентских средств для загрузки - за глаза.
Задача 5 - аналитика. Имея данные в БД, получать аналитику в любых формах и разрезах - не проблема.
Ну и задача 6 - формирование красивых выходных документов с результатами анализа. Тоже не сказать что проблема.

Можно ли написать такой же запрос, если поле raw не jsonb, а text?

Ну офигеть проблема - заменить tp."raw"->>'errorCode' на tp."raw"::JSONB->>'errorCode'

Кстати, это применимо к полю обоих типов. Просто для JSON - избыточно.

Трассировка - это ICMP. Обработка ICMP, или во всяком случае обработка ping и отправка pong - это задача с низшим приоритетом для любого узла за редчайшим исключением. Потому даже 100% потерь ни о чём не говорят. TCP или UDP пинг был бы более информативен, но с ними есть определённые сложности - при отсутствии специального ПО на целевом узле результаты будут весьма приблизительными.

Потери на промежуточных узлах тоже ни о чём не говорят. Во-первых, маршрутизаторам и без ответов на твои пинги есть чем заняться, во-вторых, тебе с промежуточными узлами общаться не требуется. ДО целевого узла добирается всё? и даже ответы - тоже возвращаются все? ну и славненько. Вот время прохождения пакета - это значимое число. Да и то, с учётом низкого приоритета, прохождение TCP пакета может быть намного быстрее.

Диапазон от 194.58.80.0/24 до 194.58.95.0/24 - лучше. Он извне (на внешнем интерфейсе) накрывается одним маршрутом.

194.58.80.0 .. 194.58.95.0 = 194.58.80.0/20
194.58.72.0 .. 194.58.87.0 = 194.58.72.0/21 + 194.58.80.0/21

Впрочем, лучше - провайдеру. Потребителю - глубоко пофиг.

PS. Конечно, пофиг вообще всем. Но это единственная разница, которую мне удалось отыскать.

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

Однако, судя описанию, обе сетевые карты настроены на автоматическое получение адреса. И соответствующие DHCP-серверы не рвутся правильно анонсировать маршруты, а просто анонсируют шлюз по умолчанию.

Соответственно для нормальной работы нужно (при условии, что обе карты адресуются по DHCP):

1. Настроить метрики интерфейсов, поставить интерфейсу в корпоративной сети более высокую метрику (бОльшее значение метрики соответствует более низкому приоритету интерфейса, и соответственно его маршрутов).

2. Выяснить адреса узлов в корп. сети, к которым тебе нужен доступ. Если доступ осуществляется по IP - то всё просто, адреса уже есть. Если же по именам, то следует отключить второй интерфейс, а потом получить соответствия имён адресам (да хоть тупым пингом) и внести эти соответствия в файл HOSTS. Ну и молиться, что эти нужные адреса - не динамические. Получив адреса (а ещё лучше - узнав у админа их подсети), прописать статические маршруты в эти подсети либо к этим адресам через анонсируемый в корпоративной сети шлюз. После чего - на карте в корп. сеть установить статические адреса DNS-серверов, и удалить из списка все серверы.

3. По-хорошему - написать скрипт, который при старте системы выключает интерфейс в корп. сеть, а затем его снова включает. Эта операция (совместно с установкой метрик) гарантирует, что будет использоваться маршрут по умолчанию именно на интернетовском интерфейсе.

Впрочем, это всё будет работать только в случае, если в корп. сети не производятся какие-то перестройки (изменения адресации). Если что-то изменится, скорее всего придётся корректировать и свои локальные настройки.

В результате надо получить таблицу, в которой будут только IPv4 адреса

Не вижу проблемы. Импорт не использует inet6_aton. Соответственно после импорта можно просто удалить записи с IPv6-адресами. А затем ещё и изменить тип поля на VARBINARY(4).

SELECT {выходные поля запроса}
FROM ( SELECT 3 AS rownumber, {выходные поля запроса}
       FROM {остальное тело запроса} )
     UNION ALL
     ( SELECT 1, {надписи шапки}
       FROM DUAL )
     UNION ALL
     ( SELECT 2, {кастомные названия}
       FROM DUAL )
) AS total
ORDER BY rownumber, {остальные поля сортировки};

• 0. Всегда (на все три вопроса). 800 устройств в одном домене коллизий, это [censored] и полный ступор.
  
• 1. Да. Но нет. Все в одной подсети - бред и никакого смысла.
  
• 2. Немаршрутизируемые в Интернет адреса (bogon networks). Я бы делал подсети в 172.16. Но это дело вкуса.
  
• 3. Ни разницы, ни усложнения нет и в помине. Стандартности тут тоже никакой.
  
• 4. Каждую подсеть в свой VLAN. Ибо нефиг.
  
• 5. Серверы в отдельных подсетях. Причём не одной. Что делать серверу видеонаблюдения в подсети бухгалтерии?
  
• 6. Стройте схему на основании потоков трафика, а не по некоему мистическому наитию.
  
• 7. Не у телефонии, а у некоторых коммутаторов есть специальная работа с VoiceVLAN. да, только экономия портов. Если не работал - то и не связывайся. Потом поэкспериментируешь.
  
• 8. По требованиям безопасности сеть видеонаблюдения вообще должна быть по возможности физически отделена от пользовательской. Отдельные коммутаторы и кабельные линии. да и трафика они генерят - могут забивать каналы, оно надо? То же и с линиями охранно-пожарной сигнализации - но тут строго, никаких "по возможности".
  
• 9. Сервер печати. И да - он и принтеры в отдельном VLAN.
  

Ставим L3 коммутатор, который будет рулить потоком, его же добавляем в качестве шлюза.

Ставь сразу нормальный маршрутизатор.
Потому что коммутатор, хоть и L3, тебе ничего не даст во вменяемой форме - ни статистики, ни управления, ни наблюдения.

Ничего он не сделает. Твоей вины в том, что некие третьи лица атакуют твой адрес - нет. Ни прямой, ни косвенной.

и кто-нибудь решит задудосить

Ты сперва спроси себя и честно себе же ответь - вот ты правда кому-то нахрен нужен настолько, чтобы тебя ДДоСить? Особенно с учётом того, что действительно реальный ДДоС, а не детские игры в песочнице - занятие в общем-то недешёвое.

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

Процитирую INTUIT.RU: Основы сетей передачи данных.

Постоянная и динамическая коммутация

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

• сети с динамической коммутацией ;
  
• сети с постоянной коммутацией.
  
  

В сетях с динамической коммутацией:

• разрешается устанавливать соединение по инициативе пользователя сети;
  
• коммутация выполняется только на время сеанса связи, а затем (по инициативе одного из пользователей) разрывается;
  
• в общем случае пользователь сети может соединиться с любым другим пользователем сети;
  
• время соединения между парой пользователей при динамической коммутации составляет от нескольких секунд до нескольких часов и завершается после выполнения определенной работы — передачи файла, просмотра страницы текста или изображения и т.п.
  

Примерами сетей, поддерживающих режим динамической коммутации, являются телефонные сети общего пользования, локальные сети, сети TCP/IP.

Сеть, работающая в режиме постоянной коммутации:

• разрешает паре пользователей заказать соединение на длительный период времени;
  
• соединение устанавливается не пользователями, а персоналом, обслуживающим сеть;
  
• период, на который устанавливается постоянная коммутация, составляет обычно несколько месяцев;
  
• режим постоянной ( permanent ) коммутации в сетях с коммутацией каналов часто называется сервисом выделенных ( dedicated ) или арендуемых ( leased ) каналов;
  
• в том случае, когда постоянное соединение через сеть коммутаторов устанавливается с помощью автоматических процедур, инициированных обслуживающим персоналом, его часто называют полупостоянным (semi-permanent) соединением, в отличие от режима ручного конфигурирования каждого коммутатора.
  

Никакую.
Формула не может изменить другую ячейку. Формула не может именно изменить себя - только посчитать новое значение.
Это делается либо формулой в отдельном столбце с последующей заменой исходного столбца на рассчитанные значения, либо процедурой на VBA.