Мертвые блокировки базы данных
Определите div - class:
all_num_class = soup.find_all('div', class_='classname')
for ai in all_num_class:
print(ai.get('data-fmid'))
Или вы можете использовать любое attr для идентификации div, который вы хотите сканировать:
all_num_class = soup.find_all('div', attr={'class':'classname'})
for ai in all_num_class:
print(ai.get('data-fmid'))
6 ответов
- Все транзакции вставка \ обновление в том же порядке.
- Удаляет; определить записи, которые будут удален за пределы транзакции и затем попытайтесь удалить в наименьшая возможная транзакция, например поиск по первичному ключу или подобному идентифицируется на этапе поиска.
- Небольшие транзакции обычно.
- Индексация и другие показатели настройка на обе скорости транзакций и продвигать поиски индекса по сканы.
- Избегайте «горячих столов», например, одна таблица с приращением счетчики для других таблиц первичные ключи. Любой другой тип «распределительного щита» настройка рискованна.
- Особенно если не использовать Oracle, учиться выглядящее поведение цели СУБД подробно (оптимистично / пессимистичный, уровень изоляции и т. д.) Убедитесь, что вы не разрешаете блокировку строк перерасти в блокировки таблицы, как некоторые RDMS будут.
Тщательно спроектируйте процессы своей базы данных, чтобы исключить как можно больше транзакций, которые включают несколько таблиц. Когда у меня был контроль над дизайном базы данных, никогда не было случая тупика, из-за которого я не мог спроектировать условие, которое его вызвало. Нельзя сказать, что они не существуют и, возможно, изобилуют ситуациями вне моего ограниченного опыта; но у меня не было недостатка в возможностях улучшить дизайн, вызывающий такие проблемы. Одна очевидная стратегия состоит в том, чтобы начать с хронологической таблицы только для записи для вставки новых завершенных атомарных транзакций без взаимозависимостей и применять их эффекты в упорядоченном асинхронном процессе.
Всегда используйте уровни изоляции базы данных по умолчанию и параметры блокировки если только вы не будете абсолютно уверены, какие риски они несут, и доказали это тестированием. Перепроектируйте ваш процесс, если это вообще возможно, в первую очередь. Затем наложите наименьшее увеличение защиты, необходимое для устранения риска (и протестируйте, чтобы доказать это). Не увеличивайте ограничения «на всякий случай» - это часто приводит к непреднамеренным последствиям, иногда того типа, который вы намеревались избежать.
Чтобы повторить точку зрения в другом направлении, большая часть того, что вы прочтете на этом и других сайтах, выступающих за изменение настроек базы данных, чтобы справиться с транзакционными рисками и проблемами блокировки, вводит в заблуждение и / или неверно, что демонстрируется тем, как они конфликтуют друг с другом так регулярно. К сожалению, особенно для SQL Server, я не нашел ни одного источника документации, который бы не был безнадежно запутанным и неадекватным.
Я обнаружил, что одним из лучших вложений, которые я когда-либо делал во избежание взаимоблокировок, было использование Object Relational Mapper, которое могло бы заказывать обновления базы данных. Точный порядок не важен, если каждая транзакция записывает в одном и том же порядке (и удаляет точно в обратном порядке).
Причина, по которой это позволяет избежать большинства взаимных блокировок, заключается в том, что ваши операции сначала всегда - таблица A, затем таблица B, затем таблица C (что, возможно, зависит от таблицы B).
Вы может достичь аналогичного результата, если вы проявляете осторожность в своих хранимых процедурах или коде доступа уровня данных. Единственная проблема заключается в том, что для этого требуется большая осторожность, чтобы делать это вручную, тогда как ORM с концепцией Unit of Work может автоматизировать большинство случаев.
ОБНОВЛЕНИЕ: Удаление должно выполняться вперед, чтобы убедиться, что все соответствует ожидаемой версии (вам все еще нужны номера версий записей или временные метки), а затем удалить в обратном направлении, когда все подтвердит. Поскольку все это должно происходить в одной транзакции, вероятность того, что что-то изменится из-под вас, не должна существовать. Единственная причина, по которой ORM делает это задом наперед, состоит в том, чтобы соблюдать ключевые требования, но если вы выполните проверку вперед, у вас будут все замки, которые вам нужны, уже под рукой.
Я анализирую все действия базы данных, чтобы определить для каждого из них, должна ли она быть в транзакции с несколькими операторами, а затем для каждого такого случая, какой минимальный уровень изоляции требуется для предотвращения взаимных блокировок ... Как вы сказали, сериализуемые, безусловно, будут делать это ...
Как правило, только очень немногие действия с базой данных требуют, прежде всего, транзакции с несколькими операторами, и лишь немногие требуют сериализуемой изоляции для устранения взаимоблокировок.
Для тех, кто это делает, установите уровень изоляции для этой транзакции, прежде чем начать, и сбросьте ее, какой бы она ни была по умолчанию после ее фиксации.
Дедлоки не важны. Просто будьте готовы повторить ваши транзакции в случае неудачи. 1252 И держи их короткими. Короткие транзакции, состоящие из запросов, которые касаются очень небольшого количества записей (благодаря магии индексации), идеально подходят для минимизации взаимных блокировок - блокируется меньше строк и на более короткий период времени. блокировка столов; они блокируют ряды; так что взаимоблокировки немного менее вероятны.
Вы также можете избежать блокировки, используя MVCC и уровень изоляции транзакции CONSISTENT READ: вместо блокировки некоторые потоки будут просто видеть устаревшие данные.
Ваш пример будет проблемой только в том случае, если база данных заблокирует ВСЮ таблицу. Если ваша база данных делает это ... run:)