The database capability for billing/accounting is not new to version 2.2. What has changed is the way it is managed. In particular, there is now an abstraction layer (DataNucleus) above the actual database (Postgres) which makes the passage from Java to SQL cleaner and less implementation-dependent. Moreover, updates to the database are handled by a change-management library (Liquibase). The latter is responsible for building the database schema referred to above.

Because it is possible that the newer version may be deployed over an existing 1.9+ installation which already uses the billing database, the Liquibase change-set has been written in such a way as to look for existing tables and to modify them only as necessary (version 2.2 adds several indices, functions and triggers, as well as a set of aggregate tables, in order to optimize the creation of histogram plots).

If you start the domain containing the billing service over a pre-existing installation of the billing database, depending on what was already there, you may observe some messages like the following in the domain log having to do with the logic governing table initialization.

INFO 8/23/12 10:35 AM:liquibase: Successfully acquired change log lock
INFO 8/23/12 10:35 AM:liquibase: Reading from databasechangelog
INFO 8/23/12 10:35 AM:liquibase: Reading from databasechangelog
INFO 8/23/12 10:35 AM:liquibase: Successfully released change log lock
INFO 8/23/12 10:35 AM:liquibase: Successfully released change log lock
INFO 8/23/12 10:35 AM:liquibase: Successfully acquired change log lock
INFO 8/23/12 10:35 AM:liquibase: Reading from databasechangelog
INFO 8/23/12 10:35 AM:liquibase: Reading from databasechangelog
INFO 8/23/12 10:35 AM:liquibase: ChangeSet org/dcache/services/billing/
   db/sql/billing.changelog-1.9.13.xml::4.1.7::arossi ran successfully in 264ms
INFO 8/23/12 10:35 AM:liquibase: Marking ChangeSet: org/dcache/services/
   billing/db/sql/billing.changelog-1.9.13.xml::4.1.8::arossi::(Checksum:
   3:faff07731c4ac867864824ca31e8ae81) ran despite precondition failure due
   to onFail='MARK_RAN': classpath:org/dcache/services/billing/db/sql/
   billing.changelog-master.xml : SQL Precondition failed. Expected '0' got '1'
INFO 8/23/12 10:35 AM:liquibase: ChangeSet org/dcache/services/billing/db/sql/
   billing.changelog-1.9.13.xml::4.1.9::arossi ran successfully in 14ms
INFO 8/23/12 10:35 AM:liquibase: Successfully released change log lock
INFO 8/23/12 10:35 AM:liquibase: Successfully released change log lock

Anything logged at a level lower than ERROR is usually entirely normal. Liquibase regularly reports when the preconditions determining whether it needs to do something are not met. All this means is that the update step was not necessary and it will be skipped in the future.

If, on the other hand, there is an ERROR logged by Liquibase, it is possible there may be some other conflict resulting from the upgrade (this should be rare). Such an error will block the domain from starting. One remedy which often works in this case is to do a clean re-initialization by dropping the Liquibase tables from the database:

[root] # psql -U srmdcache billing

billing=> drop table databasechangelog
billing=> drop table databasechangeloglock
billing-> \q
[root] #

and then restarting the domain.

[root] # psql -U srmdcache billing
billing=> \dt
                     List of relations
 Schema	|         Name          | Type  |   Owner
 -------+-----------------------+-------+-----------
 public	| billinginfo           | table | srmdcache
 public	| billinginfo_rd_daily  | table | srmdcache
 public	| billinginfo_tm_daily  | table | srmdcache
 public	| billinginfo_wr_daily  | table | srmdcache
 public	| databasechangelog     | table | srmdcache
 public	| databasechangeloglock | table | srmdcache
 public	| doorinfo              | table | srmdcache
 public	| hitinfo              	| table | srmdcache
 public	| hitinfo_daily         | table | srmdcache
 public	| storageinfo           | table | srmdcache
 public	| storageinfo_rd_daily  | table | srmdcache
 public	| storageinfo_wr_daily 	| table | srmdcache

billing-> \q
[root] #