Many thanks to all for once again helping an up and coming DBA troubleshoot. As it turns out comparing the parameter file for everything especially sort_area_size. With this information, i was able to point everyone away from Oracle and to what I originally thought was the problem. The throughput to the SAN. amazing that once they (sys admins, of which i used to be) called in support to the vendor, they were able to reset the HBA et. al. and ZOOM. I may be only a DBA, and still learning, but I do have some experience??? Thanks again... Experts willing to share is why I like this forum! On 11/22/05, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> wrote: > > Maybe one database is in archivelog mode and other is not, or one has a > faster I/O system? Are you creating it with NOLOGGING? You might also want > to try speeding it up by creating it in PARALLEL. > > > > -----Original Message----- > *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto: > oracle-l-bounce@xxxxxxxxxxxxx]*On Behalf Of *Bryan Wells > *Sent:* Tuesday, November 22, 2005 11:49 AM > *To:* Oracle-L > *Subject:* Creating index problems > > Hi... we are having issues trying to create indexes from a remote > location. we have access to the console and are running the create index on > the server, but it takes 40+ minutes to create. BTW... this table is 1Tb. > however, when performing the same operation at another location, same > configuration as before, the index only takes 10min. what am i missing? > both of these servers are SAN attached. the indexes are being created on > the SAN. > > > > -- > > Bryan S Wells (Perpetually Stumped) > Database Administrator > bunjibry@xxxxxxxxx > > > Privileged/Confidential Information may be contained in this message or > attachments hereto. Please advise immediately if you or your employer do not > consent to Internet email for messages of this kind. Opinions, conclusions > and other information in this message that do not relate to the official > business of this company shall be understood as neither given nor endorsed > by it. > -- Bryan S Wells Database Administrator bunjibry@xxxxxxxxx