Hi Connor, is there are a best practice guide about editioning views ?? especially about triggers (not speaking about cross editions triggers). What triggers must stay in the table and what in te view?? besides all triggers ar editinables. Thanks a lot for your time
I have a use case where I need to change the data type of an existing column in many tables from numeric to varchar2. I suspect EBR could help in this situation to avoid hours of downtime, but after a little research threw up my hands and walked away from it.
Check out column mapping - that should let you achieve this. I'll look at doing a video on it
2 หลายเดือนก่อน
Totally agree - it has been pitched very badly. I am having a lot of trouble trying to convince a costumer that would save thousands of euros by allowing us to use EBR.
I worked with a (online gambling) customer where downtime was equivalent to 1 million dollar loss per minute. EBR sort of paid for itself pretty quickly :-)
2 หลายเดือนก่อน
@@DatabaseDude unfortunately I am not that involved with business that I can have those numbers - I've heard between 50K and 200K/hour of downtime and there are 30+ installations... Client is afraid of ORA-00600 errors that they have had in the past (we have a structure where a most of the data is stored in varray columns).
@@DatabaseDude ah ok luckily that’s the only issue we seem to not have, we only allow adding nullable columns and not allow to rely on column order - because as a software vendor avoiding the whole EBR process (at least for non custom changes) is the best EBR usage :)
Thanks Connor. Would it be possible to get a video with a short demo of EBR in the future ?
Will add to an Office Hours session (which will subsequently become a video)
Hi Connor, is there are a best practice guide about editioning views ?? especially about triggers (not speaking about cross editions triggers). What triggers must stay in the table and what in te view?? besides all triggers ar editinables. Thanks a lot for your time
Once you go with an edition view, you never, ever touch the table again. Its "sacred", so triggers go onto the edition view
I have a use case where I need to change the data type of an existing column in many tables from numeric to varchar2. I suspect EBR could help in this situation to avoid hours of downtime, but after a little research threw up my hands and walked away from it.
Check out column mapping - that should let you achieve this. I'll look at doing a video on it
Totally agree - it has been pitched very badly. I am having a lot of trouble trying to convince a costumer that would save thousands of euros by allowing us to use EBR.
Saving “thousands” is probably not worth the additional setup and testing costs :)
@@berndeckenfels thousands per update
I worked with a (online gambling) customer where downtime was equivalent to 1 million dollar loss per minute. EBR sort of paid for itself pretty quickly :-)
@@DatabaseDude unfortunately I am not that involved with business that I can have those numbers - I've heard between 50K and 200K/hour of downtime and there are 30+ installations...
Client is afraid of ORA-00600 errors that they have had in the past (we have a structure where a most of the data is stored in varray columns).
Why do you need EBR to add a column? Ist that about non-null?
Because I've lost count of the number of times people put "select *" in their code base :-)
@@DatabaseDude ah ok luckily that’s the only issue we seem to not have, we only allow adding nullable columns and not allow to rely on column order - because as a software vendor avoiding the whole EBR process (at least for non custom changes) is the best EBR usage :)