Comments on: Improving the performance of Exact Globe http://productblog.exactsoftware.com/2009/08/improving-the-performance-of-exact-globe/ Sat, 20 Mar 2010 10:01:12 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Matthew Bather http://productblog.exactsoftware.com/2009/08/improving-the-performance-of-exact-globe/comment-page-1/#comment-517 Matthew Bather Wed, 07 Oct 2009 12:45:59 +0000 http://productblog.exactsoftware.com/?p=486#comment-517 It is not often I am surprised by software. Being in Product Management sort of removes any of the unknown excitement of "playing" with new software. Well, upon updating my local system to the latest cut of Update 395 (currently in CR), I had one of those Wow moments! I know Globe intimately, having been responsible for many of the designs in logistics and manufacturing, so I had an idea as to where I might check to see if the performance had actually improved. Well, the term "blazing" comes nowhere close to what I experienced. Brilliant and crisp. One might liken the increase in performance to upgrading from a tube based TV set to a High Definition 1024p, 52" flatscreen TV. Admittedly, my database is nothing significant, but the improvements will definately be relative, and remain significant. Anyone still thinking about whether to look at 395 should stop thinking and participate in the CR. Put the product in a "sand-box", test it, shake it and make your own determination. We can debate the technology implications of this all day long, each with differing opinons based on personal experience. At the end of the day, the real issue at hand is the increase in performance. Would you prefer to fly from London to Singapore on a Boeing 747 or would you prefer the Concorde? It is not often I am surprised by software. Being in Product Management sort of removes any of the unknown excitement of “playing” with new software. Well, upon updating my local system to the latest cut of Update 395 (currently in CR), I had one of those Wow moments! I know Globe intimately, having been responsible for many of the designs in logistics and manufacturing, so I had an idea as to where I might check to see if the performance had actually improved. Well, the term “blazing” comes nowhere close to what I experienced. Brilliant and crisp. One might liken the increase in performance to upgrading from a tube based TV set to a High Definition 1024p, 52″ flatscreen TV.

Admittedly, my database is nothing significant, but the improvements will definately be relative, and remain significant.

Anyone still thinking about whether to look at 395 should stop thinking and participate in the CR. Put the product in a “sand-box”, test it, shake it and make your own determination. We can debate the technology implications of this all day long, each with differing opinons based on personal experience. At the end of the day, the real issue at hand is the increase in performance. Would you prefer to fly from London to Singapore on a Boeing 747 or would you prefer the Concorde?

]]> By: Ronald Voets http://productblog.exactsoftware.com/2009/08/improving-the-performance-of-exact-globe/comment-page-1/#comment-378 Ronald Voets Tue, 22 Sep 2009 07:58:48 +0000 http://productblog.exactsoftware.com/?p=486#comment-378 @Nilesh, To mitigate the risk of locking by the SQL triggers, we're oinly doing inserts and no updates. There's a background job on the SQL server installed, by default running at 2am, to merge the records in the new transaction total tables. Also good to mention, is that users can turn the usage of the new transaction total tables OFF as well. Once it's turned OFF, Exact Globe will behave and perform as it does today. That's another step we took to mitigate the risk of the implementation. @Heiko We're constantly seeking for ways to improve the performance of Exact Globe. The triggers are 1 step to improve the performance of Exact Globe, removing historic MRP records is another one implemented in 395, improved index structure on some master data (based on customer database statistics) is a third one implemented in 395. So it's not "just " the database model we focus on :-) @Nilesh,

To mitigate the risk of locking by the SQL triggers, we’re oinly doing inserts and no updates. There’s a background job on the SQL server installed, by default running at 2am, to merge the records in the new transaction total tables.

Also good to mention, is that users can turn the usage of the new transaction total tables OFF as well. Once it’s turned OFF, Exact Globe will behave and perform as it does today. That’s another step we took to mitigate the risk of the implementation.

@Heiko We’re constantly seeking for ways to improve the performance of Exact Globe. The triggers are 1 step to improve the performance of Exact Globe, removing historic MRP records is another one implemented in 395, improved index structure on some master data (based on customer database statistics) is a third one implemented in 395. So it’s not “just ” the database model we focus on :-)

]]> By: Heiko van der Vlugt http://productblog.exactsoftware.com/2009/08/improving-the-performance-of-exact-globe/comment-page-1/#comment-377 Heiko van der Vlugt Tue, 22 Sep 2009 07:40:15 +0000 http://productblog.exactsoftware.com/?p=486#comment-377 Hi Ronald, The comment of Hans is true, we did use Indexed views in our Easy Access time and with great success, even with millions of transactions (database >400 GB and performing great). I assume the triggers are the first steps to an improved database model? Hi Ronald,

The comment of Hans is true, we did use Indexed views in our Easy Access time and with great success, even with millions of transactions (database >400 GB and performing great).

I assume the triggers are the first steps to an improved database model?

]]> By: Nilesh Jain http://productblog.exactsoftware.com/2009/08/improving-the-performance-of-exact-globe/comment-page-1/#comment-375 Nilesh Jain Tue, 22 Sep 2009 05:03:01 +0000 http://productblog.exactsoftware.com/?p=486#comment-375 Hi Roland, This indeed would be a good alternative to retrieve balances and write customized reports which could be faster than before. But how about updating of new tables based on triggers. In a situation where more than 200+ users are working on sales/purchase process in a single Globe databse, won't it block the table thus users would feel the performance bottleneck during transaction entry/process. I have faced similiar situation in an integrated scenario (Globe/Synergy) where balance table of Synergy was being updated dynamically (based on transaction activities in Globe) and was locked out due to heavy usage. I hope we don't miss out on this as we must keep the large users sites in consideration. Hi Roland,
This indeed would be a good alternative to retrieve balances and write customized reports which could be faster than before.

But how about updating of new tables based on triggers. In a situation where more than 200+ users are working on sales/purchase process in a single Globe databse, won’t it block the table thus users would feel the performance bottleneck during transaction entry/process. I have faced similiar situation in an integrated scenario (Globe/Synergy) where balance table of Synergy was being updated dynamically (based on transaction activities in Globe) and was locked out due to heavy usage. I hope we don’t miss out on this as we must keep the large users sites in consideration.

]]> By: Ronald Voets http://productblog.exactsoftware.com/2009/08/improving-the-performance-of-exact-globe/comment-page-1/#comment-372 Ronald Voets Mon, 21 Sep 2009 09:06:27 +0000 http://productblog.exactsoftware.com/?p=486#comment-372 Hi Hans, good comment. We considered indexed views, but decided to use SQL triggers since that resulted in better performance improvements. If you have a database with a million transaction records and you create an indexed view for i.e. actual stock on it, then SQL needs to recalculate that view with every stock update/insert/deletion action on the transaction table. We've splitted the SQL triggers into 3 parts; one for updates, one for inserts and one for deletions. That means for the example of a stock totals table, the trigger only adds/subtracts whatever stock is received/fulfilled and doesn't need to recalculate the new total stock actuals via a an expensive/slow query on the GBKMUT table (like in a situation with indexed.views). Hi Hans,
good comment. We considered indexed views, but decided to use SQL triggers since that resulted in better performance improvements. If you have a database with a million transaction records and you create an indexed view for i.e. actual stock on it, then SQL needs to recalculate that view with every stock update/insert/deletion action on the transaction table.
We’ve splitted the SQL triggers into 3 parts; one for updates, one for inserts and one for deletions. That means for the example of a stock totals table, the trigger only adds/subtracts whatever stock is received/fulfilled and doesn’t need to recalculate the new total stock actuals via a an expensive/slow query on the GBKMUT table (like in a situation with indexed.views).

]]> By: Hans van Essen http://productblog.exactsoftware.com/2009/08/improving-the-performance-of-exact-globe/comment-page-1/#comment-371 Hans van Essen Mon, 21 Sep 2009 08:41:03 +0000 http://productblog.exactsoftware.com/?p=486#comment-371 Why are you using triggers? SQL Server supports indexed views wich performs *MUCH* better, is less error prone and is also much simpler to implement. And yes, you can also use indexed views on SQL Server standard and desktop editions. Why are you using triggers?
SQL Server supports indexed views wich performs *MUCH* better, is less error prone and is also much simpler to implement. And yes, you can also use indexed views on SQL Server standard and desktop editions.

]]> By: Ronald Voets http://productblog.exactsoftware.com/2009/08/improving-the-performance-of-exact-globe/comment-page-1/#comment-286 Ronald Voets Fri, 28 Aug 2009 07:58:41 +0000 http://productblog.exactsoftware.com/?p=486#comment-286 Hi 'user', it's a very interesting concept indeed and we're quite excited about the results in our labs so far. it's the first time we deploy SQL triggers on Exact Globe. In the past sometimes customer-specific triggers may have neen deployed by consultants, b ut it's the first time we ship this as a standard part of Exact Globe. The table on which the trigger runs is our main transaction table GBKMUT. In a post next week, i will go into a bit more detail on the triggers themselves and the preliminary results. Stay tuned ;-) Hi ‘user’,
it’s a very interesting concept indeed and we’re quite excited about the results in our labs so far.
it’s the first time we deploy SQL triggers on Exact Globe. In the past sometimes customer-specific triggers may have neen deployed by consultants, b ut it’s the first time we ship this as a standard part of Exact Globe.
The table on which the trigger runs is our main transaction table GBKMUT. In a post next week, i will go into a bit more detail on the triggers themselves and the preliminary results. Stay tuned ;-)

]]> By: A User http://productblog.exactsoftware.com/2009/08/improving-the-performance-of-exact-globe/comment-page-1/#comment-285 A User Fri, 28 Aug 2009 07:49:31 +0000 http://productblog.exactsoftware.com/?p=486#comment-285 Hi Ronald Well this does sound very interesting! SQL Triggers on Exact DB is this a first? Are you able to say which tables will have these triggers? Best regards Hi Ronald

Well this does sound very interesting!

SQL Triggers on Exact DB is this a first? Are you able to say which tables will have these triggers?

Best regards

]]> By: Ronald Voets http://productblog.exactsoftware.com/2009/08/improving-the-performance-of-exact-globe/comment-page-1/#comment-283 Ronald Voets Thu, 27 Aug 2009 11:05:08 +0000 http://productblog.exactsoftware.com/?p=486#comment-283 Hi Andre, Thanks for the comment. The new tables that keep the transaction totals, are only implemented for Exact Globe. For Exact Synergy nothing changes. We thought about re-using the Balance table as used by Exact Synergy, but this table has too much 'grouping' (so too much details) which we don't need for Globe. So if we would use the Balance table from Synergy also in Globe, then the table would become too large (too many records) and not fast enough. I share your concern that two different data sources can lead to differences. It's THE reason why we could only do this project if we succesfully implemented it with SQL triggers. We're not going to rely on each individual application updating two tables instead of one. Hi Andre,

Thanks for the comment. The new tables that keep the transaction totals, are only implemented for Exact Globe. For Exact Synergy nothing changes. We thought about re-using the Balance table as used by Exact Synergy, but this table has too much ‘grouping’ (so too much details) which we don’t need for Globe. So if we would use the Balance table from Synergy also in Globe, then the table would become too large (too many records) and not fast enough.

I share your concern that two different data sources can lead to differences. It’s THE reason why we could only do this project if we succesfully implemented it with SQL triggers. We’re not going to rely on each individual application updating two tables instead of one.

]]> By: Andre Speek http://productblog.exactsoftware.com/2009/08/improving-the-performance-of-exact-globe/comment-page-1/#comment-282 Andre Speek Wed, 26 Aug 2009 22:56:07 +0000 http://productblog.exactsoftware.com/?p=486#comment-282 Sounds impressive and interesting. Still some hesitations for point 2. In a One-X or Single Database scenario's there is already the Balance table which is used by Synergy. So I'm going to check if this new Balance table for Globe is maybe this one or a newly introduced table. I hope that the existing Balance table will be used. If not, I hope the Synergy reports and Globe reports that are each other counterparts are very well verified to have the same results. Similar reporting on different data sources (like we had on the Outstanding Amounts years ago, where Synergy used GBKMUT and Globe used BankTransactiont) is always very tricky since the one building the reports is not the one that fills the table. And wow... SQL triggers...? I have to adjust my Query toolkit. I have one that can find all triggers that are not on the EBC tables since those are (correction... were) certainly not created by Exact and might very well be the source if unexplainable database errors occurs. Hey... let's even be more careful out there... :D Cheers, Andre Sounds impressive and interesting. Still some hesitations for point 2. In a One-X or Single Database scenario’s there is already the Balance table which is used by Synergy. So I’m going to check if this new Balance table for Globe is maybe this one or a newly introduced table.

I hope that the existing Balance table will be used. If not, I hope the Synergy reports and Globe reports that are each other counterparts are very well verified to have the same results. Similar reporting on different data sources (like we had on the Outstanding Amounts years ago, where Synergy used GBKMUT and Globe used BankTransactiont) is always very tricky since the one building the reports is not the one that fills the table.

And wow… SQL triggers…? I have to adjust my Query toolkit. I have one that can find all triggers that are not on the EBC tables since those are (correction… were) certainly not created by Exact and might very well be the source if unexplainable database errors occurs.

Hey… let’s even be more careful out there… :D

Cheers,

Andre

]]>