tdm performance problems

Hallo !

We actually analyze TDM 3.6.6.7 (trial with full license key) as we want to switch over from erwin to tdm. From the aspect of functionality (special the customization) TDM looks very good.

We reversed our erwin ddl model (oracle 10g) to a tdm physical model. In this model we made our adaptions (default users, permissions, triggers etc.). From this base model we want to generate ddl scripts for our suppported target databases (oracle, postgres 8.4, sql server,…). For this we used the convert/synch wizzard.

Using this functionality (reverse, convert, create alter scripts) we came into extreme trouble concerning the TDM performance:

  • reverse engineer takes about 25 minutes. Here revese tables is the time consuming factor (60 tables, column count from 5 to 50).
  • converting to any other db (postgres, even oracle) seems to hang. After 30 minutes we aborted the process.
    Then we converted the model by selecting only a single entity. Even this procedure takes more than 10 minutes
  • alter script generation is the same. About 25 minutes to generate ddl script, where only some attributes are changed.

The machine has no other programs run.
I don’t know whether this is a general problem of TDM.
Are there any ideas how that problem could be solved ?

Our system:

  • WINDOWS XP, SP3
  • no Firewall, no AntiVirus
  • 2 GByte RAM
  • CPU Intel Core 2 Duo T7100, 1,8Ghz

Thanks,
Reiner.

.

Hi Reiner,

can you send me your model to modeling@quest.com, please? I will use it only for testing purposes, of course.

Please check how many other objects were reverse engineered. There can be 60 tables, but a lot of stored procedures, a lot of views… and other objects that can cause delays in reverse engineering/conversion. In any case a model with 60 tables is not a big model and TDM should work fast enough.

Additional info: Can you try to install TDM on another machine, please? And can you try to reverse engineer another 60 tables large database and let me know if the performance is still the same? Thank you in advance.

In order to check if your model is OK, follow instructions written here:
http://blogs.inside.quest.com/modeling/2010/10/25/how-to-test-and-repair-your-model/

Regards,

Vaclav

Hi Vaclav,

Thank you very much for your fast reply.
As we now want shortly to switch to a new modeler (hopefully tdm), this topic comes to a great problem for us.

I will shortly send you that test model. The problem actually is, that the full trial license key expired in this second and i did not have the modified reversed tdm model, which makes the trouble in converting. Meanwhile i asked QUEST to extend my trial license. As long as i wait for that license, i will send you the erwin generated ddl file, which makes the performance problems on reverse engineering.

Yes, i will install it on an other machine.
I will see, whether reverse can be executed in normal trial version.

Thanks,
Reiner.

Hi Reiner,

thank you. I guess there might be a problem with the DDL file. There is a big difference between reverse engineering of physically existing database and reverse engineering of DDL file. Theoretically there might be errors in the DDL file or there can be a subset of a model or there can be something “third party software specific” etc.

In order to avoid problems I can recommend to create your database physically and reverse engineer physically existing database.

I’ll test your model and write you details then.

Regards,

Vaclav

Hi Vaclav !

Ok, direct reverse engineer from db server i will test later.

Now i could send you the reversed tdm file including the adaptions.
Using this tdm model, converting and alter scripts takes extremely long (could not finish any conversion until now).

Another point:
When in creating alter scriopt the “difference tree” is displayed, it is nearly impossible to collapes the tree nodes. It takes seonds for a node collapse/decollapse.

Regards,
Reiner.

Hi Reiner,

we tested it on multiple machines and performance was bettter (also on machines similar to the mentioned configuration - RE took about 8mins). It depends on how many processes are running on your PC etc. In general, no problem was found in the model.

Regards,

Vaclav

Hi Vaclav,

I tried tdm on another (better) machine and came to the same result for reverse as you (10 minutes).

But that was not the main problem in this topic. I send you a second reversed model with some adaptions (users,permissions,triggers,domain). Using convert wizzard to convert it to other dbs fails in that way, that it seems to hang. After hours it did not finish. This is on different machines and for different dbs.

Converting hangs for following db: postgres 8.1 8.4 and oracle 11

I just tested for mssql2008 and it succeeds!!!

Any idea ?

Regards,
Reiner.

Hi Reiner,

I tested the conversion on 2.00GHz Laptop with 2GB memory and the result was OK. Of course, the better hardware the faster performance, but in general it looks like there might be something on your machines what slows down the performance.

Regards,

Vaclav

Hallo Vaclav,

first of all, thank you very much that you take the time to help me analyzing that problem. At this moment, this topic is very important for us, as we soonest want to come to a decission whether we can use TOAD as our standard database modeler.
As i mentioned before, the functionality of TOAD is great.

Problems we have is the performance of reverse, but which is accepteable as it is not a daily work.

Actually not solved is the problem of converting our model to other supported target dbms. After starting the convert wizzard (option “convert all” is set and “comment out database specific …” is not set) it comes to the state to display the statisitics.
After then we start the converter process with the result, that the process freezes after some minutes. On the weekend we started such a converter process which did not finish even after a day. To eliminate problems of OS and hardware, we tested it several times on nearly 5 different, clean systems. Each system with at least 2GByte RAM, no antivirus software. no firewalls, no other unneeded processes, no LAN.
The result is always the same, the process freezes. On one machine it came (once) to an application exception, a screenshot will be attached to the mail.

I would be pleased if you could test the converting process (from ORA 10g to postgres 8.4) for our TDM model, which i will provide you separately by mail.

Regards,
Reiner

Hi Reiner,

my pleasure :slight_smile:

Re your model: I tried to convert your Oracle 10g model to PostgreSQL 8.4 several times. The first time it took some time (I went for lunch) but the second and other attempts were successfully finished in less then 2 minutes - I tried both Sync&Convert wizard as well as Simple model conversion (File | Sync & Convert | Simple Model Conversion).

I’d like to ask you to send me convertor Log. In Sync & Convert Wizard (File | Sync & Convert | Sync & Convert Wizard) in step Settings enable checkbox Log Progress to File.

To find out where the log is stored please click menu Settings | Options and in section Paths see Sync & Convert Log Path value.

Again, please send it to modeling@quest.com. Thank you.

Regards,

Vaclav

Hi Reiner,

one more question: can you try to reverse engineer physically existing database and then do the conversion to PostgreSQL 8.4 please? We can test models but there still might be something unique what our internal tests might not find.

Regards,

Vaclav

Hallo Vaclav,

It is unbelieveable. At this moment we wanted to supply you with the log files from the converter.To start the converter for the model, we had to enter the new trial code for full licensed tdm, as the old one expired and the normal trial will only suppport 25 entites. As we started converter we were surprised, that it realy finished for the first time and it takes just 1-2 minutes. So we tried it on all the other test machines where the converter also failed the times before.

What can i say: doing same procedure as described above, the converter succeeded.
Do you have any idea for that behaviour ?

Nevertheless, we will go on with further testing, but will have always a look on this subject.

Again, thank you very much for your great support.

Regards,
Reiner

Hello Reiner,

thank you for the info. New activation key should not affect TDM performace at all. This is really strange…

Of course, I am glad TDM works fine now and in case you need our help do not hesitate to contact us via this community.

BTW: new beta version with support for PostgreSQL 9, MySQL 5.5 and new Gallery feature was released today.

Regards,

Vaclav