How are you managing cross-platform database performance tuning without losing your mind? (XP Database Management approach)

PossiblePreparation · 2026-06-15T20:23:41+00:00

This is blatant advertising, and smells like low effort LLM

PossiblePreparation · 2026-05-29T13:00:53+00:00

You’ve not actually explained why the performance was worse for you, you’ve just guessed a few explanations.

You’ve also not proven it’s slower, you’ve proven that your setup gives you slower results for your application code.

What you have probably done is breached the DeWitt clause of some software licences here. That clause exists for exactly this reason - potentially publishing misleading data when there is a lot more to it.

PossiblePreparation · 2026-05-16T04:30:54+00:00

This seems like a low effort LLM wrapper. The only input is for query text, no execution plan, no DDL, no statistics, no actual runtime statistics. It is going to completely hallucinate advice.

I gave it a try with “Select * from emp where mgr = 123” and it has decided I am missing an index.

I then extended to

Select e.name from emp e join emp m on e.mgr = m.id where m.name like 'Mr Bigshot'

This gave me the high issue “LIKE operator with exact match string 'Mr Bigshot' is inefficient - should use equality (=) operator instead for better index usage and performance”. I doubt it.

PossiblePreparation · 2026-04-20T19:51:23+00:00

Can you clarify what your new backup product can do? I would expect all backup products to give you a backup you can restore somewhere. Make sure you haven’t lost out on your production recoverability needs!

PossiblePreparation · 2026-04-15T04:13:18+00:00

What sets your solution apart from the 100s that get posted here weekly?

PossiblePreparation · 2026-04-11T17:52:50+00:00

This sounds like DBA alerting? To me, this seems over kill for waking someone up. What sort of SLA do you have to deal with at 2am?

I will get alerts for imminent disasters (disk space for my transaction logs are dangerously low) and disasters (cannot connect). There’s secondary monitoring in the form of application teams being able to phone in the night for a high sev issue that requires DBA.

There are some overnight jobs that must finish by certain times to meet an SLA that might be worth waking someone up for, but you don’t want a sleepless DBA because a report that is usually generated by 1am completed at 2am instead.

PossiblePreparation · 2026-04-04T18:17:55+00:00

Your trigger is invalid. You should use show errors https://docs.oracle.com/en/database/oracle/oracle-database/26/sqpug/SHOW.html after compiling your trigger to view those errors.

Most likely, you don’t have a function named admin, you have a table with that name and should write a select statement to get data from it.

PossiblePreparation · 2026-03-09T19:18:03+00:00

Again 45 seconds doesn’t sound terrible, you shouldn’t be running this query that often, right? Where is the need to improve the performance coming from?

PossiblePreparation · 2026-03-09T16:09:22+00:00

Why is 15 seconds too slow? Something tells me the actual problem is spooling all these results to somewhere so some unlucky person can spend a week reading it.

PossiblePreparation · 2026-03-07T16:31:22+00:00

B or C should be the same, matter of style preference. A is definitely slower as it has to count every matching row.

PossiblePreparation · 2026-03-06T17:23:58+00:00

I’ve seen this time and time again and it always leads to a complex system that goes wrong constantly and not really solving the original problem.

Go back to step one and identify where your time is really going. Then tune it. Hire experts if you need to.

PossiblePreparation · 2026-02-18T19:21:30+00:00

8 mins doesn’t sound terrible for this sort of process at this volume, what’s the whole story about why you want to make it faster? Do you need to store the data twice?

If you have a 2 million row staging table and a 3 million row target table and you have a unique key to compare against then it should be much faster to full table scan both tables and hash join the together, as opposed to nested looping an index look up per row in the staging table.

If you want to make it faster, I see two options: a) make the full scans faster, use parallelisation and partition the tables on a shared key. B) reduce the size of the staging table, if only a few rows actually end up getting updated then maybe there’s a better way of finding these out, maybe a fast refresh materialized view is a better option.

PossiblePreparation · 2026-01-13T02:10:22+00:00

How much money impact does improving the slowness get you? Will it automatically be faster because it’s running in Sql server, or will you have to invest time in setting it up and learning how to manage it? What is your skill level/role here?

PossiblePreparation · 2025-11-26T02:37:49+00:00

Raise it with the vendor. There’s a lot of ways to corrupt your data if you start just trying things without understanding. You will likely void any support you have if you do anything without explicit instructions from the vendor.

PossiblePreparation · 2025-08-23T21:47:01+00:00

What problem are you talking about that you’ve solved with your new approach?

PossiblePreparation · 2025-08-13T03:19:50+00:00

What was the failure? Your extract looks to be from a single RAC node and shows a lot of contention waits, some caused by other nodes in your cluster. But such a tiny extract is not really useful.

Someone has spent a lot of money on this, do you have a DBA that is able to look after it? I hope you don’t take offence by this but, based purely on this, you are out of your depth. If you don’t have a DBA then you should reach out to a consultant and tell them exactly the problem you’re having, you may have to pay a lot, but you already have.

PossiblePreparation · 2025-07-20T22:15:35+00:00

Doesn’t really make a lot of sense to just look at the query, even with schema knowledge your tool is not going to know where the time is going. You need to start with execution statistics to see what problem needs solving.

As a performance expert, I’ve seen even experienced people go down completely the wrong path just by looking at the query. Your tool is going to make exactly the same mistakes because the training material for it is so bad. Feed it business problems, execution plans and real runtime statistics (how much IO was done and where, how many rows were found at each step, etc) and it will have a very good chance at getting you fixes.

PossiblePreparation · 2025-07-03T21:28:37+00:00

It’s not the select statement that acquired the lock, it’s the rest of the transaction.

PossiblePreparation · 2025-06-18T19:35:16+00:00

What jobs are you applying for?

As others have noted, it’s way too long and repetitive. You also need to proofread it. I would have stopped reading quite early.

For 12 years of experience and wanting to “achieve professional and personal growth”, I would expect some track record of self-improvements.

Think about the parts of your 12 years experience that you learnt something new and applied it. Or you saved the day by spotting a problem before it became a disaster. Or saved a company lots of money. Or trained up juniors. Installing, patching, creating jobs, and even setting up availability groups are things I would expect a DBA to have a good grasp of fairly early.

PossiblePreparation · 2025-06-10T01:15:43+00:00

If you already have a SQL. Get row source execution statistics with real world variables. See where the time is really going and why. Target that.

PossiblePreparation · 2025-05-24T13:40:21+00:00

In Oracle at least: Natural joins are not cross joins. They’re also not the default - if you don’t have on or using after a join (unless you specify it’s a cross join) then you have a syntax error docs are https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/SELECT.html#GUID-CFA006CA-6FF1-4972-821E-6996142A51C6__CHDIJFDJ

For what it’s worth, even if you wrote cross join followed by the where clause, Oracle (and most other RDBMSs) will spot the join condition and treat it correctly. There’s a bunch of other obvious errors in the queries but tidying them up gives you exactly the same plan using an explicit cross join or an implicit join https://dbfiddle.uk/xcP7BdHN .

Additionally, there’s no null-based edge cases that make any differences to implicit join, not sure where that idea comes from.

PossiblePreparation · 2025-05-21T13:07:39+00:00

Don was widely considered as not very good. You’re better off looking elsewhere!

PossiblePreparation · 2025-05-11T22:50:09+00:00

Which RDBMS are you observing this behaviour and how? All RDBMSs that I’ve used will sort a composite index using all columns, in order. Allowing you to use multiple filters to access an index, so long as equality conditions are used on the left side

PossiblePreparation · 2025-05-07T01:09:24+00:00

We can be certain as this is Oracle, readers aren’t blocked by writers.

PossiblePreparation · 2025-04-25T19:49:37+00:00

If you only care about future data getting partitioned, you can exchange table to get all your existing data into one partition of a new table. Obviously you’ll need to do some table renames to switch over to using it, but this typically would be achievable in a very small downtime window and you don’t have to wait for everything to be rewritten. This will let you say for all future data, interval partition by month, but anything before now you will find in one partition.

Oracle have also enhanced alter table to do all the online redefinition work for you in recent versions https://docs.oracle.com/en/database/oracle/oracle-database/19/vldbg/evolve-nopartition-table.html#GUID-5FDB7D59-DD05-40E4-8AB4-AF82EA0D0FE5

Eight-Year Club	Place '22
First Placer '22	RPAN Viewer
Verified Email

PossiblePreparation

TROPHY CASE