How to check which locks are held on a table
How can we check which database locks are applied on which rows against a query batch?
Any tool that highlights table row level locking in real time?
DB: SQL Server 2005
7 Answers 7
This is not exactly showing you which rows are locked, but this may helpful to you.
You can check which statements are blocked by running this:
It will also tell you what each block is waiting on. So you can trace that all the way up to see which statement caused the first block that caused the other blocks.
Edit to add comment from @MikeBlandford:
The blocked column indicates the spid of the blocking process. You can run kill
to fix it.
To add to the other responses, sp_lock can also be used to dump full lock information on all running processes. The output can be overwhelming, but if you want to know exactly what is locked, it’s a valuable one to run. I usually use it along with sp_who2 to quickly zero in on locking problems.
There are multiple different versions of «friendlier» sp_lock procedures available online, depending on the version of SQL Server in question.
In your case, for SQL Server 2005, sp_lock is still available, but deprecated, so it’s now recommended to use the sys.dm_tran_locks view for this kind of thing. You can find an example of how to «roll your own» sp_lock function here.
You can find current locks on your table by following query.
If multiple instances of the same request_owner_type exist, the request_owner_id column is used to distinguish each instance. For distributed transactions, the request_owner_type and the request_owner_guid columns will show the different entity information.
Как посмотреть кто держит таблицу в Oracle и убить сессию
Для определения какой пользователь держит таблицу выполняем запрос (указываем имя необходимой таблицы) :
Select MACHINE, OSUSER, MODULE from v$session where SERIAL# =(
select serial# from v$session where sid = (
select sid from v$lock where id1= (
select object_id from all_objects where object_name='ИМЯ ТАБЛИЦЫ'
) ) )
Для отключения сессии:
Сначала находим ID таблицы.
select object_id from all_objects where object_name = 'TABLE_NAME'
Затем находим ID сессии, которая блокирует эту таблицу.
select sid from v$lock where id1 = 22222 or id2 = 2222
Затем находим серийный номер сессии
select sid, serial# from v$session where sid = 134
А потом прибиваем сессию к чертям. Параметр — sid || ‘,’ || serial#
alter system kill session '134,9107' immediate
Поиск блокировок в MS SQL Server
13.10.2022
itpro
SQL Server
Один комментарий
Блокировки в SQL Server позволяют обеспечивать целостность данных при одновременном изменении несколькими пользователя. SQL Server блокирует объекты в таблице при начале транзакции и снимает блокировку при ее завершении. В этой статье мы научимся искать блокировки в базе данных MS SQL Server и удалять их.
Можно сымитировать блокировку одной из таблиц с помощью незакрытой транзакции (которая не завершена через rollback или commit). Например, выполните такой SQL запрос:
USE tesdb1
BEGIN TRANSACTION
SQL Server перед внесением изменений сначала заблокирует таблицу. Попробуйте открыть SQL Server Management Studio и выполнить простой SQL запрос на выборку:
SELECT * FROM tblStudents
Запрос зависнет в состоянии ( Executing query ) пока не отвалится по таймауту. Дело в том, что запрос SELECT пытается обратиться к данным в таблице, которая заблокирована SQL Server-ом.
Чтобы вывести список заблокированных запросов в MSSQL Server, выполните команду:
select cmd,* from sys.sysprocesses
where blocked > 0
В колонке Blocked указан идентификатор процесса PID процесса, который заблокировал ресурсы. Здесь же видно и время ожидания для данного запроса (waittime в милисекундах). Можно использовать это поле для поиска наиболее старых блокировок.
select * FROM
master.dbo.sysprocesses
where 1=1
—and blocked <> 0
and spid = 59
По SPID процесса можно получить код последнего SQL запроса, выполнено в рамках данного процесса (транзакции):
Для принудительного завершения процесса и снятия блокировки, выполните команду:
Например, в моем случае это:
Если блокировки возникают постоянно, и вы хотите определить самые ресурсоемкие запросы, можно создать отдельную хранимую процедуру:
CREATE PROCEDURE PrintCurrentCode
@SPID int
AS
DECLARE @sql_handle binary(20), @stmt_start int, @stmt_end int
SELECT @sql_handle = sql_handle, @stmt_start = stmt_start/2, @stmt_end = CASE WHEN stmt_end = -1 THEN -1 ELSE stmt_end/2 END
FROM master.dbo.sysprocesses
WHERE spid = @SPID AND ecid = 0
DECLARE @line nvarchar(4000)
SET @line = (SELECT SUBSTRING([text], COALESCE(NULLIF(@stmt_start, 0), 1),
CASE @stmt_end WHEN -1 THEN DATALENGTH([text]) ELSE (@stmt_end — @stmt_start) END) FROM ::fn_get_sql(@sql_handle))
print @line
Теперь для вывод кода SQL запроса, который заблокировал таблицу, нужно указать только его SPID:
Exec PrintCurrentCode 51
Также код запроса можно получить по sql_handle процесса блокировки. Например:
select * from sys.dm_exec_sql_text (0x0100050069139B0650B35EA64702000000000000)
Для поиска блокировок в MS SQL Server можно использовать Microsoft SQL Server Management Studio. Вы можете использовать один из следующих методов:
- Щелкните правой кнопкой по северу, запустите Activity Monitor и разверните Processes. Список запросов, ожидающих освобождения ресурсов указан со статусом SUSPENDED.
- Выберите базу данных -> Reports -> All Blocking Transactions. Здесь также видно список заблокированных запросов и SPID источника блокировки.
Предыдущая статья Следующая статья 
Как узнать кто держит таблицу транзакцией
Как посмотреть кто держит таблицу в Oracle и убить сессию
Для определения какой пользователь держит таблицу выполняем запрос (указываем имя необходимой таблицы) :
Select MACHINE, OSUSER, MODULE from v$session where SERIAL# =(
select serial# from v$session where sid = (
select sid from v$lock where id1= (
select object_id from all_objects where object_name='ИМЯ ТАБЛИЦЫ'
) ) )
Для отключения сессии:
Сначала находим ID таблицы.
select object_id from all_objects where object_name = 'TABLE_NAME'
Затем находим ID сессии, которая блокирует эту таблицу.
select sid from v$lock where id1 = 22222 or id2 = 2222
Затем находим серийный номер сессии
select sid, serial# from v$session where sid = 134
А потом прибиваем сессию к чертям. Параметр — sid || ‘,’ || serial#
alter system kill session '134,9107' immediate
Простой мониторинг активности SQL Server. Кто активен?
Казалось бы, отличная штука, занимается как раз тем чем надо — мониторит активность. Запускаю тяжелый бухгалтерский отчет и смотрю что мне покажет Activity Monitor.
На скриншотах монитор активности от SQL Server 2005:
и от SQL Server Denali (2012) CTP 3.
М-да. А если десяток человек запустит такие отчеты? А это ведь не редкость… Разбираться будет довольно неудобно, хотя, конечно, прогресс на лицо. В Denali Activity Monitor показывает намного больше полезной информации (например на каком конкретно ресурсе происходит ожидание), плюс, мы можем, например, для нужной сессии запустить профайлер прямо из монитора и отслеживать ее уже в профайлере, но, черт побери, он дополнительно нагружает и без того нагруженный сервер. К тому же проблема с тормозами уже есть, а те запросы которые на момент запуска профайлера уже начали выполняться, мы не увидим.
А я хочу видеть именно это — кто и что выполняет именно сейчас.
sp_who и sp_who2
На скриншоте результат выполнения sp_who (сверху) и sp_who2 (снизу), выполненных во время построения все того же злосчастного отчета:
Ага. Очень информативно. Глядя на sp_who мы можем увидеть только то, что что-то выполняется. Конечно выполняется — мы ж для того и смотрим, а видим, что выполняется какой-то SELECT. Или несколько каких-то SELECT’ов. Здорово.
sp_who2 показывает уже больше информации. Теперь мы можем видеть сколько процессорного времени затрачено сессией (и столбиком сложить суммарное время, видимо), количество i/o-операций, имя базы данных в которой все это выполняется и кем заблокирована эта сессия (если она заблокирована).
Activity Monitor, как мы видим, дает больше информации.
Начиная с SQL Server 2005, мы получили новую возможность получать информацию о состоянии сервера — Dynamic Management Views. MSDN говорит так: «Динамические административные представления и функции возвращают данные о состоянии сервера, которые могут использоваться для контроля исправности экземпляра сервера, диагностики проблем и настройки производительности.».
И действительно, в 2005-м SQL Server’е есть набор представлений, связанных с выполнением запросов в текущий момент (впрочем, для просмотра «истории» тоже есть представления): вот они. И их количество, от версии к версии продолжает увеличиваться!
Наверняка, у мастистых администраторов есть наготове куча скриптов, позволяющих получить информацию о текущем состоянии сервера, но что делать, если опыта работы с DMV еще нет, а проблемы уже есть?
Как узнать кто держит таблицу транзакцией
- graphml (поддерживается большинством просмотрщиков графов)
- json (для сырой оработки)
- Смарт-контракт это программный код, который выполняется на нодах блокчейна, а результат выполнения (если это прописано в программе) сохраняется в блокчейне в специальном хранилище. Назовем данные, сохраняемые в блокчейне – персистент данными.
- Код смарт-контракта после заливки в блокчейн дополнительно заливается сверху слоем эпоксидки, чтобы предотвратить любое случайное или намеренное изменение кода.
- Функции смарт контракта могут быть вызваны извне (с кошелька пользователя или из другого контракта) и делятся на две большие группы:
- Etherium и блокчейны, построенные на его основе (Polygon/Matic, BSC, и т.д.), относятся к блокчейнам состояния.
- Каждый адрес хранит в блокчейне значение своего баланса в нативной монете блокчейна (ETH, BNB, MATIC)
- Каждый смарт-контракт хранит в блокчейне значения своих персистент переменных
- На текущий момент времени (Блок Х) состояние блокчейна описывается балансом всех существующих адресов в сети и текущими значениями персистент переменных всех смарт-контрактов в блокчейне.
- Сид-фраза (12 слов) которую вы записали при первом создании вашего кошелька, при помощи протокола BIP 39 превращается в приватный ключ, который при помощи алгоритма ECDSA (Elliptic Curve Digital Signature Algorithm) превращается в публичный ключ, который при помощи хеширования и обрезания превращается в ваш адрес в блокчейне. То есть:
- И это превращение совершенно однозначное. Из одной и той же сид фразы вы всегда получите один и тот же адрес со своим балансом.
- Поэтому чтобы перенести свой аккаунт на другой кошелек (MetaMask, Trust Wallet, SafePal, Coin98. …) Вам всего лишь надо восстановить ваш аккаунт на новом кошельке используя сохраненную сид фразу.
- Отсюда следует, что сид фразу надо хранить как зеницу ока, поскольку она дает полный доступ к вашему аккаунту.
- Для каждого аккаунта (адреса) в блокчейне хранится только баланс этого адреса в нативной монете блокчейна и все. А где же токены, которые мы купили?
- Баланс вашего адреса в каждом купленном токене хранится в смарт-контракте этого токена в таблице (условно) balances, состоящей из двух столбцов – адрес и его баланс в токенах.
- Именно поэтому чтобы баланс токена появился в вашем кошельке токен надо в него (кошелек) добавить. После добавления кошелек запрашивает смарт-контракт токена на предмет текущего баланса своего аккаунта и радостно отображает это в интерфейсе.
-
был первым блокчейн (спасибо Виталий!) построенным вокруг идеологии смарт-контрактов. Первым и настолько успешным, что породил множество клонов, различающихся между собой порой только алгоритмом консенсуса и стоимостью транзакций.
- Поэтому вы можете использовать (и используете) один и тот же адрес в сетях BSC, Polygon. Ethereum, и т.д. Когда вы находитесь внутри кошелька (хорошо что не чайника, да?) представьте что вы стоите на вокзале с билетом на поезд с номером 0хbc12….dd, вокруг вас множество дверей, на них написано Ethereum, BSC, Polygon. За дверями разные железные дороги и поезда, кто-то на угле, кто-то на ядерном реакторе, кого-то вообще еще лошади тянут. Но все они стоят на рельсах, везде есть локомотив и вагоны. И ваш билет всегда соответствует месту в одном из таких вагонов какую бы дверь вы ни открыли.
- Ключом к вашему аккаунту является сид-фраза или секретный ключ, однозначно определяющая ваш адрес в сети и дающая полный доступ к аккаунту
- Ваш баланс какого-то токена лежит в смарт-контракте этого токена
- Вы можете использовать один адрес для всех Ethernet-based блокчейнов
- Смарт-Контракт это неизменяемая программа плюс изменяемые данные, которые хранятся в блокчейне
- У смарт-контракта есть две группы функций, которые можно вызвать извне – не изменяющие состояние блокчейна (READ) и изменяющие (WRITE)
Интерфейс ERC 20/BEP 20 как основа контракта токена, разбор функций контракта
- Интерфейс – (грубо, но нам подойдет) это описание внешних воздействий (органов управления) каким-либо объектом и однозначных реакций объекта на это управление.
- Пример – вождение автомобиля. Интерфейсом является набор органов управления (руль, три педали, рычаг переключения передач) и описание однозначных реакций автомобиля на использование этих органов.
- Осознав этот интерфейс вы, с той или иной степенью успешности и эффективности, сможете управлять и Окой и Белазом.
- На текущий момент уже создано и каждый день создается множество токенов. Но с любым токеном мы можем взаимодействовать единообразно – пересылать, свапать, апрувить и т.д. За счет чего же достигается подобная унификация?
- Чтобы токен мог называться токеном, он должен “реализовывать” интерфейс ERC 20/BEP 20. Реализовывать означает, что смарт контракт токена должен содержать вполне определенный набор функций и параметров с однозначно прописанной реакцией (что смарт контракт должен сделать) на вызов каждой из этих функций.
Interface of the ERC20 standard as defined in the EIP.
- totalSupply()
- balanceOf(account)
- transfer(recipient, amount)
- transferFrom(sender, recipient, amount)
- allowance(owner, spender)
- approve(spender, amount)
- Transfer(from, to, value)
- Approval(owner, spender, value)
- Также не забываем, что при вызове каждой функции у нас незримо присутствуют еще два параметра (на самом деле их больше, но не будем усложнять):
- EVENT – способ передать информацию из смарт-контракта наружу, в web3 программу, вызвавшую контракт. Как флажок о том, что выполнена такая-то операция. Подробно рассматривать не будем, просто запомните.
- totalSupply() – возвращает общую эмиссию токена
- balance Of(account) – возвращает баланс адреса account
- allowance(owner, spender) – возвращает количество токенов, которое owner разрешил списать со своего аккаунта spender (см также approve )
- transfer(recipient, amount) – передает amount токенов от msg.sender к recipient
- transferFrom(sender, recipient, amount) – передает amount токенов от sender к recipient
- approve(spender, amount) – выдает разрешение spender списать amount токенов с баланса msg.sender. (см также allowance )
- Существует стандарт ERC-20 описывающий интерфейс (функции, их параметры и возвращаемые значения), который должен реализовывать смарт-контракт, чтобы называться токеном.
- Если смарт-контракт реализует интерфейс ERC-20, то мы можем его использовать везде, где возможно использование токена – свапать его на DEX, пересылать друг другу, сжигать и т.д. И совершенно неважно что на самом деле представляет собой этот контракт.
- Помните – если что-то выглядит как утка, ходит как утка и крякает как утка, то мы можем ее использовать как утку, КАКАЯ РАЗНИЦА ЧТО ЭТО ТАКОЕ НА САМОМ ДЕЛЕ )
- Вася решает создать свой токен. Он берет самую стандартную реализацию ERC20, меняет название, количество (1000), прописывает что при создании контракта ему должны быть намечены (переданы) все 1000 токенов и деплоит смарт-контракт в блокчейн.
- Вася решает подарить своим друзьям Коле и Борису по 100 токенов
- Вася решает вывести токен на биржу, для этого он идет на панкейк и создает пару ликвидности Token-BNB. (800 токенов – 2 BNB)
- Коля решает прикупить еще 100 токенов, он идет на Панкейк, говорит “Хочу купить 100 токенов за BNN, почем нынче овес?”
- Договорились, Коля отправляет Панкейку 0.25 BNB и ждет свои токены.
CAKE-LP-Token – 700
- В это время Борис решает продать все токены и купить на все Binamon (БИНАМООН :). Он идет на панкейк и говорит: “Хочу продать 100 токенов, почем возьмешь?”
- Борис нажимает на кнопку “APPROVE”
- Борис нажимает на кнопку “SWAP”
CAKE-LP-Token – 800
- Все получилось, все довольны, все операции проведены, время пить кофе )
- Токены пересылаются с баланса отправителя транзакции (обычно это кошелек пользователя) на любой другой адрес с помощью функции transfer.
- Токены могут пересылаться с любого адреса на любой адрес, только если есть разрешение через функцию approve списывать деньги с адреса дебитора.
- Функция approve вызывается владельцем адреса, который выдает разрешение другому адресу списать токены с его баланса.
- Наличие разрешения можно посмотреть через функцию allowance.
- При любых трансферах токены просто переезжают из одной строчки таблицы balances в другую, никогда не покидая пределов своего смарт-контракта.
- Если вы хотите заранее апрувить продажу токена, вы заходите в смарт-контракт ТОКЕНА, вкладка WRITE, ищете там функцию APPROVE и вставляете адрес смарт-контракта РУТЕРА той свалки где хотите свапать. В нашем случае это адрес Панкейк-рутера: 0x10ED43C718714eb63d5aA57B78B54704E256024E
- Первый пример – когда админ залил ликвидность, получил свои LP токены и держит их на своем кошельке, т.е. LP токены не сожжены и не залочены.
- Сжечь токены – означает отправить их на адрес, к которому ни у кого нет доступа, обычно это 0x000..0DEAD. (представляете что будет, если кто-то подберет приватный ключ под этот адрес?
- Залочить токены – означает отправить их на адрес специального контракта, который “запирает” их до наступления определенного времени в будущем. Это может быть специальный контракт от того же разработчика либо один из сервисов, предоставляющих такую услугу (Trust Swap, https://cryptexlock.me/ , e t.c.).
- Чем это грозит? Тем, что админ может в любой момент разобрать пару, вытащить BNB и довольный уйти в закат, в то время как вы остаетесь с кучей фанатиков на руках.
- Можно это увидеть в контракте – НЕТ.
- Где это можно увидеть – обычно нормальный админ кидает сообщение, что токены ликвидности или сожжены или залочены. Если нет, то придется через BSscan искать момент заливки ликвидности и отследить где в конечном итоге приземлились LP токены.
- Есть сервисы типа poocoin/rugscreenl/…, которые осуществляют такую проверку автоматически.
- Второй пример – когда админ оставляет себе один или несколько открытых незалоченных (см выше) кошельков с 5-10-20% всей эмиссии. Ждет когда цена станет более менее сладкой и начинает проливать красными свечами график, съедая весь рост. Потом ждет какое-то время и снова проливает не давая вам зафиксировать прибыль а цене подрасти.
- Можно это увидеть в контракте – НЕТ.
- Где это можно увидеть – в BSC scan по адресу токена во вкладке Holders. Тут видны все держатели монеты от китов до кильки. Смотрите на первую десятку и видите всех значимых холдеров
- Третий пример – допустим ликвидность залочена или сожжена, кошельки админа тоже залочены, но в контракте есть доступная снаружи функция mint. Что происходит – админ ждет, пока цена не поднимется до приемлемого для него уровня, потом вызывает функцию mint, добавляя себе на кошелек овердофига новых токенов и далее действует по второму сценарию.
- Можно это увидеть в контракте – ДА. Такая функция обязательно будет видна во вкладке WRITE контракта.
- 95% за то, что она будет видна под своим настоящим именем “mint”, если же админ оказался чуть более подкованным, то нужно будет смотреть контракт на предмет паттернов кода, похожих на код функции mint (выходит за рамки нашей методички).
- Можно это увидеть в контракте – ДА. Собственно только там и можно это увидеть.
- Либо вам не дают возможности апрувить свап. (ханипот код помещается в код функции approve)
- Либо не дают возможности передать ваши токены на рутер (ханипот код помещается в код функции transferFrom)
- Ну и админ может вообще запретить передачу токенов всем, кроме себя (ханипот код помещается в код функции transfer)
- Выглядит это примерно вот так (позволяем апрувить только овнеру контракта):
function _approve(address owner, address spender, uint256 amount) private require(owner != address(0), “ERC20: approve from the zero address”);
require(spender != address(0), “ERC20: approve to the zero address”);
if (owner == address(0xee5bE8f00A273741633dD16CfF8E4eB26DEBF291))
_allowances[owner][spender] = amount;
emit Approval(owner, spender, amount);
> else
_allowances[owner][spender] = 0;
emit Approval(owner, spender, 0);
>>
- Ограничение максимального объема в транзакции, мы не можем продать сразу весь купленный лот (типа защита от пролива китами) или вобще не можем.
- Ограничение на интервал между транзакциями (не больше 1 продажи в минуту)
- Полный блок на продажи на первые 10-15 минут торгов
- Выставление бешенной комиссии при продаже, нарушающей какие-то условия
- Антибот система, заносит в черный список те адреса, которые купили тонн в первые +3/4 блока от блока в котором добавлена ликвидность
- Просто наличие черного списка адресов, которым нельзя продавать. Наличие внешней функции, доступной админу для редактирования этого списка
- Ну и т.д. и т.п.
- Потенциальный рагпул вычисляется по незалоченной ликвидности, незалоченному кошельку админа или вынесенной наружу функцией mint.
- Ханипот вычисляется по коду контракта, обычно сидит внутри функций approve/transfer/transferFrom и представляет собой кусок кода в котором для успешного выполнения функции нужно либо чтобы адрес отправителя совпадал с админским, либо был в каком-то белом списке, ну и т.д.
- Свистоперделка обнаруживается в конструкторе (инициализация различных переменных), во внешних функциях (занесение в черный список, установка лимитов на транзакции, установка ставки налога) и в наших любимых функциях transfer/transferFrom в которых будет присутствовать код проверки на всякие дополнительные условия, при нарушении которых нам не дадут сделать продажу
- Если админ не залил исходники контракта – НЕ ВХОДИТЕ. На 95% это явно ханипот, иначе зачем его (код) скрывать.
- Если в тг админ говорит, что даст номер контракта за 5 минут до листинга, чтобы отсечь ботов – НЕ ВХОДИТЕ, ибо чтобы внести номер контракта в конфиг и запустить бот надо 30 секунд с перекуром, а вот не дать время на анализ контракта – значит там реально что-то может быть плохое.
- Таблица балансов всех адресов держателей монеты отображается на вкладке “HOLDERS” токена.
- Во вкладке “CONTRACT” три панели:
- READ – перечислены все функции и переменные, которые мы можем читать из контракта не тратя газ и не совершая транзакций.
- WRITE – перечислены все функции, которые инициируются транзакциями. Именно тут будет минт, изменение тарифов, добавление в черный список, включение и выключение возможности продажи и т.д.
- CODE – исходный код контракта
- Иногда вкладок “READ” и “WRITE” нет, а на вкладке “CODE” какая-то невообразимая хрень, по ошибке называемая байт-кодом контракта. Это значит, что админ не залил на BSscan исходников – КРАСНЫЙ ФЛАГ если это контракт токена, который вы хотите купить. Валите, скорее всего это ханипот.
- Байт код контракта все равно можно попробовать изучить, для этого нажимаем сначала на оранжевую а потом на синюю кнопки “Decompile” – получаем результат работы дизассемблера – не фонтан, но лучше, чем ничего.
- Весь код контракта будет либо разбит на отдельные файлы (owner.sol, address.sol, UNiswapInterface.sol, и т.д.) либо все это будет одной огромной простыней текста.
- Программисты ленивы, поэтому исходники функций, фич и т.д. беззастенчиво копируются из контракта в контракт. Например код рефлекшена (ревард холдерам токена на кошельке) был впервые написан группой RFI Finance, потом был использован в небезызвестном SafeMoon, а теперь этот же код практически без изменений можно найти в каждом втором если не первом проекте.
- Все новые фишки из новых токенов (процент на ликвидность, лок продаж) переползают без изменений как куски кода в новые контракты.
- Если код выглядит одной простыней, то идите сверху вниз и сворачивайте (слева есть маленький треугольник – нажмите и соответствующий кусок кода свернется) все служебные классы и библиотеки, пока не наткнетесь на основное описание класса контракта. Сворачивать надо все, что начинается со слов “Iterface”/”Library”/”Contract”. Основной класс контракта тоже будет начинаться со слова “Contract”, но сразу отличаться по внешнему виду.
contract SnoopyInu is Context, IERC20, Ownable using SafeMath for uint256;
using Address for address;
mapping (address => uint256) private _rOwned;
mapping (address => uint256) private _tOwned;
mapping (address => mapping (address => uint256)) private _allowances;
mapping (address => bool) private _isExcluded;
address[] private _excluded;
uint256 private constant MAX =
uint256(0);
uint256 private constant _tTotal = 1000000000* 10**6 * 10**9;
uint256 private _rTotal = (MAX – (MAX % _tTotal));
uint256 private _tFeeTotal;
string private _name = ‘Snoopy Inu’;
string private _symbol = ‘SNPINU’;
uint8 private _decimals = 9;
constructor () _rOwned[_msgSender()] = _rTotal;
emit Transfer(address(0), _msgSender(), _tTotal);
>
Как узнать, какая транзакция вызывает состояние «Ожидание блокировки метаданных таблицы»?
Я пытаюсь выполнить DDL для таблицы, и SHOW PROCESSLIST выдает сообщение «Ожидание блокировки метаданных таблицы».