Akina

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

Если гипервизор не единственный, придётся на рабочем выполнить экспорт, потом перенести накопитель на другой, там импортировать по месту и затем сливать. Если же гипервизор единственный, или придётся собирать страйп, понадобится 18Т пространства (или два тома - 9 для экспорта и 14 для импорта и слияния), потому что нужно будет делать импорт с созданием нового идентификатора и, соответственно, с копированием.

К слову, все эти операции можно проводить и на примонтированной шаре. Только сетевушку желательно на 10Г, или это будет очень долго.

Конечно, не исключено, что слияние даст суммарно финальный том не 5+4=9, а меньше... но я бы на это не рассчитывал. А если в процессе кончится место, и слияние оборвётся по ошибке, то виртуалка, скорее всего, умрёт. Именно поэтому операцию следует выполнять на экспортированной и реимпортированной копии.

Есть и ещё вариант. Выполнить внутри виртуалки бэкап тома с данными на подключенный третий диск. А потом пересоздать рабочий диск и восстановить.

Либо подключить ещё один, пустой, образ, и внутри виртуалки собрать и синхронизировать софт-mirror, потом развалить, оставив только том-копию, убрать том-оригинал и мигрировать на его место копию. Тогда получится обойтись дополнительным томом на 9Г, но геморроя куда как больше. Зато плюс этого способа - он допускает выполнение всех операций без остановки виртуалки.

Пинг гарантированно увеличится. Но при полностью исправном, неперегруженном и правильно настроенном оборудовании зарегистрировать эту разницу не получится.

По смыслу происходящего во втором блоке кода - значение в поле SteamID таблицы qq_player_acc должно быть уникальным.

Соответственно два вопроса.

1. Объявлено ли указанное поле в структуре указанной таблицы уникальным? Если нет - то почему? Добавьте требование уникальности.

2. Что мешает выполнить обычный INSERT IGNORE или, если надо обновлять существующую запись введёнными значениями, то INSERT ODKU или REPLACE INTO?

PS. INSERT {table} .. WHERE EXISTS ( {table} ) - вообще-то недопустимый синтаксис.

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

В PostgreSQL это вообще элементарная операция. Можно удалить запись в CTE и вставить её во внешнем запросе, можно наоборот. То, как выполнять, определяется возможными зависимостями и интерференциями.

WITH cte AS (
    DELETE
    FROM table1
    WHERE {criteria}
    RETURNING *
)
INSERT 
INTO table2
SELECT *
FROM cte;

-- или 

WITH cte AS (
    INSERT 
    INTO table2
    SELECT *
    FROM table1
    WHERE {criteria}
    RETURNING id
)
DELETE
FROM table1
WHERE id IN (
    SELECT id
    FROM cte
);

Sample fiddle

Само собой, вместо звёзд может быть (даже правильнее сказать - должен быть) перечень определённых полей и выражений.

PS. Хотя намного разумнее оставить одну таблицу и выполнять "мягкое удаление". Внимательнейшим образом прочитайте ответ alexalexes. При очень большом количестве записей, влияющем на производительность, такую таблицу можно и секционировать.

Но таблиц стало много и неопределённо много.

Вижу два варианта.

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

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

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

На строго в рамках PDO - полностью согласен с предыдущим оратором. Никак.

Первым делом в свойствах старого скопа корректируется время выделения адреса. Для стационарных узлов обычно по умолчанию ставится 5 или 7 дней. Первым делом меняем это время на 1 час. Это не сильно увеличит нагрузку на сеть. Ждём, пока все не перейдут на это время выделения. Затем, непосредственно перед переездом, ужимает это время до 5 минут. И через час начинаем собственно переезд. для чего просто (в зависимости от того, что умеет сервер) либо повышаем приоритет нового скопа относительно старого, либо просто отключаем старый. За час все перепрыгнут в новый скоп. После чего там можно поднять время выделения в новом скопе до старого значения в неделю, а старый вообще удалить.

Но это просто процесс перевода всех динамиков в новую подсеть. А чтобы всё работало, нужно ещё много предварительных телодвижений, которые обеспечат отсутствие сбоев в работе.

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

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

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

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 даст кучу ссылок - что приятно, большинство русскоязычные. Выбирай не хочу.

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

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

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