1 2 Previous Next 20 Replies Latest reply on Apr 24, 2012 2:45 PM by Pleiadian Go to original post
      • 15. Re: SDO_AGGR_UNION very slow
        Paul Dziemiela
        Hi folks,

        Great topic and thanks to Luc for reminding me its been half a decade since I said I would test out the OCI stuff and never did. To make up for that I can submit the ER through my client. Any guidance on how to phrase it? Are we complaining about SDO_AGGR_UNION, SDO_AGGR_SET_UNION or both? If you are shy about posting, feel free to shoot me an email at my first name at my last name dot com or look me up on LinkedIN. With this last name I am easy to find.

        I think once we have a ER established, then we can push posters with issues to climb on board the ER. Dr. Ravada has a point that we have been griping for years but there are no ERs in the system.

        I can make a decent business case as the watershed boundary dataset
        is a critical dataset for my client and various aggregations of the different levels are always needed. My partial solution of cutting topologies for topological aggregation is not workable when the dataset is updated frequently (not to mention topology skills are fairly rare out there).


        • 16. Re: SDO_AGGR_UNION very slow
          Waldecir P. Junior
          Hello friends,

          I opened a SR in oracle support about this problem.

          The oracle customer support is forming an action plan to try solve this problem.
          Already sent a dataset to Oracle and will contribute to this problem is finally solved.

          I'll post here news about the SR.


          • 17. Re: SDO_AGGR_UNION very slow
            Simon Greener

            I am happy to help provide data, SQL or techniques to an ER but I can't initiate one as I have explained before.
            Dr. Ravada has a point that we have been griping for years but there are no ERs in the system.
            Well, why wasn't the process to be followed fully explained on this forum years ago (it may have been but I have been quiet on this forum for years
            only just returning)?

            Additionally, Oracle has known how much we, consultants and users, have been griping about performance and have even agreed with us! Isn't there some
            sort of "internal ER" process?

            However, it seems to me that there MUST have been an ER in the system because, as argued, it is the only way that something can be done to
            solve a problem. So, a customer MUST have raised an ER about SDO_AGGR_UNION performance because the result is what we all know to be the sub-optimal
            implementation of SDO_AGGR_SET_UNION!


            In addition, I find it hard to believe that the Spatial development team's hands were tied so much that they could not do anything about the
            problem without an ER! And, additionally, that every performance improvement made over the years has been done only at the behest of an ER or SR.

            It strikes one not used to Oracle's ways, as being a very "old world" method for developing and extending technology in the Internet age.
            It is not agile, nimble or wholly customer-centric when viewed from a wider definition of what a customer is. For example, I may not be an
            Oracle "customer" in the sense of owning lots of its technology (and paying maintenance), but I am a customer in the sense that my developments,
            ideas and consulting are focused on making the Oracle customer "experience" the best it can be (cf my blog and work on the free GeoRaptor extension,
            SC4O and PL/SQL packages). I have no power to effect any changes except to hassle Oracle Spatial staff from the position of the "un-empowered": I don't
            contribute $$$$ to Oracle's profits: my customers don't use expensive partitioning extensions or Exadata machines. It becomes even more frustrating
            to watch complaints about Union performance solved on the PostGIS forum in dev cycles that make me cry next to the glacial pace of Oracle.

            In short, I believe I am seen as a noisy complainer with no suggestions or solutions. A bit of a joke. I hate standing up in Forums to ask the hard questions
            on behalf of quiescent customers and being a target of ridicule, easily dismissed as a complainer (the thanks from customers afterwards doesn't make up for
            the emotional pain and head-banging frustration that accompanies the question). I hate making postings like this. But I also hate working in Oracle sites in
            Australia seeing Oracle's SDO_GEOMETRY technology not performing at what it could do because of technical limitations one cannot get addressed (what
            Oracle Spatial support in Australia?): and that these performance issues are used by those who do not have Oracle's interests at heart to denigrate and
            then replace (either whole database or just the spatial type) it with (longer-term) inferior solutions.

            So, I finish positively, if anyone wants to raise another ER (as I can't) with my providing input then I would be glad to do so. (Oracle 13g anyone?)

            • 18. Re: SDO_AGGR_UNION very slow
              Paul Dziemiela
              Hi Simon,

              Well, I kind of think we are at the mercy of our Oracle friends as to whether there are or aren't enhancement requests in the system. Such things are not searchable to my knowledge so we plebs can only go by word-of-mouth. For example, lets take my enhancement request from a while back for Spatial to support GML 3.2/3.3. I think its a reasonable request for Oracle to consider. You can search all day long on metalink under "GML","3.2", "OGC" or what-not and never find a whisper of my request. But if you know the magic number, 9788193 - there it is!

              So we need Waldecir to cough up his ER number! :)
              In the meantime if anyone puts in a service request, support should be able to merge them together but I would still like the number.

              By the way I am enjoying the banter on the topic. This group had been getting pretty long-in-the-tooth so the recent uptick in posts is great. Now if only someone could remove that ancient advertisement for the 2011 spatial conference...


              • 19. Re: SDO_AGGR_UNION very slow
                Waldecir P. Junior
                Hi Paul,

                The SR is 3-5583487281.

                Addition, the status was changed to Development Working.


                • 20. Re: SDO_AGGR_UNION very slow
                  I am an Oracle consultant in a company that uses ArcGIS for its spatial tools. I try to avoid ArcGIS as much as possible and will always try a pure pl/sql based solution first. In my purist view, ArcGIS is often slow & messy in its interaction with Oracle...

                  I have to shamefully admit though that ArcGIS' union (dissolve) functionality is far superior to Oracle's sdo_aggr_union (and sdo_aggr_concat_lines). As soon as you try to union more than about 50 geometries, things get extremely slow. Until recently I didn't know about this limitation and I naively tried to union 100.000 rows into one geometry! ArcGIS has no problem with that, but Oracle ( will go down on its knees... I was unable to kill the proces and had to bother our DBA's each time I tried.

                  Must find an Oracle solution... ArcGIS is bad... must find an Oracle solution... ArcGIS is bad... aaarrggh!

                  1 2 Previous Next