"The best method" is probably a really vague concept.
I disagree completely. The "best" method varies widely, because it is specific to the RDBMS you're using.
OP says he understands how databases work, but it seems to be limited to how to put data in & get data out. A database is (or can be) more than a bit bucket. If it's taking too long to fetch records from a 10 million record table, there are some serious performance issues here. It could be any combination of bad data modeling, improper indexing, underpowered hardware, poorly configured concurrency/consistency controls, inefficient I/O subsystem, OLTP workload on a system configured for OLAP etc...
Understanding concepts like transactions, locking mechanisms, disaster recovery, table structure (heap vs clustered), index structure, temp tables, stored procedures/packages/functions, data types, etc. is important, but it's equally important to understand how your chosen RDBMS implements these so that you can fully exploit them. Armed with this knowledge and the needs of your business, you'll be able to refactor your data and/or applications appropriately
I think you can get at the concepts through practice - particularly since you're working with more than 1 RDBMS, but "getting" databases in general won't get you what you're looking for. Depending on the urgency here, you may find yourself hiring a gun to help sort out your situation, as the amount of research & testing required to get the knowledge you need to do this may not be practicable for an IT Director.
I hope this helps!