ALL NEW Database Sharding Technology Has Been Part of JD Edwards for 20+ Years
Bill Rehm - Database Team Manager - Sr. Customer Success Manager
If you’ve been keeping up with new database features, you probably know that sharding is a new big thing in the DB world. If you haven’t, sharding isn’t a slang word for anything. It refers to splitting application data across multiple databases. It helps make a very large database more manageable and can allow the application to run much faster.
With JD Edwards, you don’t need any fancy database features or licenses to set up your very own shards. But let’s take a step back: Why would you want to split your data across multiple databases? The main reason is for performance. As your data grows it takes longer to read and manipulate that data. The bigger the table, the longer it takes to search through it (yes, even with indexes) to find what you need.
Now, any one individual table can grow quite large and you might not notice a performance issue if that was the only table you used. With a very large data footprint (like JDE) there are many large tables that are all interconnected. As a transaction winds through your application and the database, it will encounter a little bit of slowness here, a little slowness there, and that all adds up to noticeable performance issues. The database managing all those transactions has to be a traffic cop for thousands of transactions per minute and the application can really start slowing down.
That one database doesn’t have to do all the work though. What if you could pull out your busiest tables and put them on their own powerful database? How about just putting the F0911 General Ledger table on its own machine? You could even separate out an entire set of system codes (all of accounting, for example) and give them a dedicated system. Now you have multiple databases with their own independent resources managing subsets of your data.
You’re probably wondering what that looks like to your JDE application users. The great news is that they have no idea what’s happening in the background! As far as they can tell, the application works exactly the same way as before. They don’t have to go to any different screens or make any special accommodations.
What is this sorcery? It’s simple – Custom OCMs and Data Sources. You can add more than one database to a JDE installation, and they don’t have to be the same platform either. If your database is Oracle/Linux and you want to add an iSeries DB2/400 to the mix, go right ahead! JDE will work fine with both. Once you add that second database, you run the platform pack on it to get the basic configuration installed. Next, create new data sources that point to your second database. You can then pick the tables you want to reside on that new machine and set up OCMs that direct activity to the new data source.
There is a little bit of downtime required to physically move the table to the new platform, of course. If you are using all the same databases, you can use database tools to copy the table over to the new machine. With different databases the easiest way is to use R98403. Whichever way you choose, once the table is on the new database you simply activate the OCMs for those new table locations and you’re done! Your users won’t notice a difference except possibly that everything is running much faster now.
There’s a lot more you can do to speed up JDE processing, and you probably already have all the JDE and database features to do many of those things. Multiple databases, high availability, table compression, table partitioning, and much more can be done with the tools you already have. If you’re considering a third-party solution to split your data or speed up processing, take a step back and look at what you’ve got. You might already have that ability. If you need someone to look at your configuration and let you know your options, give the GSI database team a call and we’ll take care of you.
To find about GSI's products or services, call us at 855-GSI-4ERP or click on CONTACT US to send us a request for more information.
Meet the Author
Bill Rehm
