Akina

Отслеживать - нет.
Можно написать скрипт, который будет получать текущую таблицу (interface bridge host print либо interface ethernet switch host print) и сравнивать с предыдущей версией. По результатам сравнения сообщать. Период запуска, само собой, меньше времени жизни записи в кэше.
Хотя разумнее одним скриптом сливать в файл, а потом другим скриптом обрабатывать и кляузничать - но уже не так часто. Или вообще в БД писать, для истории...

1. Собственный сервер - скорее да, чем нет. На Windows - 33/67 (альтернативы - Linux и NAS). AD - точно нет.
2. Коммутатор, разделяющий сеть на изолированные сегменты с помощью VLAN. При необходимости ограниченного или контролируемого доступа из сегмента в сегмент - маршрутизация Микротиком.
3. См. п. 1.
4. Видео - есть. Полезных - нет.

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

SNR-SFP-W35-3 1000BASE-X 3km, 6dB TX 1310nm/RX 1550nm - это одномодовый свисток. Одноглазый, кстати.
ML-SG-2DFM-31LD 1.25G SFP 1310nm 2KM DDM - это многомодовый свисток. Вообще двуглазый.

Они говорят на разных языках. Работают на разном волокне. И никогда друг друга не поймут.

Mission impossible.

Когда каскадное обновление это плохо?

Каскадное обновление - в большинстве случаев это... глупо.

Вспомним, что это вообще такое.

Имеется связь, реализованная внешним ключом. Некое поле (в общем случае - выражение) основной таблицы, уникально индексированное, является значением, на которое ссылается некое поле (или выражение) подчинённой таблицы (возможно, и той же самой).

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

Что же есть каскадное обновление? Это изменение связанного значения в подчинённой таблице, если изменяется значение основной таблицы. Ну то есть если изменяется (вспоминаем сказанное выше) значение первичного ключа или поля, объявленного уникальным. В основной таблице. Ага...

Ну то, что изменение/корректировка значения поля первичного ключа есть bad practice (читай - дурь голимая), хорошо известно, обосновано и весьма логично. Нет, реально возможны ситуации, когда такая операция оправдана и имеет смысл - но такая ситуация абсолютно всегда одноразовая, и есть составная часть административного обслуживания. А если подобная надобность возникла на уровне пользователя, в рабочем процессе - то это гарантия наличия серьёзной ошибки в проектировании БД.

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

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

Шаблон:

UPDATE main_table
JOIN ( SELECT id, MAX(created_at) AS created_at
       FROM ( SELECT id, created_at from slave1
              UNION ALL
              SELECT id, created_at from slave2
              UNION ALL
              ...
              UNION ALL
              SELECT id, created_at from slaveN             
              ) AS alldates
       GROUP BY id
       ) AS maxdate USING (id)
SET main_table.created_at = maxdate.created_at

Между маршрутизаторами внутри частной сети WAN или LAN?

Частная - это по-ихнему private.
Private network - это подсеть, которая не маршрутизируется в Интернете (явно или условно). В первую очередь подсети "серых" адресов (RFC 1918), но вообще таких подсетей (именуемых bogon networks) под полтора десятка.
Сеть, адресация которой построена на не маршрутизируемых глобально адресах - это LAN.

Суёшь линк/ярлык в
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

А к какой заднице тут вообще CRON прислонился?

Если же имеется в виду, что указанным запросом надо удалять записи регулярно - то CRON для решения такой задачи просто нафиг не нужен..

Using the Event Scheduler

PS. И в запросе следует избавиться от WHERE IN и переписать его на обычный JOIN.

Ну там не головоломки, а самые обычные задачки.

Да, сайты, где есть не только SQL-задачи, но и их решения, имеются. Тот же sql-ex, например.. Правда, не припомню таких, где бы предлагалось и объяснялось решение именно авторами сайта - решения (а практически любая задача имеет много альтернативных, порой радикально различающихся подходом, решений) можно найти либо в комментариях пользователей к задаче, либо на прилагаемом форуме.

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

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

Если вес является единственным параметром, то это "Задача линейного раскроя".

Ну и нехватает критерия максимума. Например, критерием может быть минимальный остаток допустимого веса, а может быть и максимальный процент заполнения...

Оборудование на другом конце - ситуация штатная. Тестер обязан её предусматривать, в т.ч. и вариант с PoE.

Про убитый тестером порт даже не слышал. Но если такое произойдёт, то это будет явно следствие неисправности тестера. Либо "после, но не вследствие".

А вот если на другом конце окажется что-то, что использует витую пару, но сетевым интерфейсом не является (например, порт "дальнобойной" АТС), можно остаться и без тестера...

UPDATE test
JOIN ( SELECT id, ROW_NUMBER() OVER (ORDER BY id) new_id
       FROM test ) AS cte USING (id)
SET test.new_id = cte.new_id;

id - UNIQUE NOT NULL, либо вообще PRIMARY KEY. Поле либо выражение.

Предполагая, что тип данных поля - DECIMAL(xx, 3):

SELECT MIN(value) + 0.001
FROM test t1
WHERE NOT EXISTS (
  SELECT NULL
  FROM test t2
  WHERE t1.value = t2.value - 0.001
  );

https://dbfiddle.uk/9Yyi-pol

PS. Возвращаемое значение не может быть меньше минимального из уже имеющихся в таблице.

из той статьи появилось предположение

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

Таблица часто join-тся в запросах через hash.

Что, берутся все записи таблицы, и сортировка выходного набора тоже по этому полю? нет? тогда статья тут близко не лежала.

"hash" - это primary key и содержит md5 текста

Тип данных и размер мы должны сами придумать?

Какое преимущество для текущей конфигурации обеспечивает настройка сетей VLAN?

Это же учебное задание, верно? и, поскольку маска у клиентских узлов не указана, следует полагать, что используется классовая адресация, и соответственно все 6 указанных узлов находятся в одной подсети.

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

Можно же взять S1 и подключить к нему PC1, PC4 и т.д.

Это же учебное задание, верно? ну так если имеется именно показанная схема, без обозначенных пространственных зон, то однозначно предполагается, что подключение клиентских узлов к другим коммутаторам - невозможно физически.

Так что никаких "можно же взять" - нельзя, и точка.

WITH cte AS (
  SELECT *,
         SUM((flag IS NULL) :: INT) OVER (PARTITION BY user_id ORDER BY product_id ASC) grp
  FROM test
  )
SELECT product_id, user_id, flag,
       DENSE_RANK() OVER (PARTITION BY user_id ORDER BY grp ASC) "rank"
FROM cte
ORDER BY 1,2;

fiddle