RE: db file sequential read [WAS:wait event puzzler]

Clarifying:
1 - has been shown to be impossible.
2 - Most people on the list disagree with this. Even if someone wants to try it for testing it won't help you in production.

3 - Was a JOKE!
4 - True.
5 - True.
6 - True.
7 - True. Dangerous advice should always be accompanied by a ton of caveats.
8 - was a JOKE!
9 - good advice. Read The Fine Manual.

Summary - updating the data dictionary directly means that Oracle will not support your database. Unless you're not paying for any support, nothing you do is worth that risk.

Why is the limit 30 characters? It has always been that way. Who decided 30 characters when Oracle was first built? The answer is probably lost in the mists of time. Why is it still 30 characters? I am guessing because changing that size would cause millions of lines of code (Oracle software, third-party software, customer homegrown software) to have to be modified and there is not enough demand for Oracle to make that change.

> -----Original Message-----
> From: Bhaskar Viswanathan [mailto:[EMAIL PROTECTED]
>
> To sum up the suggestions:
>
> 1) You can modify col$.NAME to varchar2(60) and try......
> 2) I do agree with you. But some times we may need go beyond the
> scopes.
> For testing purpose we can do these kind of R&D's.(alterning the
> col.Cname size)
> Nothing wrong in this.
> 3) That is a Very Good Idea...
> We will do away with DDL Stmts will start writing directly into
> the Data Dictionary ...
> 4) Oracle does not support column names that are longer than 30
> characters.
> This is a hard standard and can not be changed.
> 5) Ur not supposed to Update Data Dictionaly Tables Directly ...
> Oracle has A Limit of 30 Chrs and is Hardcoded.. So ReName your
> Columns within 30 Chrs...
> 6) Updating a data dictionary is simply not done. Remember, we're
> the DBA (you will be assimilated) and not fun loving students
> who can play with their alma mater's equipment.
> Updating the data dictionary directly would cause the database
> to lose support from
> Oracle Corp. and the perpetrator would be liable.
> 7) telling him to do a Update on COL$... He Ends up Doing that in
> his Production Database..
> And he is going to be in a HOT soup....
> 8) Write a compress / decompress algorithm that will take your
> 200-character table names from
> the application and pass them to the database as <= 30
> characters; then uncompress them from
> the database back to the application.
> 9) references to DB naming conventions.
>
> I would want to go with the majority. "Do not Do it!!!!!!".
>
> But then, the problem is like, I cannot afford to shorten
> names as there
> are a lot of other problems which crops up.
> Though right now, thatz what we do and which is what I am
> attempting to
> avoid.
> Ofcourse, the suggestion to have an algo. translate the names
> is a good
> one, which is thought of and is the current
> Decision.
>
> Whew!, if oralce supports more than 30 characters for column
> names, life
> would be easier.
>
> Can somebody explain in brief, why this is being restricted to 30
> characters?

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jacques Kilchoer
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).