In a previous post, I explained how you can collect and plot metrics using MySQL Shell.

This is a new series of article where I will explain how to read and understand some of the generated graphs.

Understanding your workload and seeing the evolution of it over time can help anticipating problems and work on solutions before the breakdown.

Let’s start the series with a concept that is not always well understood or at least not always considered at its true value: MySQL Checkpoint Age.

example of checkpoint age graphInnoDB Checkpointing

Before analyzing the graph, we need to understand what is MySQL InnoDB Checkpointing.

Each change to a data page in the InnoDB Buffer Pool are also written into the Write Ahead Logs.

In the literature they are sometimes called Transaction …

This post is the twelfth one of a series of articles on extending MySQL with the Component Infrastructure:

• Extending MySQL using the Component Infrastructure – part 1
• Extending MySQL using the Component Infrastructure – part 2: building the server
• Extending MySQL using the Component Infrastructure – part 3: component services
• Extending MySQL using the …

This post is the second of a series of articles dedicated to MySQL Database Service (MDS):

• Using MySQL Database Service in OCI – Part 1: creating a MySQL DB System
• Using MySQL Database Service in OCI – Part 2: importing Data to MySQL DB System
• Using MySQL Database Service in OCI – Part 3: faster with MySQL HeatWave !

The goal of this series if to get familiar with MDS, HeatWave and useful MySQL Shell utilities.

Before we start, I would like to highlight that the fastest and recommended way to import data to a MySQL DB System in OCI is to use a parallel dump created using MySQL to Object Storage and load it …

This post is the first of a series of articles dedicated to MySQL Database Service (MDS):

• Using MySQL Database Service in OCI – Part 1: creating a MySQL DB System
• Using MySQL Database Service in OCI – Part 2: importing Data to MySQL DB System
• Using MySQL Database Service in OCI – Part 3: faster with MySQL HeatWave !

The goal of this series if to get familiar with MDS, HeatWave and useful MySQL Shell utilities.

In this first article we will start by creating a MySQL DB System and a Compute instance in OCI. One of the goal is also to see the benefits of HeatWave, so we will start by creating this …

Recently, I saw many interest in understanding and getting information about database locking.

MySQL InnoDB’s locking can be complex and having an overview not always simple.

For more information about how InnoDB locking is working, I can only recommend this excellent series of articles by Kuba:

• https://dev.mysql.com/blog-archive/innodb-data-locking-part-1-introduction/
• https://dev.mysql.com/blog-archive/innodb-data-locking-part-2-locks/
• https://dev.mysql.com/blog-archive/innodb-data-locking-part-2-5-locks-deeper-dive/
• …

Last Tuesday, it was the very first session of DB AMA, Morgan Tocker made a nice presentation of MySQL Performance_Schema and illustrated it with some nice queries to get Meta et Data Locks.

As those queries were not that simple to write or at least to remember, I thought it might be a good idea to add them to MySQL Shell, the best MySQL DBA Tool !

I’ve then added a new method to the check plugin: getLocks().

Let’t see it in action:

As you can see, this is a small extension that can offers you a better view of what’s locked per transaction.

You can find several MySQL Shell Extension directly on github: …

Today, we will cover a totally different MySQL Shell plugin: InnoDB.

Currently only 3 methods have been created:

Those related to the Table space fragmentation, have already been covered in this recent article.

Let’s discover the getAlterProgress()method. This method allows us to have an overview of the progress of some alter statements status like:

• stage/innodb/alter table (end)
• stage/innodb/alter table (flush)
• stage/innodb/alter table (insert)
• stage/innodb/alter table (log apply index)
• stage/innodb/alter table (log apply table)
• stage/innodb/alter table (merge sort)
• stage/innodb/alter table (read PK and internal sort)
• stage/innodb/alter tablespace (encryption)

This is an output of the method:

As …

In the first part of this article related to the check plugin, we discovered information retrieved from the binary logs. This part, is about what Performance_Schema and SYS can provide us about the queries hitting the MySQL database.

Currently, 3 methods are available:

• getSlowerQuery()
• getQueryTempDisk()
• getFullTableScanQuery()

The method’s name should be self explaining.

This is an overview of the parameters for each methods:

ext.check.getSlowQuery()ext.check.getQueryTempDisk()ext.check.getFullTableScanQuery()

Some methods allow a select parameter if only SELECT statements should be returned.

When only one query is returned (default), it’s also possible to …

To illustrate how easy it’s to see who’s trying to access data they have not been granted for, we will first create a schema with two tables:

mysql> create database mydata;
mysql> use mydata
mysql> create table table1 (id int auto_increment primary key, 
              name varchar(20), something varchar(20));
mysql> create table table2 (id int auto_increment primary key, 
              name varchar(20), something varchar(20));

Now, let’s create a user :

mysql> create user myuser identified by 'mypassword';

And as it’s always good to talk about SQL ROLES, let’s define 3 roles for our user:

• myrole1: user has access to both tables in their entirety, reads and writes
• myrole2: user has access only to `table2`, reads and writes
• myrole3: user has only access to the column `name`of `table1` and …

Answering this question is not easy. Like always, the best response is “it depends” !

But let’s try to give you all the necessary info the provide the most accurate answer. Also, may be fixing one single query is not enough and looking for that specific statement will lead in finding multiple problematic statements.

The most consuming one

The first candidate to be fixed is the query that consumes most of the execution time (latency). To identify it, we will use the sys schema and join it with events_statements_summary_by_digest from performance_schemato retrieve a real example of the query (see this post for more details).

Let’s take a look at what sys schema has to offer us related to our mission:

> show tables like …