Re: how can i eliminate burleson's stuff from google search results? - Burbeson strikes back!
Date: Fri, 22 May 2009 23:14:31 +0200
Message-ID: <4a1715c8$0$190$e4fe514c_at_news.xs4all.nl>
ddf schreef:
> On May 21, 4:40 am, Shakespeare <what..._at_xs4all.nl> wrote:
>> Shakespeare schreef: >> >> >> >> >> >>> spamp..._at_gmail.com schreef: >>>> All, >>>> posts from dba-oracle.com tend to rank relatively high in google >>>> search. >>>> is there some setting I can use to eliminate those from the result >>>> set? >>>> thanks! >>> Just for laughs: a quote from the Burbeson site (20th of May) >>> " Escape the tedium of general Internet searches for information about >>> your Oracle system! >>> Due to popular request, we have now implemented Google site search, a >>> quick way to locate all salient articles on this web site! Take full >>> advantage of the wealth of information provided by our Oracle experts. >>> To find our articles on other web sites, many people simply append >>> “Burleson” to their search strings. With our new site search option, >>> this is no longer necessary. >>> We hope that you find this new feature useful in your quest for expert >>> Oracle information. " >>> Shakespeare >> And for more laughs: this is the way Burb.. finds out whether a database >> user exists: >> >> " Checklist for ORA-01017 errors: >> >> Check that user ID exists >> >> select * from user_tables >> where username = 'fred'; >> >> " >> >> Shakespeare- Hide quoted text - >> >> - Show quoted text -
>
> I looked up the entire checklist old Don provided:
>
> http://www.dba-oracle.com/t_ora_01017.htm
>
> Gee, it's just chock full of errors, like the one posted above and the
> one regarding external authentication:
>
> "If using external authentication (ops$) verify that
> os_authent_prefix=ops$ and remote_os_authent=true your initialization/
> spfile."
>
> The error here is that os_authent_prefix does NOT need to be set to OPS
> $ or ops$ to use external authentication; you can have no prefix
> defined (os_authent_prefix='') and the authentication works as
> expected. And the 'tip' of checking your Oracle parameters:
>
> "Check your environmental parameters ($ORACLE_SID), e.g.:
>
> export ORACLE_SID=TEST
> sqlplus "/nolog"
>
> "
>
> proves what, exactly, except that the ORACLE_SID you set is valid
> (which is also proven by the ORA-01017 error because you had to get to
> the database to know the login/password wasn't valid), but NOT that
> it's valid for the username/password in question:
>
> $ export ORACLE_SID=ying
>
> $ sqlplus /nolog
>
> SQL*Plus: Release 11.1.0.6.0 - Production on Thu May 21 07:28:19 2009
>
> Copyright (c) 1982, 2007, Oracle. All rights reserved.
>
> SQL> connect / as sysdba
> Connected.
> SQL> connect fred/flintstone
> ERROR:
> ORA-01017: invalid username/password; logon denied
>
>
> SQL>
>
> Oh, gee, fred is a user in the flong database ...
>
> $ export ORACLE_SID=flong
>
> $ sqlplus /nolog
>
> SQL*Plus: Release 11.1.0.6.0 - Production on Thu May 21 07:28:19 2009
>
> Copyright (c) 1982, 2007, Oracle. All rights reserved.
>
> SQL> connect / as sysdba
> Connected.
> SQL> connect fred/flintstone
> Connected.
> SQL>
>
> So we know that ying is a valid ORACLE_SID (again, a fact we already
> knew from the initial error) but what good does that do us? And, if
> the ORACLE_SID wasn't valid we wouldn't get an ORA-01017, we'd get a
> TNS protocol error:
David,
sometimes people are not aware what database they connect to, mixing up test databases with development or production databases because they mess up their TNSNAMES.ORA. A TNSPING (and indeed not a sqlplus /nolog) can uncover such mistakes. I have seen plenty examples of this.
Shakespeare
>
> $ export ORACLE_SID=yung
>
> $ sqlplus /nolog
>
> SQL*Plus: Release 11.1.0.6.0 - Production on Thu May 21 07:33:11 2009
>
> Copyright (c) 1982, 2007, Oracle. All rights reserved.
>
> SQL> connect / as sysdba
> ERROR:
> ORA-12560: TNS:protocol adapter error
>
>
> SQL>
>
> so I'm not seeing where that test is of any benefit to troubleshooting
> an "invalid username/password" error.
>
> The step of selecting from user_tables where username = '...' is
> classic, though, and this from "one of the world’s leading Oracle
> experts", according to old Don hisself. To add more humor I found
> this disclaimer on his website:
>
> "Errata? Oracle technology is changing and we strive to update our BC
> Oracle support information. If you find an error or have a suggestion
> for improving our content, we would appreciate your feedback. Just e-
> mail: ... and include the URL for the page."
>
> Apparently the throngs who rely on old Don for Oracle expertise can't
> recognize errors when they see them.
>
> The page has been reported; let's see what they do to correct it.
>
>
>
> David Fitzjarrell
Received on Fri May 22 2009 - 16:14:31 CDT