Day one was quite interesting! We learnt a lot of staff about tuning approach, I have got confirmation that most of the “WE KNOW THAT, IT HAS ALWAYS BEEN SO” were maybe one day true, but are no longer, for example “separate index and tables”, or, delightfull, “you must periodically reorganise your tables”. I also learnt about DBMS_APPLICATION_INFO, which I may use in my dba-scripts too.
I also feel relaxed that designing a table to be IOT or Hash-Clustered is NOT a dba task, but a developer task. Wow, finally, the dba have to look at the database not at the table structure to gain performance…
In the evening, we had a dinner with my friend Fabrice, my ZKB-collegue Roman, my future ex-lc collegue Marc, a reader of tom blog and mine one called Leo, and also Lutz, who is working for Oracle University, and of course Tom, who enjoyed the fishes 😉
soon day 2, so i have to go to bed right now
“I also feel relaxed that designing a table to be IOT or Hash-Clustered is NOT a dba task, but a developer task.”
I’m not convinced on that. I think a lot depends on what are the perceived roles of DBAs and developers in that particular organisation.
Some places, DBAs do not much more than backups and developers have most of the responsibility for the application/schema. Other places, developers focus on coding, whether in PL/SQL, C, Java…, but the DBAs are in charge of the ‘schema’.
Without question, I think both developers and DBAs need to UNDERSTAND how those work. But I think we need to be flexible on the exact job title of the person(s) with the passwords for creating tables, indexes etc.
Maybe the Developer is best placed to know what is best for a given application, given their intimate knowledge of it, but the DBA is best-placed to know what the options are and how they work.
“Without question, I think both developers and DBAs need to UNDERSTAND how those work. ”
I agree 100%!
well, even if the DBA knows what it is, it is not really a dba task to reorganise a heap table in an iot, the application should be designed as an iot. I will ask more details to Tom today
See the day II post for a clarification….
My point was – OPTIMALLY this is a developer(/dba) job, they should be doing this, they should have the knowledge, they should care enough – but, when they do not, the DBA/developer can be smart enough to use these structures as tuning devices.
Scalability and performance is best designed into an application. Having the DBA come in and tune it in later is second choice…
Optimally, this is the job of the Developer/DBA type – unfortunately, it falls into the job of the DBA/Developer many times – and if you are unlucky enough to just have a DBA or a Developer – you’ll never use them….