If you're writing unit tests, you're creating a program to verify that the target code, given a specific set of input, returns a known and expected output. To make unit tests for your reports, you need:
- A mock database that you run your test reports against.
- Sufficient mock data to generate reports.
- Known examples of the output said reports should generate when said mock data in mock database is sent.
Unless you're actually working on development of the Oracle software itself, you don't need to test things like "are dates actually dates" or "does each column have a header." You only need to match your mock input to your mock output, and expand your test suite until you cover all applications needed for usages in production.
OTOH, if you're actually going to test how the report returns items based on your live database, you're writing integration tests and possibly even production checks. (Are you tests going to run each time the report does, or just when a new version of code is pushed to production?)
In all cases, I'd only test that which is either important to the end-user ("is the sales column actually sales?") or otherwise part of your design specification ("UserCancellation Report includes only users marked for cancellation.").
Knowing precisely how many tests to write and what to write requires a lot of domain knowledge, not the least of which is how often these tests are ran and what your test framework is like. (You are using an automated test suite of some kind, either OSS or purchased from a vendor or even home-grown, right?)