Na meer dan een jaar hard werken aan het replenishment systeem van Etos, was het 21 maart 2016 zo ver: 3 winkels zijn gestart met het nieuwe systeem. Bestellen gaat automatisch op basis van voorraad, verkoophistorie en toekomst prognoses. Tellen in de winkel wordt gestuurd door de handheld. In de winkel draaien naast de POS (kassa) 2 systemen. 1 systeem op de desktop en 1 systeem op de handheld. Naast het tonen van de artikelinformatie kunnen de ontvangsten van de bestellingen op de handheld gedaan worden. Ook kunnen de tellingen op de handheld worden ingevoerd. Tellen wordt eenvoudiger maar ook belangrijker. Door het nieuwe systeem zouden lege schappen niet of weinig meer mogen voorkomen.
Het nieuwe systeem bestaat uit vele onderdelen. Orcado heeft de desktop- en handheld-applicatie ontworpen en gebouwd. Hierbij hoort ook het artikel planningssysteem, of de automatische herbevoorrading en de ontwikkeling van de interfaces met de andere systemen.
Samen met de andere partners van Etos mocht er een feest georganiseerd worden. Iedereen was aanwezig. De locatie was midden in Amsterdam. Op de bovenste verdieping van de Zilveren Toren met uitzicht over heel Amsterdam. De opening van de avond werd verzorgd door Jan-Derek Groenendaal, general manager van Etos, vervolgens was het de beurt aan Ben Wishart, Group CIO van AHOLD. Allebei de heren waren vol lof over het behaalde resultaat.
Tot slot kwam Nigel Ford aan het woord. Er werden een aantal collega’s in het zonnetje gezet, het zonnetje dat natuurlijk bedoeld was voor ons allemaal.
Het feest ging verder met een heerlijk buffet. Er werden behoorlijk wat rondjes rond de buffettafels gemaakt.
Daarna ging het echt los. De muziek ging harder en alle voetjes kwamen van de vloer. De collega’s uit India hadden wat aansporing nodig maar gingen uiteindelijk ook mee rond in de Hollandse-Polonaise. Een van de hoogtepunten van de avond was dat de Portugese collega André Alves het lied zong van Michel Teló: Ai Se Eu Te Pego. We kunnen terugkijken op een geslaagde avond die ons motiveert om vol energie het volgende traject te vervolgen. De gefaseerde uitrol van de applicatie in alle winkels en het voltooien van Release 7. Orcado heeft er zin in.
Recently I was investigating on performance issues with a java application. Due to object relational mapping this application generated a lot of varying sql statements which often had plan issues.
I wanted to replay some of these statements with variatons to find a generic solution to this.
The SQL monitor reports however had a lot of bind variables of the timestamp type. In the reports these were represented in a value like this: 7874051A0B1F01
At first I just guessed the values but at some time I really needed to know if they were querying a week or a year of data.
I decided to reverse engineer the format with a testscript which generated SQL monitor reports using a range of timestamps. From the reports I digested the format and made a SQL query to translate them:
[code language=”sql”]
select to_timestamp
( to_char (to_number (substr (:input, 1, 2), ‘xx’) – 100, ‘fm00’)
|| to_char (to_number (substr (:input, 3, 2), ‘xx’) – 100, ‘fm00’)
|| to_char (to_number (substr (:input, 5, 2), ‘xx’), ‘fm00’)
|| to_char (to_number (substr (:input, 7, 2), ‘xx’), ‘fm00’)
|| to_char (to_number (substr (:input, 9, 2), ‘xx’) – 1, ‘fm00’)
|| to_char (to_number (substr (:input, 11, 2), ‘xx’) – 1, ‘fm00’)
|| to_char (to_number (substr (:input, 13, 2), ‘xx’) – 1, ‘fm00’)
|| to_char (nvl (to_number (substr (:input, 15, 8), ‘xxxxxxxx’), 0), ‘fm000000000’)
, ‘yyyymmddhh24missff’
)
from dual
[/code]
The above timestamp representation translates to 26-5-2016 10:30:00,000000000.
For timestamps with timezones or ones with a different precision the formula will probably be similar.
Last week I was called in on a performance issue regarding a query on a datawarehouse that took about 4 hours. When looking at the execution plan in the excellent sql monitor I noticed a big full table scan yielding a whopping 125 million rows. Before I could turn around to ask the application team why this table was not partitioned my eyes were drawn to the cpu usage and wait bars in the plan. The buffer sort on the result of the full table scan was taking far more time than the scan itself!
I have seen this phenomenon a long time ago and I wouldn’t have thought this issue would still be around in the 11g r2 database.
The culprit in this is the cartesian join. The query contained a cartesian join to a calendar table which was filtered on a single day. The result in this case is that the 125 million rows are put in a sort area for the buffer sort. The sort area is way to small to hold these rows and so we end up doing this on disk using temp.
The approach the optimizer took is probably to prevent the full table to be repeated in case the cardinality estimate on the calendar was off, but the result is pretty dramatic. When I forced the use of a nested loops join the buffer sort was gone. What is left is that in 11g r2 the optimizer apparently still doesn’t have the capability to forsee the cost of the buffer sort disk operation.
For now there doesn’t seem to be an elegant way to work around this, maybe the adaptive query optimisation of 12c will resolve this in a better way.
EDI – de ultieme integratieIk ben inmiddels al ruim 13 jaar bezig met EDI. Dat is best lang. Zo lang dat ik bij veel collega’s zelfs bekend sta als “Mister EDI”.
En het is ook alweer zo’n 9 jaar geleden dat ik voor het eerst te maken kreeg met het vakgebied van Integration en Middleware. In mijn geval betreft dat voornamelijk het werken met webMethods.
In al die jaren is mij een aantal zaken opgevallen. Als ik in mijn werk betrokken ben als EDI Architect dan komt heel vaak het volgende voorbij:
In mijn werk als Integration Architect hoor ik vaak heel veel ambities voorbij komen:
Tja, dan denk ik soms wel eens: dat ouderwetse EDI, is dat eigenlijk al niet decennia lang de ultieme vorm van Integration?
Hier komt de sidebar