Akina

В чем тогда проблема для провайдера просто блокировать все зашифрованные запросы?

Это противоречит действующему законодательству. См. законы о предоставлении услуг связи и о предоставлении телематических услуг.

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

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

В комментариях дампа указано, что источником дампа послужил сервер MySQL версии 8.0.28. Поэтому восстанавливать следует на сервере MySQL, причём крайне желательно на версии не ниже 8.0.4. При восстановлении на более младшей версии или на частично совместимой MariaDB возможны проблемы при восстановлении, которые потребуют ручной корректировки дампа - а для этого нужны определённые знания, которых, скорее всего, нет.

Для восстановления на локальном MySQL-сервере самое разумное - загрузить клиент командной строки и в нём:

• создать новую БД (CREATE DATABASE databasename;) (в комментариях дампа указано имя history_futures_binance, так что разумно использовать именно его, если такой БД на сервере нет)
  
• сделать её текущей (USE databasename)
  
• дать команду на развёртывание дампаSOURCE 'x:\path\filename.sql'.
  

Скорее всего, всё будет выполнено без ошибок, и в результате БД будет восстановлена. Если же при выполнении возникнут проблемы, будет выведено какое-то сообщение об ошибке - и в зависимости от него нужно будет предпринимать какие-то корректирующие действия.

Вот нафига было удалять предыдущую версию вопроса?

Ладно, повторю. У FileSystemObject нет метода Copy, он есть у объектов Folder и File. Следовательно,

Set File = fso.GetFile(ThisWorkbook.Path & "\doc.docm")
Set File = fso File.Copy("%Temp%\d6c.docm")

PS. Что такое "открытый файл", где, кем и вообще почему он открытый - так и не понял.

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, тебе ничего не даст во вменяемой форме - ни статистики, ни управления, ни наблюдения.

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

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

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

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