Bernhard S
Member³
I think it's really annoying that there's still no fix about the Performance problems with "Compare User Objects" and "Export User Objects in v10. What is your opinion?
Poll about fix of Performance Problem
- Thread starter Bernhard S
- Start date
Hilarion
Member³
There seems to be to few forum readers to make this poll representative. I mean there are many people that use this forum, but most of them come here only if they have a problem and only read what is related to their specific problem (or even only the thread they create for that problem - even if the problem was already reported/discussed in the forum).
For example: Have you seen my thread about error in handling user reports menu? Probably not - no one here cared to try to reproduce the error, even if it's results indicate some memory corruption caused by use of connections pane.
And yes, I did vote in the poll.
For example: Have you seen my thread about error in handling user reports menu? Probably not - no one here cared to try to reproduce the error, even if it's results indicate some memory corruption caused by use of connections pane.
And yes, I did vote in the poll.
Hilarion
Member³
Maybe you already voted (or someone used your account to do that)?
I do not see radio buttons but that's because I already did. That's a shame that this forum does not explicitly show me that I did vote and which option I did choose. Ability to change your vote would also be nice (at least till the poll is closed).
I do not see radio buttons but that's because I already did. That's a shame that this forum does not explicitly show me that I did vote and which option I did choose. Ability to change your vote would also be nice (at least till the poll is closed).
Bernhard S
Member³
Even as the creator of the poll I don't see anything more than you guys. I guess only the admins can help you there.
I'd wish that you could see also how long the poll will still be active. I defined it to last until New Years Eve. I'm not too happy about the low participation. I guess we all have already quite an aversion on doing polls from so many websites getting on your nerves with unsolicited polls. Well, it was worth trying though. I wonder why for so many this issue is not of any higher importance. Are they just not using those features at all?
I'd wish that you could see also how long the poll will still be active. I defined it to last until New Years Eve. I'm not too happy about the low participation. I guess we all have already quite an aversion on doing polls from so many websites getting on your nerves with unsolicited polls. Well, it was worth trying though. I wonder why for so many this issue is not of any higher importance. Are they just not using those features at all?
Hilarion
Member³
That's probably it. I admit I did vote that way for that specific reason: I rarely use that feature.
I can understand your frustration as I also am really annoyed by one of PL/SQL Developer errors that apparently only bothers (or even affects) me and my co-workers - no one on this forum (including Allround Automations staff) bothered to try to confirm (or deny) that the problem is there, when I was able to specify exact way to reproduce it.
OK. I'm doing it again - using someone's thread to mention my problems. I'm sorry. I'll try not to do that again.
I can understand your frustration as I also am really annoyed by one of PL/SQL Developer errors that apparently only bothers (or even affects) me and my co-workers - no one on this forum (including Allround Automations staff) bothered to try to confirm (or deny) that the problem is there, when I was able to specify exact way to reproduce it.
OK. I'm doing it again - using someone's thread to mention my problems. I'm sorry. I'll try not to do that again.
Hilarion
Member³
Every change we do on our DEV DBs is either made as an SQL script files first and then installed to DEV DB or changed in DEV DB directly and immediately exported to SQL script files. Those scripts (organized by application module, object type, etc.) are under source control. When we want to install changes to PROD, we get all changes from source control since last install and append some constant verification scripts to such package (we have an application that does all that and also compiles binaries that have changed too and packages all that for "shipping"; we run it on one of few machines dedicated for only that purpose).
Before installing such package on PROD, we test it on an intermediate local TEST database (one or more for each client DB), which is a copy of PROD (same structure and dictionary data, and a big sample of operational data; it's refreshed on regular basis by importing a dump file made by Oracle Data Pump limited export from PROD DB, not necessarily before/after each install). Usually after that we do a second installation on remote (client) TEST DB (full copy of PROD DB, refreshed also on regular basis), so the client can check the changes by himself.
Yes, sometimes we "loose" some changes, when someone forgets to export from DB, but those are quite rare problems. For such cases we do a limited comparison of structure between DEV and local TEST (comparing only objects which are reported by DB as changed since last install and verifying that those that are changed, are scripted in the package). It does not involve data, so in case of data changes we might miss something. Usually we catch such problem on TEST (local or remote), but sometimes they go to PROD uncaught. Happened twice or thrice in 5 years and fortunately was easy to fix and did not cause major problems for client.
Before installing such package on PROD, we test it on an intermediate local TEST database (one or more for each client DB), which is a copy of PROD (same structure and dictionary data, and a big sample of operational data; it's refreshed on regular basis by importing a dump file made by Oracle Data Pump limited export from PROD DB, not necessarily before/after each install). Usually after that we do a second installation on remote (client) TEST DB (full copy of PROD DB, refreshed also on regular basis), so the client can check the changes by himself.
Yes, sometimes we "loose" some changes, when someone forgets to export from DB, but those are quite rare problems. For such cases we do a limited comparison of structure between DEV and local TEST (comparing only objects which are reported by DB as changed since last install and verifying that those that are changed, are scripted in the package). It does not involve data, so in case of data changes we might miss something. Usually we catch such problem on TEST (local or remote), but sometimes they go to PROD uncaught. Happened twice or thrice in 5 years and fortunately was easy to fix and did not cause major problems for client.
Maxmix
Member³
Many thanks Hilarion for a such detailed description. Serious system, I'd say! But I'm the only one developer, who knows PL/SQL and SQL ;-) here, and so I am seeking for easy ways. One DEV, several PRODs, 0 TESTs, 0 clients willing to test. So I dream about a tool like 'Compare User Objects', but a bit faster and more functional (multi-schema compare and privileges comparison are most wanted features).
Hilarion
Member³
Been there, done that. Being the sole developer with no one else willing to do any testing is real pain in the ass.
You can still benefit from saving everything you do to files. After some time getting used to that routine it stops bothering you and you do not have the need to do DB comparison. This also allows you to do source control (at least for stored PL/SQL) and this way easily tell what was done when, how and why (at least if you comment your check-ins properly) and - if needed - go back to previous versions.
You can still benefit from saving everything you do to files. After some time getting used to that routine it stops bothering you and you do not have the need to do DB comparison. This also allows you to do source control (at least for stored PL/SQL) and this way easily tell what was done when, how and why (at least if you comment your check-ins properly) and - if needed - go back to previous versions.
1. Put system trigger on DDL for the schemas you develop in and save source code into log table.
That way you will have every change stored automatically aka auto VCS.
2. Write a set of scripts to render changelog in a friendly way for easy investigaton.
3. Develop on PROD. (this is optional =) )
That way you will have every change stored automatically aka auto VCS.
2. Write a set of scripts to render changelog in a friendly way for easy investigaton.
3. Develop on PROD. (this is optional =) )
Similar threads
- Discussion
- Discussion
