Erhm why would we run Windows XP or Vista on our blade servers in our central european data center?
A 64-bit version Job Server for Windows 2003 seems to make the most sense to me.
DI Designer can remain 32 bit of course - thats just a workstation application. But we could really use a 64-bit Job Server that can handle the massive volume of financial data we receive from all over Europe and doesn’t suffer from a 2 GB memory limit.
64-bit on client OSes (XP, Vista) seems unnecessary.
I understand from Werner’s previous post about it, that there are dependencies on drivers for the various DBs and connectors that DI can use. For example, on 32-bit DI running on 64-bit Win2003, you can’t even get to an Access ODBC data source. And the MySQL support with that combination is flaky.
Now I’m probably going to get publicly executed for this but… just because MySQL might have an issue with 64-bits support, it would delay a Windows 2003 based 64-bit DI Job Server which would work just fine with 64-bit editions SQL Server 2000, SQL Server 2005 and Oracle 10g? 64-bit connectivity with these databases isn’t an issue at all.
That doesn’t really make a lot of sense to me. But that’s probably because I’ve never encountered MySQL as a Data Warehouse platform with any of my clients or employers. But perhaps that’s just the European banking industry - where Oracle and SAP are king and Microsoft is the runner up. Perhaps in other areas MySQL is used more frequently?
Still, when selling and supporting this software, it’d be a complex message to get across. DI supports mainframe connectivity, a variety of ODBC sources, real-time database log scraping (CDC), connections to ERP/CRM systems, and so on. Until BO can certify the majority of these connectors, I can understand the reluctance to roll out a 64-bit platform.
I agree, though, that UNIX DB2, Oracle, and SQL probably represent the bulk of what people connect to, database-wise.
Has anyone tried running DI job server on Windows 64-bit with iSeries ODBC driver?
According to IBM iSeries driver for 64-bit would not work with 32-bit apps. I would like to see if anyone had any experience with that.
Thanks!
I am considering splitting my job server to a separate box so my db can be on a 64-bit. But I don’t know whether that would jeopardize the ETL performance.
Do you know if it’s a good practice to have the job server on a separate machine vs on the target database server? I found mixed messages about that. I am running SQL Server 2005 and DI 11.5.3.1
If they’re on separate boxes, make sure they’re really “close” to each other on the LAN and you should have gigabit ethernet between them.
If they’re on the same single box, make sure that one box is big enough.
What sort of load/volume/database size/number of rows processed are you expecting?
Given the cheap price of hardware these days, I wouldn’t recommend (for SQL 2005) anything smaller than (2) dualcore CPUs and 16Gb RAM. Make sure your disk space is RAID 10 and not RAID 5 (whether it’s local disk or on a SAN.).
we do incremental load everyweek from the iSeries which takes about 6 hours and a full load on Saturday that takes about 14 hours. The biggest table is about 15mil rows and the second biggest is about 4mil. My staging db is about 100gb and the biggest mart is 50gb. The box is a dual CPU and has 16GB of RAM.
We are upgrading to put data on SAN and keep the logs and DI on a separate beefed up box. I want my jobs to run faster and my reports too as we have a very heavy usage during the day when corp reports being generated.
I am currently using the ODBC to connect to the iSeries. I heard that DB2 client or DB2 connect work better. Any experience with that?
Thanks for the suggestions on the hardware.
Hi All,
I am struggling with the ODBC Iseries for windows . I have DI 11.7.2 installed on windows 2003 server 64 bit OS machine.
In DI, I can browse the As/400 library, I can import, as well as view data, but when I try to run a simple job (extract a table from AS/400 using this ODBC Iseries), the job failes with ODBC call failed… Can not resolve port(1764 3936 CON-120302 11/17/2007 2:38:32 PM ODBC call for data source <MSDUS01_D3GGMAACD> failed: <[IBM][iSeries Access ODBC Driver]Communication link failure. comm rc=11004 - CWBCO1011 - Remote port could not be resolved>. Notify Customer Support.)
is there any solution to this or a recommandation.
Importing tables and viewing data is something your PC does (the Designer client on your PC is opening the database connection). It doesn’t have anything to do when you run the job itself.
On the job server machine, do you have the appropriate AS/400 connectivity (database driver or middleware or whatever) installed?
From the job server, can you log into the database directly (not through DI) successfully?
Are you using 32-bit drivers, and not 64-bit drivers? You’d need a 32-bit driver/middleware.
I do have an Iseries access for windows (V5R3M0) installed on the DI server. it is a 32 bit client. I can use the Iseries navigator (on the DI server) and navigate through the as/400 libraries.
I also use the same ODBC connection to browse , import and view the data through the DI designer which is also installed on the DI server.
I do have another DI server installed on 32 bit windows server 2003. and the whole setup works fine.
I am starting to think it is a 64 bit thing that is causing all this.
Could someone “in the know” answer this question? Is there something in the works or is this years away? As someone said a Windows 2003 x64 version is the obvious choice.
Some of the core 3rd party libraries used inside DI are not available for Windows 64bit. So either we get rid of them or we wait until available - either way it won’t be quick. Personally I would not expect to get something in 2008 - but I am not involved much in this particular discussion. However, I have shown this threat here to my team. If there are particular reasons why somebody believes a 64 version to be key for his use, please post here and I will send an update to my team.
Volume of data we can process that might exceed the 2GB limit is one of them.
Improved performance/processing power is another.
We have invested heavily in our 64-bits server architecture - our management is now asking us why we are using 32 bits products. As Business Objects gave me no other option to answer “because there is no 64 bits DI Job Server for Windows 2003” - our managers are now looking at alternative products.
Basically, I see no excuse where there is no 64 bits DI Job Server other than bad product release management.
It sounds very risky that DI as a product depends on lazy, 3rd party suppliers. How do you control your own development cycles? What if they go bust? A big corporation like BO/SAP should force those suppliers to deliver 64 bit versions or tell them to take their business elsewhere.
I’m quite shocked to learn that there is no 64 bit version on the horizon. This is something I have to report to my management as we also have invested heavily in our 64 bit server / database platform. When we bought DI in late 2005 we were told that late 2006 / early 2007 there would be a 64 bit version ready.