...
Don't do it
It's best not to directly access the database in an IChannel. Re-architect so that your IChannel accesses service implementations which in turn are backed by DAOs. Including actual database connection and SQL query code in the IChannel class itself leads to long and complicated IChannel implementations. Adding some abstraction allows you to think of this in terms of what services your IChannel needs to consume and expose, and then elsewhere, in service implementations and DAOs, you can place the code that makes those services real.
What is your IChannel doing? Is it something that would be of interest to other uPortal deployers? If there's enough interest, potentially by factoring this such that there's a pluggable DAO layer, you can share this channel with others and their work in getting it deployable in their environment is to reconfigure or re-implement the DAOs to point at their data.
A layered architecture buys a lot, even in IChannels.
Getting at the Database
uPortal's IChannel API is very good at configurably provisioning IChannel instances with String configuration parameters, which can be specified at channel publish and/or subscribe time and are mediated by a declaratively configurable channel publishing workflow (CPDs). uPortal is much less elegant at injecting into channels the non-String resources they need.
...
CSqlQuery exemplifies the DataSource from RDBMServices approach.
When in the channel lifecycle to access the db
You can retrieve your data in setRuntimeData(), store it (in an instance variable in an IChannel, in some awful channel state map in an IMultithreadedChannel, and use the stored data in renderXML(). This moves the data retrieval to earlier in the channel rendering process while still keeping it after threads have been dispatched (so other channels won't be waiting on your database connection to return.)