-1

SQL beginner here. I am a r/o user of a very large oracle 12 db with many tables that have to be combined to build the desired output. (using custom sql in tableau to build report) basic structure is;

Select 
  cus_fields  
  cus_loc_fields
  ent_fields
  cir_fields
from (
  Select
    cus_loc_fields
    from ( 
      Select
        cus_fields  
        cus_loc_fields
      from cus 
      inner join (
         (select
            cus_loc_fields
            from cust_loc
            union all
            cus_loc_del_fields
            from_cust_loc_del
         ) cus_loc
      ) on cus.cusnum = cus_loc.cusnum
    ) cus_loc
) cus_loc

left join (
  (select
     ent_fields
     from 
       (select
          ent_fields
        from ent
        union all
        select
          ent_del_fields
        from ent_del
     ) ent 
  ) ent
-
  full outer join (
     (select
        cir_fields
        from
          (select
             cir_fields
           from cir
           union all
           select
             cir_del_fields
           from cir_del
        ) cir
     ) cir
  ) on ( ent.name = cir.name
         and ent.shname = cir.shname )
-
) on cus_loc.name = ent.name
  or cus_loc.name = cir.name

without the cir outer join, the tableau filter query to gather the list of customer names is in the seconds. Once I add the outer join in, the tableau filter query to gather the customer names takes hours. Everything works if i put a known customer name in the filter but still takes much longer.

furthermore I still need to left join 4 more tables to the cir table and 1 more left join to the ent table. In essence it becomes unusable

obviously i need some sort of an index, but how can i do this as a r/o user

GwaiTsi
  • 1
  • 1
  • See this [*previous question*](https://stackoverflow.com/q/51713528/1260204). It is very well written because it includes a self contained table structure (**DDL**), insert **data** to populate those tables, and the **query** attempt to retrieve the data against the tables as well as **expected output**. In other words a complete [mcve]. *You* providing these same artifacts *in your question* would go a long way into others being able to help you with your question. You could also use http://rextester.com/ for your DDL and data. – Igor Aug 29 '23 at 09:26
  • @Igor it works as expected i.e. data output is correct, it is performance issue. I believe the server builds a list of each table before performing the joins right. this would be many millions of rows. the cir and ent fields create exponential rows for each cus_loc. data is also confidential and volumes, so i don't see the data being the issue, but rather how i apply indexing as a r/o user – GwaiTsi Aug 29 '23 at 09:31
  • 1
    The reason why that data (from 1st comment) is necessary is because there might be a much more efficient way to construct your query and get the same output. There is no way for anyone to do that or figure that out until you provide that data. If you feel strongly about not providing it then I wish you luck because it is not likely you will get an answer on this forum as what can be provided will be very limited. – Igor Aug 29 '23 at 09:38
  • 1
    @GwaiTsi, performance tuning is not a trivial exercise, and it often does not have anything to do with indexes. I seriously doubt an index would be useful or desirable for a query like this - there isn't any filtering predicate that would indicate you're after a tiny percentage of rows in these tables. More likely you have a many-to-many join or are scanning serially without parallelism, or are writing excessively to temp for a sort operation, or are using an index you shouldn't be.. it could be many things. Only examining wait data would determine exactly where the problem is. Ask your DBA. – Paul W Aug 29 '23 at 10:55
  • @PaulW Reporting is typically based on one or a small selection of cus, which can have thousands of loc and each loc can have thousands of cir and ent. ideally the query should process only data for the selected cus, but i don't think it works like that right? If correct, that would mean processing millions of rows in each table before joining the data – GwaiTsi Aug 30 '23 at 10:10
  • Your query does not show any such selection. If there is more to your real query than you are showing above, folks aren't going to be able to help much. Please provide the actual query, with any predicate filter(s) that you expect. Somewhere there should be a bind variable on some customer identifier or attribute of some kind or you have no selection. – Paul W Aug 30 '23 at 10:42
  • @PaulW when you use tableau and add a filter via the app, it run a query and builds a list of all the current values that you select from. – GwaiTsi Aug 31 '23 at 11:14
  • Then you aren't showing us the actual query. Are you saying your actual selects from this as a view and adds additional predicates (it's own WHERE clause)? If so, we'd need to so that full query, not just the view code. That would be a radically different animal than the view code by itself. – Paul W Aug 31 '23 at 18:36

0 Answers0