Re: Creating index problems

  • From: Bryan Wells <bunjibry@xxxxxxxxx>
  • To: Oracle-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 23 Nov 2005 08:04:30 -0700

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

Other related posts: