New answers tagged

1

You could also fire this off in a few concurrent sessions. Only one session will be able to get the exclusive lock at any one time. BEGIN TRANSACTION; EXEC sp_getapplock @Resource = 'FooBar', @LockMode = 'Exclusive'; WAITFOR DELAY '00:00:30'; EXEC sp_releaseapplock @Resource = 'FooBar'; COMMIT TRANSACTION;


2

BEGIN TRANSACTION SELECT * FROM YourTable WITH (TABLOCKX, HOLDLOCK) WAITFOR DELAY '00:05:00' -- 5 minutes ROLLBACK TRANSACTION And then in another Query Window: SELECT * FROM YourTable


3

This is pretty easy to do. Open two query windows in Management Studio. Run something like this in the first one (choose a test table that nobody is using, because this will block them, and make sure it has at least one row in it): BEGIN TRANSACTION SELECT * FROM sometesttable WITH (TABLOCK, XLOCK, HOLDLOCK) Then in the second query window: SELECT * ...


4

The only way to find out what process caused the autogrowth is to use Extended events esp. EVENT --> sqlserver.database_file_size_change & sqlserver.databases_log_file_size_changed and ACTION --> sqlserver.sql_text. Looks like @DBA_ANDY already did the hard work of writing an XEvent -- Original Author : @DBA_ANDY http://nebraskasql.blogspot.com/2016/06/...


0

Depending on the Operating System, you might see 1 process for mysqld, or you might see 1 per connection. Each initially connected on port 3306. If you have connection pooling (in the client) and/or a high value of thread_cache_size and a high value of wait_timeout, there may be a bunch of idle connections that "don't go away". As Rolando says, "nothing ...


0

Once someone executes INSERT DELAYED, a system thread will open in order to track and mitigate INSERTs of this kind. MySQL 5.6 deprecates it and 5.7 does not support it. What is more, in terms of MySQL Replication, Slaves will completely ignore an INSERT DELAYED command from a Master and execute them as a standard INSERT. Please read the MySQL 5.5 ...


0

All those processes you are seeing in the OS are all kernel threads emanating from mysqld. Look carefully at the first picture Linux Process ID 26101 is mysqld_safe Linux Process ID 26307 is thread mysqld_safe launches mysqld Linux Process ID 26308 is actually mysqld 19 Linux Process IDs 26309 - 26334 are threads coming from mysqld (26308) My guess is ...


0

They're not all using the same port. The main mysqld process will have forked its children off (you can see the child<>parent relationship in the 2nd and 3rd columns of the ps output - pid 26308 looks to be the master "thread". Only one of the processes will actually be listening on the TCP port. You can verify this using lsof. I'll add that a forked ...


0

What we see is impossible, so the logical assumption is that it's an illusion. Multiple MySQL server instances can't listen on the same port. They also can't share the same pid file, as these do, nor can the data files for InnoDB be shared. The most sensible explanation for this is that the tools are showing you threads, not processes -- for whatever ...



Top 50 recent answers are included