I can't get logged into the new improved metalink...
Steve Howard
error message that comes flying in from the top right corner of the
screen, getting bigger every millisecond, makes it all worthwhile! I
start giggling when I see it, like a child on Christmas morning.
"A server connection error occurred. You cannot continue Please try
again later."
I have been getting this since yesterday morning. Yeah, this new
system is freakin' great :(
bdbafh
The integration with SSO has been amazing as well.
I had a separate OTN account from my Metalink account.
The OTN account lacked any CSIs.
Integration meant that the real account was disabled and the bogus
account won.
The real account administered multiple CSIs. Well, it used to.
Its not like I'm attempting to push out critical patch updates, open
service requests, check avail for MS Windows 7, etc.
So the bogus account waits for the real account to grant it access,
yet the real account can't login.
Deadlock detected. Rolllback.
There is no rollback.
There is no undo.
It will be interesting to see how large this FAIL gets.
I'm guessing that it will be "epoch".
-bdbafh
justalowlydba
Wow. Have to say this is great. Have not logged into metalink in a
while and just when I need it. Go figure.
I also had a separate OTN account that was not linked to and CSI
numbers.
Is there a solution for this problem as I would like to get this
resolved?
Any luck other than a just wait as see approach?
Gerard H. Pille
>
> Any luck other than a just wait as see approach?
A great time to switch to PostgreSQL
Mladen Gogala
> Is there a solution for this problem as I would like to get this
> resolved?
There is no solution which doesn't include the use of firearms.
Palooka
> On Thu, 12 Nov 2009 11:50:25 -0800, justalowlydba wrote:
>
>
>> Is there a solution for this problem as I would like to get this
>> resolved?
>
> There is no solution which doesn't include the use of firearms.
>
>
>
Palooka
Mladen Gogala
Interesting comment. I am currently being involved in a project which
strives to replace one Oracle database with a PostgreSQL equivalent. Have
you had any experiences with that? PostgreSQL user group in my town
doesn't really exist and there are many rumors circulating around. I don't
know where are you located, but if you are within 15 miles of the Times
Square, we can meet and have a cup of coffee.
Mladen Gogala
Palooka
Palooka
Tim X
> On 12/11/09 21:14, Mladen Gogala wrote:
>> On Thu, 12 Nov 2009 11:50:25 -0800, justalowlydba wrote:
>>
>>
>>> Is there a solution for this problem as I would like to get this
>>> resolved?
>>
>> There is no solution which doesn't include the use of firearms.
>
Personally, I prefer knives - its more personal!
>
>>
>>
> Like Gerard, I am looking at PostgreSQL. Seems easy as pie so far.
>
PostgresSQL is pretty good. I've moved a couple of fairly simple apps
from Oracle to PostgresSQL and it has been fairly straight
forward. However, I've only been using the basic postgresSQL, not the
'special' one that is specifically aimed at being an Oracle replacement
(I believe you can get it with support etc). I also know there are some
Oracle compatibility 'plugins', but I've not used them either.
On the whole, I've found no really difficult to resolve issues and I
find postgresSQL magnitudes better than MySQL, which IMO is only good
for web counters and basic bit bucket style database apps, which I tend
to avoid where possible.
I have yet to test some of the more 'enterprise' oriented aspects of
postgresSQL, but am hoping to get the opportunity soon. At this sage,
I'm still trying to convince people that while postgresSQL is not a
simple drop in replacement, there are applications which will do fine
using it. On the other hand, I'm more skeptical regarding any
application that demands really high throughput with large data
sets. The real problem is convincing management that maintaining two DB
engines and using each when appropriate may actually provide a better
and cheaper solution than a 'use Oracle for everything' attidue that
currently prevails.
What I'd really like to try is a mid sized app that has quite high
inserts/updates along with the need for fast queries. I've found MySQL
pretty woeful in this regard. Fro the little experience I've had so far
with postgresSQL, you do need to be more across locking issues. I also
find the available tools for analysis and identifying possible tuning
strategies a little limited, though to be honest, I've not really needed
them. Its more the desire to have a good feel for what is going on and
that will probably come with time.
I also find the support for using different scripting languages pretty
interesting, though I've not yet determined what the trade-offs are with
the different optons available. What I really do like is that it is a
more complete, in the sense of what I'm use to, RDMS. I was constantly
frustrated with MySQL's inability to do things which I've grown
accustomed to being what you would find in a RDBMS.
Tim
--
tcross (at) rapttech dot com dot au
joel garry
>
> I have yet to test some of the more 'enterprise' oriented aspects of
> postgresSQL, but am hoping to get the opportunity soon. At this sage,
> I'm still trying to convince people that while postgresSQL is not a
> simple drop in replacement, there are applications which will do fine
> using it. On the other hand, I'm more skeptical regarding any
> application that demands really high throughput with large data
> sets. The real problem is convincing management that maintaining two DB
> engines and using each when appropriate may actually provide a better
> and cheaper solution than a 'use Oracle for everything' attidue that
> currently prevails.
>
As someone who spent a lot of years dealing with multiple db engines,
I must say, this "when appropriate" idea breaks down way too soon.
Eventually, people either start going the db-blind bit-bucket route,
or one becomes the stepchild. "Better and cheaper" is one of those
things that can be misapplied to a set of system life cycles.
Ironically, this was one of the reasons I went whole-hog towards
Oracle - only to become more valuable to places that were adding
Oracle to a mix of engines.
jg
--
@home.com is bogus.
http://www.signonsandiego.com/news/2009/nov/12/orchid-award-goes-to-tiny-eatery-onion-to-condo/
Mladen Gogala
I've been working on PostgreSQL quite a bit for approximately 3 weeks now
and it's not quite that easy. There are no database links, there are no
distributed transactions or synonyms. Syntax of the PLPGSQL is quite
similar to the syntax of PL/SQL minus everything that starts with "DBMS_".
Partitioning is done in a very similar way to what is was on Oracle7: one
creates separate partition tables and then creates a rule or a trigger
which handles the insert.
Also, there is nothing like RAC, one has to scale horizontally and use
shared-nothing architecture. I was successful with setting up backup and
recovery and with doing replication using Slony-I. You are not the first
person to mention Postgres and I have been quite busy with working on the
PostgreSQL pilot. So, if there are people interested in exchanging
experiences about transition from Oracle --> Postgres, please contact me
at gogala...@gmail.com
Palooka
I understand right, it doesn't even support foreign key constraints.
No referential integrity, then. If I just wanted a bit bucket, I might
just as well store the data in flat text files.
Palooka
The Boss
Your 5-minute review must have been a couple of years ago, because MySQL
supports foreign key constraints and referntial integrity for at least 4
years (with the InnoDB engine), see for instance this article:
http://articles.techrepublic.com.com/5100-10878_11-6035435.html
I wouldn't use MySQL for critical apps either, but for a non-critical
intranet portal it isn't that bad.
--
Jeroen
Palooka
check out PostgreSQL.
Palooka
Tim X
> On Nov 12, 11:08 pm, Tim X <t...@nospam.dev.null> wrote:
>
>>
>> I have yet to test some of the more 'enterprise' oriented aspects of
>> postgresSQL, but am hoping to get the opportunity soon. At this sage,
>> I'm still trying to convince people that while postgresSQL is not a
>> simple drop in replacement, there are applications which will do fine
>> using it. On the other hand, I'm more skeptical regarding any
>> application that demands really high throughput with large data
>> sets. The real problem is convincing management that maintaining two DB
>> engines and using each when appropriate may actually provide a better
>> and cheaper solution than a 'use Oracle for everything' attidue that
>> currently prevails.
>>
>
> As someone who spent a lot of years dealing with multiple db engines,
> I must say, this "when appropriate" idea breaks down way too soon.
> Eventually, people either start going the db-blind bit-bucket route,
> or one becomes the stepchild. "Better and cheaper" is one of those
> things that can be misapplied to a set of system life cycles.
>
I agree you need to be careful and you probably need to define som
eclear criteria regarding when to use one or the other and yes, you do
need to be careful that one doesn't become the 'poor
stepchild'. However, the reality for us right now is that Oracle for
everything is just not working. Part (a big part) of the problem is lack
of funding for skilled developers with good Oracle experience and part
of the problem is a lack of DBA resources.
To some extent, the problem is made worse because som eof the apps that
are currently using Oracle are already viewed/treated by the DBAs as
being insignificant or irrelevant compared to the 'important'
systems. The reality is that these smaller applications are actually
just as critical. So, we already have poor stepchildren, but its the
database apps rather than the engine. Combine this with a lack of DBA
resources and the result is we cannot get crucial upgrades, improves and
fixes done in a timely manner.
On the other hand, the couple of systems we now have running on
postgresSQL are doing really well. The reduced complexity has meant that
our Unix admins are able to administer the system quite adequately. This
has taken som eload off the Oracle DBAs while also providing developers
and clients with better responsiveness.
How it pans out in the long term only time wil tell.
> Ironically, this was one of the reasons I went whole-hog towards
> Oracle - only to become more valuable to places that were adding
> Oracle to a mix of engines.
>
In a similar vain, I've developed using Oracle for quite some time
because I thought it was the best engine out there, was going to be
around for a long time and would provide good opportunities.
I'm a little less confident now and think its probably even more
important, from a developer perspective, to stay across a wider range of
technologies and not become too specialised or focused on just a small
segment.
Tim X
I think it can do foreign key constraints, but this depends on the
storage engine you configure. This is one of the tricky aspects of
MySQL. It supports a couple of different storage engines which have
quite different characteristics. Generally, the default engine is the
one that shows really fast queries. However, it uses table locks for
inserts/updates, so as soon as you add those to the mix, performance
falls right off. If you want more of the 'normal' sor tof RDBMS
facilities, you need to go with other storage engines, but then its a
whole different set of trade-offs.
Apart from referencial integrity issues, I've also found MySQL a pain
with respect to SQL, especially for things like sub-queries etc. Stored
procedures, while supported can be a pain to implement as well. I've
also run into a number of clients with problems arising from currupted
databases. Admittedly, not for a while because I've been focused on
Oracle, but before moving to Oracle, data curruption was a real
problem.
Mladen Gogala
> I wouldn't use MySQL for critical apps either, but for a non-critical
> intranet portal it isn't that bad.
I used MySQL for the DW layer, something similar to TimesTen. MySQL has
"STORAGE=MEMORY" option, which allows me to store the tables in memory.
Oracle did the heaving crunching, with the full table scans and group by
expressions and the results were loaded into a MySQL database. The end
users were given the ODBC driver which they used from Excel to produce
all kinds of nice graphics. They were happy as clams.