Tales From A Lazy Fat DBA

Its all about Databases, their performance, troubleshooting & much more …. ¯\_(ツ)_/¯

Archive for August, 2025

Early Access, Cool Swag, and the Best Community Ever – The Oracle ACE Story

Posted by FatDBA on August 11, 2025

I was inducted into the Oracle ACE Program back in 2021, and honestly, it has been one of the most rewarding chapters of my career. Over the years, I’ve had the chance to connect directly with Oracle teams, work with passionate community members, and be part of projects that pushed me to learn, share, and grow.

Last year at Vegas, Oracle CloudWorld 2024, I met so many of these like-minded Oracle professionals in person. It was incredible. The hallway conversations, the deep-dive technical sessions, the after-hours chats over coffee — those are moments you simply can’t replicate online. The energy of being surrounded by people who live and breathe Oracle technology was something else entirely.

Sadly, I’ll be missing Oracle CloudWorld this year because of other travel commitments 😦 It’s a bit of a heartbreaker, but it also makes me appreciate just how special these opportunities are when you do get them.

That said, my journey as an Oracle ACE has been about far more than conferences. From early access to technology, to direct collaboration with Oracle’s product teams, to the friendships formed with other ACEs — the benefits go well beyond the badge on my LinkedIn profile … I also have to give a huge shout-out to the Oracle ACE Program team – Jen Nicholson, Oana Bonu, and Cassandra Call — for the constant encouragement, guidance, and for keeping the ACE community so well-connected and engaged. Their support plays a massive role in making the program such a great experience.


So, you have probably seen someone proudly showing off that little red Oracle ACE badge on their LinkedIn profile.
It looks cool, but what does it actually mean? Is it just a bragging sticker or is there something real behind it?

It turns out it is a whole lot more than a badge.
It feels like joining an invite-only club where the currency is knowledge, the meetings happen in Slack channels, and the secret handshake is swapping tuning tips over coffee at a conference.

One of my favorite perks is the Beta Program eligibility. This is where you get to play with Oracle’s new features before the rest of the world even knows they exist. Imagine Oracle telling you, “Here is a new 23ai feature, go ahead and test it, break it, tell us what you think.” You run your tests, push it to the limit, maybe even crash it completely in your lab and then send feedback straight to the people building it. It is like being a database taste tester. Sometimes it is exciting, sometimes it is messy, and sometimes you discover something so odd you are half-expecting them to name the bug after you.

Then there are the five thousand dollars in Oracle Cloud credits. This is one of the most underrated perks. You basically get your own sandbox to build whatever you want. It could be Autonomous Databases, test clusters, proof-of-concepts, machine learning experiments, or even a fully populated database of every coffee type known to humankind just to test JSON search performance. You can go wild without worrying about the cost or your manager asking why the cloud bill suddenly tripled.

And of course, Oracle CloudWorld. As an ACE, you can get passes to attend. This is where it feels like Disneyland for Oracle professionals. You get hands-on labs, deep dives into technology you have never even heard of, and those hallway conversations that somehow end up teaching you more than any formal session. You meet engineers who wrote the features you use every day, swap ideas with other ACEs, and sometimes find yourself in late-night debates about why people still write SELECT * in production code.

Another important benefit is the direct connection to Oracle Product Management. It does not mean they will fix your SR in two minutes, but it does mean you can talk directly to the people who design and own the products. Got a question about hybrid partitioned tables or JSON indexing or Vector Search/Indexing or …. ? You can skip the long escalation chain and ask the folks who built it. It is like having a hotline for database issues, except your contact is probably in a polo shirt and speaks PL/SQL.

There is also the social media boost. If you are blogging, making YouTube tutorials, or speaking at events, Oracle helps amplify your work. They will share your content, feature it in newsletters, and suddenly your small weekend blog post is getting attention from DBAs all over the world. You wake up to dozens of comments and connection requests from people who just read your take on optimizer statistics.

Now, I would be lying if I did not mention the swag. Hoodies, jackets, mugs, backpacks. And not the cheap conference giveaway kind. This is the sort of gear that makes colleagues raise an eyebrow and ask, “Where did you get that?” The ACE hoodie is an instant conversation starter at events. I have met people simply because they spotted it from across the room and came over to talk.

If you speak at conferences, there is also travel support. This can be a game changer, especially for events far from home. If you have ever wanted to present to a large audience but travel costs made you think twice, this can tip the balance and make it possible.

The biggest thing for me though is the community. You are surrounded by people who love this stuff as much as you do. People who understand why you are excited about a new optimizer hint. People who send you screenshots of strange execution plans just for fun. People who will happily spend part of their evening helping you troubleshoot a tricky replication setup because they have been there before. It is not just networking. It is friendship, mentorship, and constant learning all rolled into one.

Being an Oracle ACE comes with many perks such as early access to features, cloud credits, event passes, direct connections to product management, social media amplification, great swag, and travel support. The real magic is in the access, the learning, and the people you meet along the way.

If you enjoy sharing your knowledge, writing, presenting, or helping other Oracle users, keep doing it. One day that email saying “Congratulations, you are an Oracle ACE” might land in your inbox. That is when the real adventure starts.

Hope It Helped!
Prashant Dixit
Database Architect @RENAPS
Reach us at : https://renaps.com/

Posted in Uncategorized | Tagged: , , , | Leave a Comment »

MySQL OPTIMIZE TABLE – Disk Space Reclaim Defragmentation and Common Myths

Posted by FatDBA on August 8, 2025

When working with MySQL databases, one common task is reclaiming disk space and defragmenting tables. The typical solution that most of us have turned to is OPTIMIZE TABLE. While this sounds like a simple, quick fix, there are a few myths and things we often overlook that can lead to confusion. Let’s break it down.

The Basics: OPTIMIZE TABLE and ALTER TABLE

To reclaim space or defragment a table in MySQL, the go-to commands are usually:

  • OPTIMIZE TABLE <table_name>; or OPTIMIZE TABLE [table_name_1], [table_name_2] or via sudo mysqlcheck -o [schema] [table] -u [username] -p [password]

But before we dive into the myths, let’s clarify what happens when you run these commands.

OPTIMIZE TABLE Overview

  • OPTIMIZE TABLE is essentially a shorthand for ALTER TABLE <table_name> ENGINE=InnoDB for InnoDB tables. It works by rebuilding the table, compacting data, and reclaiming unused space.
  • In MySQL 5.6.17 and later, the command works online, meaning it allows concurrent reads and writes during the rebuild, with some exceptions (brief locking during initial and final stages). Prior to 5.6.17, the table was locked for the entire duration of the operation, causing application downtime.

Myth #1: OPTIMIZE TABLE Is Always Quick

  • No: OPTIMIZE TABLE can indeed take a long time for large tables, especially if there are a lot of inserts, deletes, or updates. This is true when rebuilding the table. For larger datasets, the I/O load can be significant.
mysql> OPTIMIZE TABLE my_large_table;
+----------------------------+--------+----------+----------+----------+
| Table                      | Op     | Msg_type | Msg_text |
+----------------------------+--------+----------+----------+----------+
| mydb.my_large_table         | optimize | ok       | Table optimized |
+----------------------------+--------+----------+----------+----------+

In the output, the values under each column heading would show:

  • Table: The table that was optimized (e.g., yourdb.customers).
  • Op: The operation performed (optimize).
  • Msg_type: Type of message, usually status.
  • Msg_text: The result of the operation, such as OK or a specific message (e.g., “Table is already up to date”).

If the table is already optimized or doesn’t require optimization, the output might look like this:

+------------------+----------+----------+-----------------------------+
| Table            | Op       | Msg_type | Msg_text                    |
+------------------+----------+----------+-----------------------------+
| yourdb.customers | optimize | note     | Table is already up to date |
+------------------+----------+----------+-----------------------------+

Below screenshot explains possible values of msg_text etc.

Real-Time Example Validation:

  • MySQL logs can show something like this: [Note] InnoDB: Starting online optimize table my_large_table [Note] InnoDB: Table optimized successfully

However, for larger tables, it is critical to consider the additional I/O load during the rebuild. For example:
bash [Note] InnoDB: Rebuilding index my_large_table_idx [Note] InnoDB: Table rebuild completed in 300 seconds

Note: In order to get more detailed information its good to verify PROCESSLIST or SLOW QUERY LOG (if enabled).

Myth #2: OPTIMIZE TABLE Doesn’t Block Other Operations

  • Yes/No: This myth is partly true and partly false depending on the MySQL version.
  • For MySQL 5.5 and earlier: The table is locked for writes, but concurrent reads are allowed.
  • For MySQL 5.6.16 and earlier: Same as above .. concurrent reads are allowed, but writes are blocked.
  • For MySQL 5.6.17 and later: Concurrent reads and writes are allowed during the rebuild process, but the table still needs to be briefly locked during the initial and final phases. There is a brief lock required to start the process, which is often overlooked.

Real-Time Example for MySQL 5.6.17+:

[Note] InnoDB: Starting online optimize table my_large_table
[Note] InnoDB: Table optimized successfully

Although reads and writes are allowed during this process, you might still experience short bursts of lock at the start and end of the operation.

Myth #3: You Don’t Need to Worry About Disk Space

  • No: You need sufficient disk space before running OPTIMIZE TABLE. If you’re running low on space, you could encounter errors or performance issues during the rebuild process.
  • There are few bugs as well which might could occur if disk space is insufficient. Additionally, there’s also temporary disk space required during the rebuild process. Running OPTIMIZE TABLE with insufficient space could fail silently, leading to issues down the line.

Best Practice:
Ensure that your disk has at least as much free space as the table you’re optimizing, as a copy of the table is created temporarily during the rebuild.

Myth #4: ALTER TABLE with Row Format Is Always the Solution

  • No: ALTER TABLE ... ROW_FORMAT=COMPRESSED or other formats can help optimize space, but it may not always result in savings, especially for certain data types (like BLOBs or large text fields). It can also introduce overhead on the CPU if you’re using compression.

In some cases, switching to a compressed format can actually increase the size of the table, depending on the type of data stored.

Real-Time Example:

  • For a table like customer_data: ALTER TABLE customer_data ROW_FORMAT=COMPRESSED; Depending on the types of columns and data (e.g., BLOBs or TEXT), compression might not always yield the expected results.

Myth #5: You Only Need to Optimize Tables When They Get Slow

  • No: This is another common misconception. Regular optimization is crucial to ensure long-term performance, especially for heavily modified tables. Tables that undergo a lot of updates or deletions can become fragmented over time, even without obvious performance degradation.

Optimizing periodically can help prevent gradual performance loss.

Real-Time Example:

  • If you have an orders table: mysql> OPTIMIZE TABLE orders; Over time, especially with frequent UPDATE or DELETE operations, fragmentation can slow down access, even if it’s not immediately noticeable.

Main Pointerss ..

  • OPTIMIZE TABLE is a helpful tool but not a one-size-fits-all solution.
  • It requires sufficient disk space and careful consideration of your MySQL version and storage engine (InnoDB vs. MyISAM).
  • In MySQL 5.6.17 and later, online optimizations are possible, but brief locking still occurs during the process.
  • For MyISAM tables, there’s no escaping the full lock during optimization.
  • Always assess the potential overhead (I/O and CPU usage) before running the operation, especially on larger datasets.

By breaking these myths, you can make better decisions when using OPTIMIZE TABLE to keep your database healthy without causing unnecessary downtime or performance hits.

Hope It Helped!
Prashant Dixit
Database Architect @RENAPS
Reach us at : https://renaps.com/

Posted in Uncategorized | Tagged: , , , , , | Leave a Comment »