Understand transactions.
Read an explain plan and understand basic indexing.
Test recovery of your server and implement a standby/ failover.
Understand the pros and cons of where to put the logic of the application (db objects, stored proc, backend services, ui etc).
Understand the pros and cons of using an orm and how you might tune or scale an app using one.
Reading the Oracle or postgres documentation gives a lot of information about the internals, tuning, acid etc although it can be a bit dry...
Many developers don't get the concept of deploying a patch. They envision a script for each DB object stored in source control. Mimicking the the Java class files for all their objects. That's fine for code which can be re-built from scratch. But you can't re-build your DB, it must be patched to preserve the precious data.
It works fine for DB release #1. But when DB release #2 comes around there's no way to deploy the DB changes. Special diff tools are brought in to generate the patch. The auto generated patch drops a column.. ooops.
Know that most databases can spit out a "worst performing queries" and "overall most expensive" reports. The method varies per engine. Always illuminating, and usually not the queries you were expecting.
Know how to turn logging on/off and where the logs go.
Know there are a bunch of system tables that keep data about all your tables in it in most engines, information_schema tables. Rows, size, columns, etc. These are actually defined in the SQL spec, but various SQL vendors have even more available, e.g. there's a load of extra stored procedures in SQL Server.
Be able to generate and read a query plan report for your engine, which will tell you what's causing a slow query.
