Founded in 1826, Die Mobiliar is the oldest insurance firm in Switzerland. From its headquarters in Berne, the national capital, the company’s network of 160 offices and more than 4,000 employees provides home, car, accident, and risk management insurance and other financial services to more than 1.6 million individuals and businesses throughout the Alpine country’s 26 cantons. In late 2014, Mobiliar found itself with a database inventory not uncommon to firms with long histories and technology acquired via mergers and acquisitions. The company’s IT included IBM mainframe and DB2 database technology, Microsoft SQL Server, and Oracle Database, as well as a raft of legacy COBOL applications.
“As you can imagine, it’s very difficult to deliver three different database systems simultaneously,” says Paolo Kreth, team leader for database management systems at Mobiliar. “You need different technicians for each, you need different hardware for each, and you need different licensing for each.”
Management at Mobiliar realized that maintaining three databases was no longer feasible, nor did that fit the company’s long-term plans. “We had decided to get off the mainframe and move toward Java and open systems,” explains Jochen Maas, head of base service, IT operations, at Mobiliar. “The key to getting off the mainframe was finding the right database to support that strategy.”
Mobiliar was running several instances of Oracle Database 11g, including one that supports its call center’s Siebel Customer Relationship Management (Siebel CRM) applications from Oracle, and the company decided its new strategic database platform going forward would be Oracle—specifically, Oracle Database 12c with the Oracle Database In-Memory option.
“We chose Oracle to become our strategic database,” says Kreth. “We plan to stop using DB2 over the next 10 years. We need that time frame because all our core applications on the mainframe are written in COBOL.”
Oracle’s stewardship of Java was one factor in the database decision, says Kreth. “Going with Oracle Database will closely align us with Java technology,” he notes.
Location: Berne, Switzerland
Industry: Financial services
Employees: More than 4,000
Revenue: CHF 596.4 million in 2014
Oracle products: Oracle Database 12c, Oracle Database In-Memory option, Oracle Database 11g, Siebel Customer Relationship Management applications
But more important in the database decision were the performance improvements that the Oracle Database In-Memory option offered to existing applications without changes or fine-tuning. “With the Oracle Database In-Memory option, we can improve an application’s performance in minutes,” says Kreth.
Oracle Database In-Memory adds a new in-memory column store to Oracle Database’s existing row format. The row format provides optimal performance for online transaction processing (OLTP), and the in-memory column format delivers the best performance for analytics. (See the “Best of Both Worlds” sidebar for information on Oracle Database In-Memory.)
To prove the performance benefits of the Oracle Database In-Memory option, Kreth and his team set up a proof of concept to test three different database scenarios that are typical of the firm’s current operations.
For the first test, the team chose a recurring business operation. “We selected a typical business case at Mobiliar today,” says Kreth. “When we sell to a new customer, that customer’s information is entered in a DB2 database, but that data isn’t visible to the sales data warehouse until the contract is signed. But that happens later, and we can’t go back two days after a customer has signed a contract and say, ‘Hey, if you also bought car insurance from us, we could give you this extra discount.’”
Oracle Database 12c (Release 126.96.36.199) was installed on a seven-blade, Intel Xeon–based server with 384 GB of main memory per blade and the Linux operating system. It was then populated with the same data that ran on the firm’s sales data warehouse.
For the first test, the team enabled Oracle Database In-Memory on the seven-blade server and essentially tested the system “as is,” changing only one table partition. Says Kreth, “We wanted to see what would happen if we just took the data, activated the Oracle Database In-Memory option, and did nothing.”
The answer confirmed the company’s new database strategy, he says. “Some queries were faster, some were slower, but overall the Oracle Database In-Memory option increased query performance,” he notes. “Our management was very happy. They did not have to worry about a loss of performance because of the change in our database strategy.”
In the second scenario, the team tested the Oracle Database In-Memory option on a new executive data warehouse that was under construction. “We worked with the executive data warehouse team to come up with some simulated queries that probably will happen,” explains Kreth. “For some queries, we saw very big improvements—for instance, we had one report that was running in 200 to 300 seconds and it now runs in a second.”
For the third scenario, the test team wanted to see how the company’s 20-year-old risk management system, dubbed RICO, would perform on Oracle Database In-Memory. The team made only a few changes to the partitioning schema of the application, which has its own 1 TB database. “On average, the Oracle Database In-Memory option improved RICO’s application performance between 50 and 200 times,” says Kreth.
As a first step, Mobiliar is upgrading all its existing Oracle Database 11g installations to Oracle Database 12c, and from there, it will activate the Oracle Database In-Memory option on all its Oracle databases over time. The first application to go into production with the Oracle Database In-Memory option was Mobiliar’s new enterprise data warehouse, in April 2015. The new data warehouse runs on the same blade server hardware used for the proof of concept; four blades are being used for development, testing, and integration.
“Currently we have licenses for two blade servers for the Oracle Database In-Memory option,” says Kreth. “But we have signed a contract to license the Oracle Database In-Memory option for even more blades, and over the next year we intend to activate the Oracle Database In-Memory option for all our other production databases.” “With the current performance results, the Oracle Database In-Memory option has proven its worth,” says Kreth. “We will now be looking to optimize our database designs to work more effectively in memory.”
The Oracle Database In-Memory option is a technology whose time has come, thanks to the availability of inexpensive RAM and a new generation of 64-bit operating systems, says Maria Colgan, master product manager at Oracle.
“Organizations are demanding to be able to analyze their data in real time—without having a negative impact on OLTP [online transaction processing] performance and without having to wait for the classic ETL [extract, transform, and load] process to load into the data warehouse,” says Colgan. “Analytic queries tend to hit a subset of columns out of a table with millions or billions of rows, whereas OLTP applications hit all the columns for a very small number of rows. Having the data structured automatically for both—column-wise for analytic queries and row-wise for OLTP—is a capability that businesses demand.”
To provide the best performance for both OLTP and analytics, the Oracle Database In-Memory option adds a new in-memory column store that allows data to be simultaneously populated in memory in both the traditional row format for OLTP and an in-memory column format for analytics. The new column format complements but does not replace the existing buffer cache, so the data can be held in memory in both column and row formats.
The Oracle Database query optimizer automatically routes queries to the correct format—the column format for analytic queries and the row format for OLTP queries—transparently delivering best-of-both-worlds performance. Oracle Database automatically maintains full transactional integrity and consistency between the formats. And because the new in-memory column format is purely in memory and not persistent on disk, there remains only a single copy of the table in storage (in row format), so there are no additional storage costs or synchronization issues.
LEARN more about Oracle Database In-Memory
Photography by Aldo Schumann,Unsplash