Open source databases running on Linux like MySQL, Ingres r3, PostgreSQL, and Firebird have aroused a lot of interest.

Database developers and corporate users are heralding the anticipated the release of MySQL 5.0, which includes enterprise-level features such as stored procedures, triggers, and views.

Last August Computer Associates made Ingres r3 available under the CA Trusted Open Source License and followed up with a Million-Dollar Challenge, an unprecedented offer to the open source community to develop migration toolkits for the system.

Tony Gaughan, senior VP at Computer Associates, says, "The relational database world is evolving. Enterprise customers are demanding rich, functional products that scale, while lowering the total cost of ownership. Ingres has the pedigree of one of the most seasoned and functional products in the market that can be flexible enough to meet the demands of even the largest organizations."

The publicly traded data infrastructure software company Pervasive Software now services and supports PostgreSQL. Marten Mickos, CEO of MySQL AB, as quoted in SearchEnterpriseLinux.com, is optimistic about open source databases this year betting that "We will see increased growth, faster growth than before, in the adoption of open source in the enterprise, not just for MySQL, but across the board."

Though surely not breaking news, there are many compelling business and technical reasons for migrating to an open source database running on Linux. IT organizations are becoming more focused on business value and are asking questions like "Are we overspending on software? Are there more cost-effective alternatives that meet our specific needs and don't lock us into a long-term relationship with a vendor?"

Besides, unlike the desktop, a database isn't a user-facing technology. A change or modification to a database is less likely to "stir a hornet's nest" among a company's transactional or knowledge workers.

From a technical perspective, security and flexibility are being given serious consideration. For example, since Microsoft SQL Server is tightly integrated into the Windows platform, it's exposed to Windows virus attacks and, as a result, is vulnerable. There have been numerous documented virus attacks on Microsoft Windows, the worst attacks targeted at SQL Server. The Sapphire/Slammer worm (www.cs.berkeley.edu/~nweaver/sapphire/) exploited a buffer overflow vulnerability in Microsoft SQL Server. It infected at least 75,000 hosts and caused network outages and unforeseen consequences such as canceled airline flights, interference with elections, and ATM failures.

Companies are valuing more and more the need to assume greater control of their development processes. With open source, not only can a company view and modify the source code to fix bugs and add needed features, they can control the code's future development. After a consultant or vendor has developed a specific open source application for a customer, that customer is free to use a different consultant or vendor for future development, maintenance, and enhancements if it likes.

Since it's unlikely that Microsoft will open source SQL Server anytime soon, I thought LinuxWorld readers might find an overview of how to migrate the data structure and data from SQL Server to open source databases running on Linux valuable. A word of caution - tread carefully! A manual migration is extremely tedious. Each step takes many man-hours to complete. And, due to space limitations, I won't address the manual migration of stored procedures, views, and triggers that, admittedly, are important components of the enterprise-level database.

That being said, if considering a migration from Microsoft SQL Sever to MySQL, I would recommend waiting for MySQL 5.0 since the current versions don't have stored procedures, views, and triggers. PostreSQL, Ingres r3, and Firebird support stored procedures, views, and triggers so those databases are ready for migration and implementation today. For additional instructions on migrating stored procedures, views, and triggers please see (www.versora.com/__files/documentation/database_migrationsec.pdf)

Migrating Data Structure
First, you'll need to export the table structure using SQL Server Enterprise Manager:

• At the SQL server, launch Enterprise Manager and connect to the database you intend to migrate.
• Select all the tables that are being migrated, right-click, and choose Generate SQL Scripts.
• In the dialog that appears, switch to the ‘Formatting' tab. Uncheck Generate the DROP <object > Command for each Object box. Check Generate Scripts for All Dependent Objects.
• To make things more manageable, you'll probably want to choose Create One File Per Object. Click OK and indicate where to save the script files. This procedure will create a data structure that works only with SQL Server.

Tweaking will be required for the new database. Consider removing the brackets around names and types. Change types to corollary types. Remove the permissions and index statements from the end of each of these files and store them in a temporary "holding" file that will be applied after data is applied (for speed reasons). If statements aren't revised as indicated, migrating the data will be significantly slower.

When completed, copy these files to the new machine (via file sharing, by burning a CD, or any other way you want), and apply them to the new database. Each database has its own way of running SQL script files though most will let you execute scripts via command-line redirection. For example, PostgreSQL has a command-line tool called psql used to import SQL script files. An example command line for PostgreSQL might look something like this:

psql <dbname> -U <username> < sqlscript.sql

The total time needed to move the data structure manually varies depending on which database you're migrating to, how complicated existing tables are, and how many tables there are. Though this isn't a difficult phase, it can be tedious.