Databases and ERP Selection: Oracle vs SQL Server

Transcription

1 DATABASES AND ERP ORACLE VS SQL SELECTION: SERVER

2 Databases and ERP Selection: Oracle vs SQL Server By Rick Veague, Chief Technology Officer, IFS North America An enterprise application like enterprise resources planning (ERP) or enterprise asset management (EAM) is comprised of multiple technologies layers, but during a software selection process it is the database layer that can be the subject of some of the most heated discussions, at least among technologists. Technologists, like everyone else, have preferences and biases about a number of things, including databases. In this whitepaper, we ll try to sidestep these biases and preferences to compare how SQL Server and Oracle databases compare when it comes to their ability to support an enterprise application in small to medium-sized business (SMB), middle market and enterprise-level situations. Is one database platform really more complex to operate or expensive to run? How well does each platform scale to support additional users and business growth? Industry standard, application standard IFS Applications has always standardized on Oracle databases. This is in part because from the standpoint of security, scalability, reliability, and the ability to support mission critical business processes, Oracle databases are widely recognized as being superior to other offerings on the market. IT analysts with The Edison Group have completed studies comparing Oracle databases to SQL server, and have found that they are more scalable, faster, more reliable and more affordable. Specifically, Edison found that Oracle is 47 percent faster than any SQL server install in a Windows environment and it costs 20% less. As even SMBs are operating internationally and need to support 24-7 operation with a lean IT staff, these strengths of the Oracle database platform become even more important. It is certainly a misnomer that Oracle is more expensive or more difficult to operate and support than SQL. This may have been a consideration a number of years ago, but since then, Oracle has added numerous features, to expedite installation and management of the database, as well as features to automate storage management and memory management. Oracle has also developed diagnostic tools that can not only provide real-time information on the health of the database but make intelligent recommendations about how to avoid problems or even improve performance based on the actual usage patterns of the database. Choosing an enterprise application that is designed exclusively for a single database should be appealing because that application can be optimized to take advantage of everything the Oracle database has to offer, delivering more powerful IFS, April

3 ORACLE VS SQL SERVER querying and enterprise application search functionality than applications that support multiple databases. Enabling those powerful database features, if the application is not aware of them, is a very complex task. You will also see an improvement in overall performance if an application is designed specifically to run on a single database platform because the application is carefully tailored for the way a particular product performs. All of these things result in lower overall cost of ownership, higher reliability and a more satisfied end user because you will have greater uptime, greater performance, less maintenance overhead and system overhead by technicians. Administrative, financial costs Oftentimes, the database administrator (DBA) or IT staff of a company in a software selection process will express misgivings about the Oracle database because the company might lack a certified Oracle DBA. If you are looking at packaged software that has been optimized for a specific database, the amount of technical skill that you need is reduced, because the optimization work has already been done by the vendor. An application that is wellmannered and makes good use of the database will present very few challenges when it comes to daily management of the underlying database because the application will automate many database administration processes. The skills and tasks required of a DBA are similar with both products. The specific controls used to undertake those tasks may differ from one product to the other, but the knowledge that the DBA applies is essentially the same. If someone has SQL Server experience, they can generally apply that knowledge to an Oracle database administration setting. An IT professional who knows how to back up a database can perform this task just as easily if not more easily in Oracle as they can in SQL. The same is true of other database maintenance activities that might be required of a DBA. In the area of financial cost, the Oracle database has advantages over other database products on the market, but has been perhaps mischaracterized as carrying a premium price. When it comes to acquisition cost, the Oracle database is priced in different tiers, including tiers for midrange computers where the pricing is very aggressive. Oracle prices database licenses to market using SQL Server as a benchmark, and in many cases, the Oracle database can come in below SQL for a comparable license. But the Oracle solution, while being competitive in price with SQL, comes bundled with the ability to use advanced features like real application clusters. So what you get is a robust, affordable database in a scalable configuration that SQL Server cannot offer. Scalability and high availability Scalability, the ability of the database to expand and support additional users and transaction volumes over time, and high availability, the ability to continue transaction processing in event of a component failure, are traditional strengths that Oracle provides. As more and more small and medium sized enterprises require IFS, April

4 ORACLE VS SQL SERVER support for multi-site, global operations, scalability and high availability become even more important. There are many elements that contribute to the scalability and availability of the database: The size of the database must grow over time with limited DBA involvement, and without requiring changes to the application layer. Oracle provides many automated tools and features such as Automatic Storage Management (ASM) to dynamically adjust database size and resource allocations. These adjustments are made based on the operational characteristics of how the database is actually used, which of course varies from customer to customer. This substantially reduces the need to accurately forecast ahead of time exactly how the database will be used as well as the need for manual adjustments. If not configured correctly, a database can fail resulting in downtime. Oracle automated management features can help prevent this from happening. Concurrency, the degree to which the database controls multi-user access and updates, is critical to application performance and how the database scales. Concurrency is often referred to as locking, and if not handled correctly can cause application delays and reduced transaction volumes. Oracle has always included support for scalable concurrency controls, including row level locking, the most granular form of concurrency control. Other databases typically support page level, or even table level locking, which effectively locks out larger portions of the database during updates. This can lead to high levels of user contention for data and results in delays. Recently, SQL has added support for row level locking, but not all applications can take advantage of this feature. Redundancy, the ability of the database to continue operation in the event of a hardware failure, is critical to uninterrupted application operation. Oracle supports grid computing to meet this challenge. Grid computing is a database architecture that enhances scalability and load balancing. Oracle Real Application Clusters (RAC) allows a single copy of a database to be accessed by multiple nodes (servers) in a computing cluster. This means that multiple applications, multiple users, can access the database simultaneously in real time while controlling synchronization and concurrency internally by the cluster itself. In the event one fo the servers in the cluster fails, processing is automatically resumed on a surviving node in the cluster. Other databases support clustering, but in a less active manner. In some cases, a backup server is running in a stand by mode, meaning the application must be restarted in the event of a failure. Other approaches, including data federation, require the database to be split over multiple servers. This can help with scalability concerns but not high availability concerns. Scalability can also be seen as a licensing issue. Oracle provides four different editions of its database product: XE a free developer version Standard Edition and Standard Edition One Enterprise Edition IFS, April

5 ORACLE VS SQL SERVER The advantage of this tiered license is that an SMB can license SE One and move up to other versions as the business grows. However, each tired edition interacts with an enterprise application in exactly the same way, so there are no changes needed to the configuration or coding of the application layer of the solution as the edition of the database changes. Conclusion The database is an important aspect of an overall enterprise application solution, but it is only part of the solution. From a packaged application perspective, looking at any one part of the solution makes less sense than looking at the overall solution and how it addresses business needs. In the end, the specific database technology used to support an enterprise application should be of secondary interest in an application selection process as long as the database technology: Is open, supportable and has a clear future to prevent technology lock in; Does not come with any penalties or drawbacks in terms of cost, ease of use, scalability or deployability; Is fully supported by the application, and the application layer takes full advantage of the databases feature set; Is scalable and supports cost effective high availability needs consistent with the business requirements. Rick Veague is Chief Technology Officer with IFS North America, and is based in the Schaumburg, Ill. headquarters. In this role, Veague provides direction for IFS use of Service-Oriented Architecture (SOA) and works with IFS leading customers to leverage SOA to provide state-of-the-art ERP. IFS, April

6 About IFS IFS, the global enterprise applications company, provides solutions that enable organizations to respond quickly to market changes, allowing resources to be used in a more agile way to achieve better business performance and competitive advantage. IFS was founded in 1983 and now has 2,600 employees worldwide. IFS has pioneered component-based enterprise resources planning (ERP) software with IFS Applications, now in its seventh generation. IFS component architecture provides solutions that are easier to implement, run, and upgrade. IFS Applications is available in 54 countries, in 20 languages. IFS Applications provides extended ERP functionality, including supply chain management (SCM); enterprise asset management (EAM); maintenance, repair, and overhaul (MRO); product lifecycle management (PLM); customer relationship management (CRM); and corporate performance management (CPM) capabilities. IFS has over 500,000 users across seven key vertical sectors: aerospace & defense, automotive, high-tech, industrial manufacturing, process industries, construction & facilities management, and utilities & telecom. IFS also provides a cross-industry solution for retail & wholesale distribution. More details can be found at For further information info@ifsworld.com This support offer has been made in order to respond to the requirements of IFS customers. Since the customers requirements may be different in some markets, variations of this offer may exist. IFS and all IFS product names are trademarks of IFS. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. The example companies, organizations, products, domain names, addresses, logos, people and events depicted herein are fictitious. No association with any real company, organization, product, domain name, address, logo, person or event is intended or should be inferred. This document may contain statements of possible future functionality for IFS software products and technology. Such statements of future functionality are for information purposes only and should not be interpreted as any commitment or representation IFS