Not just for disasters anymore

Later this summer, the computer system for the 311 dispatch center in Austin, Texas, will take on more work. As that happens, the city's information technology office wants to move some of the system's less-urgent duties off the primary database system.

One potential source of relief is the failover database system. The city is considering running reports using data in the failover system rather than the primary database system, said Wesley Jackson, manager of business applications at the city's communication and technology management office.

The idea of using the failover system or other backup databases for duties in addition to disaster recovery is not new. It's a feature users have been requesting for a while, said Juan Loaiza, senior vice president of database development at Oracle Corp. "In order to get protection from site failures, they have to set up an entire other data center ? this entire other computer system, this entire other database ? and feed it this information, but they'll never use it except in case of a disaster," he said. "Nobody wants to do that, because site disasters don't happen every day."

Yet, with recent replication and failover technologies improving, accessing and using that data is becoming easier. And organizations are finding uses for that data ? and those databases. "The data that resides on a failover database has some value," said Bill Cooper, vice president of data warehouse system provider Teradata, a division of NCR.

Like all cities and towns, Austin gets plenty of calls about things such as trash not being picked up, dogs on the loose and other nonemergencies. And like other cities, it must keep metrics on how these calls are handled ? everything from how long it takes to complete those calls to where they originate. "This is a very high-profile system, and we have to be able to provide reports about our call volumes," Jackson said.

Such reports are based on the service requests filled out by the call center operators. When a new call comes into the center, employees log the information, which the database then stores. When reports are required, they are easily generated by tapping into the database. The database servers, running instances of Oracle 9i databases, are located at the call center.

Shared load

This summer, the Austin 311 center will begin responding to nonemergency police calls that previously came in from the 911 call center. "We're about to have a major ramp-up of the number of calls that we take," Jackson said.

Traffic coming into the call center is expected to double or even triple. As a result, the city's IT department is rethinking the idea of running the reports from the primary database. With the increased traffic, the city can't afford to let the database be slowed by the generation of reports.

"We don't want to have a major incident where we have to pull reports for a 311 call center [and] at the same time have our service reps take in [a surge of] support calls," Jackson said. "We had this failover database at this other location, so we thought, 'Why not point to that failover database and run our reports from there?' "

Initially looking into this possibility, however, Jackson found that it could not be done, at least not without splitting the software that provides the replication services between the two databases. Now the city is looking into ways around the problem or, should those fail, other ways of generating reports ? perhaps by setting up a third database.

Austin is not alone in confronting these issues. Other organizations are eyeing their failover or backup databases for additional duties. Many organizations have already set up secondary databases. Some will just keep a backup copy of the data.

Others are kept in a failover status, meaning they can be used as a primary database in an emergency should the primary one fail. In fact, current software, such as that offered by SunGard or Oracle, allow systems to switch between the primary and backup databases so quickly that users don't notice the switch.

Loaiza said Oracle has made great strides in making failover or backup databases more readily available for additional purposes. This is not easy, given the trickiness of updating and reading databases.

In the most basic configuration, the primary database makes a log file of the changes, which then can be shipped to the secondary database and applied to make the two databases identical. Oracle has long offered this approach, which it calls Critical Standby. Users could query Oracle's Critical Standby database when it wasn't being updated with new material. However, both actions couldn't be done at the same time.

"So what people would do is switch back and forth," Loaiza said. "Maybe at day, they'd read the database, and at night, they'd apply the changes."

This proved to be unsatisfactory to some users, so about seven years ago, the company introduced something called the Logical Standby database, which allowed reads and writes at the same time.

"It's more flexible," Loaiza said. But the downside to Logical Standby, he said, was that it wasn't as fast because a lot more conversion of data was needed. It was also more complicated for administrators.

With the upcoming release of Oracle 11g, a new feature called Readable Physical with Real Time Queries will offer the best of both Logical Standby and Critical Standby, Loaiza said. Reading and writing can be done nearly simultaneously, and the database system can maintain the speed of the primary system.

The agility of new tools such as Readable Physical with Real Time Queries can give organizations a lot more flexibility. For example, organizations can bring down the primary system to apply patches and updates while running the failover system in its place. Then when the updates are finished, they can bring the secondary system down for its upgrades.

"Organizations like Amazon can't be down at all, so this is a technique that they use," said Ari Kaplan, president of the Independent Oracle Users Group.

In addition to patching, organizations could also reuse failover databases to take backup chores away from the primary database server, Kaplan said. When a system is being backed up, it can slow service by 10 percent to 40 percent. Backing up the failover server ? rather than the primary server ? removes any lag felt by users of the primary system.

The failover system could also be used for testing, Loaiza said. An organization may want to make a change in the production environment but worries that the changes will cause havoc. The change could be made to the failover server first and only applied to the production database if the change is successful.

Report cards

Increasingly, though, organizations are generating reports against these secondary databases.

In many cases, the data organizations' need to report exists only in the database in which it was created, Kaplan said. Yet such databases are optimized for transactions, so running reports against these databases slows the system for users. "Organizations are stuck in that mixed, dual-purpose environment," Kaplan said. "If you have everything in one environment, it hurts performance."

Because failover databases don't have the performance requirements that the primary ones do, they might offer quicker responses to queries by business intelligence software. "You can do the heavy reporting in one system and the updates on the original," Kaplan said.

One thing to keep in mind with this approach is that the reporting database is a little less current than the production database, Kaplan said. Unless the two database servers are fully synchronous ? meaning the two are updated at the same time ? the secondary server may not be as complete as the primary one. "That might be OK if you're doing a report about what happened last month," he said. In some cases, however, it may not be acceptable to have differing versions of the data.

Joab Jackson is chief technology editor for Government Computer News, an 1105 Government Information Group publication.