A database test plan can cover different things depending on the scenario. A full database migration would require a wide ranging test. A change to a single application could require a detailed analysis of data in a few tables.
A new database, or a large change to an old one, usually requires a performance test. At the simplest level, this could involve running some of your largest transactions or reports. A larger database with a greater change could involve using automated testing tools to challenge the system with a quantity of complex data.
After a migration or application changes, it is important to note whether the application can function. Run through a set of transactions designed to work out the areas where changes occurred.
Build queries to test data integrity. Run transactions against the database, then use the queries to check the data is being created, deleted and updated correctly. While performance and the ability to work in a system are important, it is data integrity problems that can lie hidden for months which cause the most anguish in the end.
Test connections from the other systems that access the database. Make sure the database accounts they use are functional. Some simple queries or transactions from these remote systems will suffice.
With any test plan, the most important part is that it exists. Decide ahead of time what is to be measured and how it is to be measured. Changes can always be made and additional tests can be performed.