Periodic db restarts

[DaPi]

Hi guys,

Thanks for your input. My reaction was "what a complete load of bollocks!" - unless UNIX has learned something from Windoze - and I certainly agree about flushing buffers being a bad thing.

I'm having trouble with the idea that stop & start can break something. I'm talking about shutdown/startup, not rebooting or power cycling. Power off/on can produce the electro/mechanical shocks that will break something. But I'm not happy with the car or light-bulb analogy for shutdown/startup. Sorry if I've misread you Slim.

If shutdown/startup fails, then you have a problem somewhere. Isn't it better to find out about this problem under controled conditions, than to have it bite you when you aren't looking?

[davey23uk]

Originally posted by DaPi
Hi guys,

Thanks for your input. My reaction was "what a complete load of bollocks!" - unless UNIX has learned something from Windoze - and I certainly agree about flushing buffers being a bad thing.

I'm having trouble with the idea that stop & start can break something. I'm talking about shutdown/startup, not rebooting or power cycling. Power off/on can produce the electro/mechanical shocks that will break something. But I'm not happy with the car or light-bulb analogy for shutdown/startup. Sorry if I've misread you Slim.

If shutdown/startup fails, then you have a problem somewhere. Isn't it better to find out about this problem under controled conditions, than to have it bite you when you aren't looking?

yeah but the trouble is it is typically unattended, with no-one around to fix it, what if someone changed a parameter which only takes effect on a reboot. You could be hosed all for the sake of doing something you dont need to do

[slimdave]

Originally posted by DaPi
I'm having trouble with the idea that stop & start can break something. I'm talking about shutdown/startup, not rebooting or power cycling. Power off/on can produce the electro/mechanical shocks that will break something. But I'm not happy with the car or light-bulb analogy for shutdown/startup. Sorry if I've misread you Slim.

If shutdown/startup fails, then you have a problem somewhere. Isn't it better to find out about this problem under controled conditions, than to have it bite you when you aren't looking?

Well, things happen at stop and start that don't happen at other times. Dependencies get broken, permissions get changed etc., and the problem only manifests itself when you try to start the database. It's not an exact analogy, more like some kind of general "law of nature" that things break like this.

Yes, if shutdown/startup fail then it is better to find out about it under controlled conditions, but a nightly process is not that kind of condition -- it's when the people expected to fix it are asleep/bleary eyed, and when they have maybe six hours to fix it (possibly trying to enlist the support of o/s, hardware, and Oracle support to boot -- pun-intended) before the working day begins.

To my mind it's better to avoid the shutdown/startup cycle unless neccessary.

[Alchemy]

Are you saying that shutting down a database could cause a database to be unrecoverable?

Not at all gandolf989. I may have ran everything together in that post, apologies. I was running the explaination given to me outloud.

You know, after re-reading I see where I said that. It was not my intention to state that. Truth is I'm still not sure about that aspect.

I understand how flushing the cache will require what was previously in there to have to put back in, and in that process user operations will be slow until the user operations recycle.

I understand what davey23uk and slimdave are saying about how "unexpected" things can happen then makes a mess of the situation. I think that is the crux of their posts.

[reydp]

Originally posted by marist89
Insert favorite MCSE joke here

Haven't you hear that 8 years old from India is an MCSE already?
check this link:

an 8 years old MCSE kid

All kidding aside, taken completely out of context, this statement is absurd. However, if your instance was crashing every 26 hours because of memory leaks, this might be a semi-reasonable suggestion.

With all seriousness too, the new post(ORA-600)that I have made seems to lead to a memory leaks(buffer cache) issues. This is also what ORACLE SUPPORT claims right now.
I used to do C and C++ programming before and as we all know the mother source of Oracle RDBMS is C++. Though I am not aware how is it evolve now, have they slowly migrate there codes to java like codes I don't know. But here what I have experienced, no matter how good the C/C++ programmers was even to resolve memory like meticulously destroying the objects that they create(explicitly), there's still a possibility that the program could produce memory leaks because the other objects(classes) that they reuse either from C++(like MFCs) or third party objects(DLLs) can be the one who can cause the memory leaks. Unlike what JAVA claims now, all the objects that you have created within your program will be implicitly destroyed upon existing the program.

So I believe it's still necessary to refresh the DB, but for sure not on daily basis.

[slimdave]

Originally posted by reydp
So I believe it's still necessary to refresh the DB, but for sure not on daily basis.

If there's an identified problem in a particular environment, and re-starting the instance once a week is what it takes to workaround it, then no problem -- but for general advice, "re-start the db every 24 hours" sucks.

[gandolf989]

Originally posted by reydp
So I believe it's still necessary to refresh the DB, but for sure not on daily basis.

At a previous job we had a database running on a Sun Cluster for several years. We did all of the maintenance, which wasn't very much. It was backed up, but otherwise, it just ran. After two years of uptime, there was a network issue and it cutover without any intervention. After two years the database was running fine and obviously did not need to be refreshed, other than the network issue.

[reydp]

Originally posted by slimdave
If there's an identified problem in a particular environment, and re-starting the instance once a week is what it takes to workaround it, then no problem -- but for general advice, "re-start the db every 24 hours" sucks.

Totally agree with this Dave.

[reydp]

Originally posted by gandolf989
At a previous job we had a database running on a Sun Cluster for several years. We did all of the maintenance, which wasn't very much. It was backed up, but otherwise, it just ran. After two years of uptime, there was a network issue and it cutover without any intervention. After two years the database was running fine and obviously did not need to be refreshed, other than the network issue.

From my understanding CLUSTERING means sharing resource between two or more servers including MEMORY which serves the same database. So, if one server failed to allocate its own resource to address a process, then it couldn't failed because there will be the other clustered server to catch that process so to speak. Pls feel free to correct me if i'm wrong.