đŸ”„ The DB Grill đŸ”„

Where database blog posts get flame-broiled to perfection

Why doesn't Oracle Multi-Value Index optimize .sort() like MongoDB does with its multi-key index? RecordId deduplication.
Originally from dev.to/feed/franckpachot
August 15, 2025 ‱ Roasted by Alex "Downtime" Rodriguez Read Original Article

Well now, this is just a fantastic read. A real love letter to those of us in the trenches. I have to commend the author for this wonderfully detailed exploration of Oracle's new MongoDB emulation. It’s always reassuring when a decades-old relational database decides to become a "document store." It’s like watching your grandpa put on a backwards baseball cap to connect with the youth. You’re not fooling anyone, but we appreciate the effort.

I’m especially fond of the setup process. A simple docker run, followed by a charming little until grep ... do sleep 1 loop. It’s that kind of elegant, hands-on approach that you just don't get with those other databases that... you know, just start. This little shell script ritual is a great way to build character before you even get to sqlplus. It reminds you that you're about to work with a serious piece of enterprise engineering.

And the syntax for the new Multi-Value Index? A masterpiece of clarity.

CREATE MULTIVALUE INDEX FRANCK_MVI ON FRANCK ( JSON_MKMVI( JSON_TABLE( ... NESTED PATH ... ORA_RAWCOMPARE ... )))

It just rolls off the tongue. I can’t wait to explain this to a junior engineer during a production incident. It’s practically self-documenting. Why would you ever want a simple createIndex({ field1: 1, field2: 2 }) when you can have this beautiful, multi-line testament to the power of the SQL standard, with a few proprietary functions sprinkled in for flavor? It’s job security, really.

But my favorite part, the part that truly speaks to me as an Ops lead, is the section on troubleshooting. The author claims it’s "easy to dump what’s inside." And they are absolutely right. Instead of being burdened with some high-level, intuitive dashboard, we're given the privilege of a real, old-school treasure hunt.

This is what true observability looks like, people. Forget Grafana. Forget Prometheus. Just give me a 50-gigabyte trace file filled with buffer cache dumps. That’s where the truth is. I’m already picturing it now: 3:00 AM on the Saturday of a long weekend, the application is down, and I'll be there, calmly grep-ing through hex codes, feeling like a real detective.

The execution plan comparison is also incredibly insightful. It shows how Oracle's emulation layer artfully translates a simple MongoDB index scan into a much more robust, multi-stage process involving an INDEX RANGE SCAN, a HASH UNIQUE, a TABLE ACCESS, and a SORT ORDER BY. Why do one thing when you can do four? It’s about being thorough. That extra SORT operation is just the database taking a moment to catch its breath before it gives you the data. It’s not a performance bottleneck; it's a feature.

And the conclusion that this is all built by combining "function-based indexes, virtual columns... and hints originally created for XML" is just the chef's kiss. It's so inspiring to see this kind of resourceful recycling. It reminds me of my sticker collection—I've got a spot for this "Oracle 23ai MVI" right next to my stickers for Ingres, RethinkDB, and that "Oracle XML DB" one from 2003. They’re all part of the great circle of life.

I'm genuinely excited to see this roll out. I predict a future of unparalleled stability. The application team will push a seemingly innocent change, maybe adding a new value to one of those JSON arrays. The query planner, in its infinite wisdom, will decide that the HASH UNIQUE operation now needs just a little more memory. Say, all of it. The ensuing outage will be a fantastic team-building opportunity, a chance for all of us to gather around a massive trace file dump, pointing at hex codes and sharing stories of databases past. It will be a glorious failure, and I, for one, can't wait to be there for it. Pager on silent, of course.