'Unbreakable' marketing strategy irresponsible?

[Keith]

You answer the question.

[url]http://www.geek.com/news/geeknews/2003Jul/gee20030718020880.htm[/url]

[FC]

Could you just stop posting nonsense?
Thanks, I appreciate the effort.

Bye,
Flavio

[J Alex]

"FC" <flavio@tin.it> wrote

> Could you just stop posting nonsense?
> Thanks, I appreciate the effort.
>

The first one was fine (at least I was interested that a popular website was
blaming Oracle for a serious failure), but 5 posts in two days is beyond the
level of troll....

[Niall Litchfield]

"Keith" <nospam@nospam.com> wrote in message
news:vhgep3qcble8e9@news.supernews.com...

> Sir,
> The post is on topic with no profanity. If you are not interested,
> others still may. To tell someone to stop posting news that may help
> someone mitigate serious data loss is simply stupid and irresponsible.

Who has suffered serious data loss? Orbitz hasn't lost a single bit of
comitted customer data. read the links you post.


--
Niall Litchfield
Oracle DBA
Audit Commission UK
*****************************************
Please include version and platform
and SQL where applicable
It makes life easier and increases the
likelihood of a good answer
******************************************

[Keith]

Sent the last post in error, here is the corrected one:

The point is, there is potential of data loss whenever there is the
possibility of an outage. Because they avoided it this time, does not
mean the will next time. Data loss or not, there was financial loss as
stated in the article. In the end, it is the financial loss that is
important. Everything eventually comes down to a financial loss and how
to prevent it.


Keith wrote:

> Yes, I suggest the same.
>
> Regarding the Orbitz outage:
> "Orbitz officials say that the problem was related to the Oracle
> database used to run the site. The outage comes during a period of high
> travel for many Americans, which in turn increased the losses suffered
> by the company as a result of the outage."
>
> [url]http://www.geek.com/news/geeknews/2003Jul/gee20030718020880.htm[/url]
>
> Niall Litchfield wrote:
>

>> Who has suffered serious data loss? Orbitz hasn't lost a single bit of
>> comitted customer data. read the links you post.
>>
>>

>

[Keith]

Hello?? RAC was identified as the problem. RAC was replaced. Site is up
and running. Which of those news links do not point to Oracle as the
problem?

rob wrote:

> So it was the UNIX administrator after all...
> [url]http://www.orbitz.com/App/about/careers/jobs/jobs.jsp?cache=1058561313311&requestId=383[/url]
> ;-)
>
> As others stated, until no evidence is presented what so ever that an oracle
> software bug is to blame, why should you believe this is the case. Where is
> your critical attitude towards the blame storming that is going on at
> Orbitz. Ever heard of cognitive dissonance?
> Please stop posting the same content published on different web-sites, cross
> posting, trolling, posting with a fake email adress.
>
> Rob
>
> "Keith" <nospam@nospam.com> wrote in message
> news:vhge1pd4ue0q93@news.supernews.com...
>

>>You answer the question.
>>
>>[url]http://www.geek.com/news/geeknews/2003Jul/gee20030718020880.htm[/url]
>>

>
>
>

[rob]

> Hello?? RAC was identified as the problem.
Come back when you can present some _facts_ or technical details. Then we
can have a meaningfull discussion.

'nuf said
Rob.

[Hans Forbrich]

Keith wrote:

> You answer the question.
>
> [url]http://www.geek.com/news/geeknews/2003Jul/gee20030718020880.htm[/url]

Keith,

The post IS on topic for cdo.MISC. Please avoid cross posting to the
other groups. Cross-posting is simply rude behaviour by all netiquette
standard.

This has been cross-replied to provide a consistent request all others
--- please respond to Keith's messages ONLY in cdo.misc

Thx
/Hans

[Daniel Morgan]

Niall Litchfield wrote:

> "Keith" <nospam@nospam.com> wrote in message
> news:vhgep3qcble8e9@news.supernews.com...

> > Sir,
> > The post is on topic with no profanity. If you are not interested,
> > others still may. To tell someone to stop posting news that may help
> > someone mitigate serious data loss is simply stupid and irresponsible.

>
> Who has suffered serious data loss? Orbitz hasn't lost a single bit of
> comitted customer data. read the links you post.
>
> --
> Niall Litchfield
> Oracle DBA
> Audit Commission UK
> *****************************************
> Please include version and platform
> and SQL where applicable
> It makes life easier and increases the
> likelihood of a good answer
> ******************************************

I killfiled Keith as he is obviously a troll that couldn't write a SQL
statement if you threatened him with bodily harm ... but it seems from the
responses he is still doing the one thing he is capable of doing ... wasting
bandwidth.

I would suggest that everyone do as I have done ... killfile him / ignore
him. He has nothing of value to contribute. Never has ... likely never will.

Now I've killed the thread too so I'll not be seeing any of this.
--
Daniel Morgan
[url]http://www.outreach.washington.edu/extinfo/certprog/oad/oad_crs.asp[/url]
[email]damorgan@x.washington.edu[/email]
(replace 'x' with a 'u' to reply)

[Orville]

Keith <nospam@nospam.com> wrote in
news:vhgep3qcble8e9@news.supernews.com:

> Sir,
> The post is on topic with no profanity. If you are not interested,
> others still may. To tell someone to stop posting news that may help
> someone mitigate serious data loss is simply stupid and irresponsible.
>
> FC wrote:
>

>> Could you just stop posting nonsense?
>> Thanks, I appreciate the effort.
>>
>> Bye,
>> Flavio
>>

>

That article doesn't mention any data loss.

Here's one that does.

[url]http://groups.google.com/groups?selm=200205081145.37254.mallah%40trade-in[/url]
dia.com

Subject: data loss due to improper handling of postmaster ....
This is the only article in this thread
View: Original Format
Newsgroups: comp.databases.postgresql.admin
Date: 2002-05-07 23:17:53 PST

Hi folks,

this is a long email.
I too experienced a data loss of 11 hrs recently.
i have the most recent postgresql 7.2.1 on RedHat 6.2

but my case was bit different and i feel my wrong handling
of situation was also responsible for it.

I would be grateful if someone could tell me what should have
been done *instead* to prevent the data loss.

as far as i remember the following is the post mortem :

the load average of my database server had reached 5.15 and my website
had become slugglish so i decided to stop the postmaster and start
again, (i dont know it it was a right thing but was inituitive to me)

so i did

# su - postgres
# pg_ctl stop <-- did not work out
it said postmaster could not be stopped.

# pg_ctl stop -m immediate
it said postmaster is stopped ,
but it was wrong ps auxwww still showed some processes running.

# pg_clt -l /var/log/pgsql start
said started successfully (but in reality not )

at this point postmaster is neither dead nor running essentially my live
website was down, so under pressure i decided to reboot the system
and told my ISP to do so.

but even the reboot was not smooth , the unix admin of my isp says
some process does not let the system reboot (and it was postmaster).
so he has to put the machine in power cycle and the machine fscked
in startup.

as a result i too got similar messages as Bojan has given below .
and my website was not connecting to the database.
it used to say "database in recovery mode.... "

then i did "pg_ctl stop" then start but nothing worked out.

since it was my production database i had to restore the database
in minimum time so i used my old backup that was 11 hrs old and
hence a major data loss.

I strongly beleive Postgresql is the best open source database
around and is *safe* unless fiddled in a wrong manner.

But there are problems in using it.

due to The current Lack of inbuilt failover and replication solutions
in postgresql people like me would tend to become desperate because
one cannot keep webserver down for long as a result we take wrong steps.

For mere mortals like me there should be set of guidelines for safe
handling of the server. (DOS' and DON'TS type) to prevent
DATA LOSS.


Also i would like suggestions on how to live with postgresql
with its current limitations of replication ( or failover solutions) and
without data loss.

what i currently do is backup my database with pg_dump but there are
problems with it.

Because of large size of my database pg_dump takes
20-30 mins and the server load increases this means
i cannot do it quite frequently on my production server.
so in worst case i still loose of duration ranging from 1-24 hrs
depending on frequency of pg_dump.
And for many of us even 1Hour of data is *quite* a loss for us.

I would also want comments on usability of USOGRES / RSERV
replication systems with postgres 7.2.1

hoping to get some tips from the intellectuals out here

regds
mallah.


On Tuesday 07 May 2002 07:52 pm, Bojan Belovic wrote:

> My database apparently crashed - don't know how or why. It happend in
> the middle of the night so I wasn't around to troubleshoot it at the
> time. It looks like it died during the scheduled vacuum.
>
> Here's the log that gets generated when I attempt to bring it back up:
>
> postmaster successfully started
> DEBUG: database system shutdown was interrupted at 2002-05-07
> 09:35:35 EDT DEBUG: CheckPoint record at (10, 1531023244)
> DEBUG: Redo record at (10, 1531023244); Undo record at (10,
> 1531022908); Shutdown FALSE
> DEBUG: NextTransactionId: 29939385; NextOid: 9729307
> DEBUG: database system was not properly shut down; automatic recovery
> in progress...
> DEBUG: redo starts at (10, 1531023308)
> DEBUG: ReadRecord: record with zero len at (10, 1575756128)
> DEBUG: redo done at (10, 1575756064)
> FATAL 2: write(logfile 10 seg 93 off 15474688) failed: Success
> /usr/bin/postmaster: Startup proc 1339 exited with status 512 - abort
>
> Any suggestions? What are my options, other than doing a complete
> restore of the DB from a dump (which is not really an option as the
> backup is not as recent as it should be).
>
> Thanks!