 | |
server time reset
comp.databases.oracle.server comp.databases.oracle.server
 |
| | Thread Tools | Display Modes |
#21
 
| |||
| |||
|
Re: server time reset -
06-17-2008
, 12:23 PM
|
On Tue, 17 Jun 2008 06:21:46 -0700, fitzjarr... (AT) cox (DOT) net wrote: On Jun 17, 7:52*am, Ben <benal... (AT) yahoo (DOT) com> wrote: 10.2.0.2 EE aix 5.2 we have a server that somehow got behind in time by 5 minutes. I mentioned it to the sysadmin and next thing I knew she had changed the time on the server ahead 5 minutes. First thought was panic and what is going to happen to the database now. Nothing seemed to happen. We haven't rebooted the server yet or restarted the database that was running on that server yet. I could see some really disasterous scenarios if the time was pushed back, but essentially we skipped about 5 minutes of the day. Anyone ever have this happen before or have any comments on things they could see coming down the line when the database restarts? This happens, twice yearly, when Daylight Savings Time commences and when Standard Time returns, and this involves an hour difference either way, and I've yet to experience any issues with Oracle. *Yes, during the above-mentioned scenario you can duplicate an hour which could make it difficult to perform a PITR based upon clock time, but you still have the SCN as a reference point, and that doesn't change when the clock does. I really see no issue here. David Fitzjarrell Especially because the database coordination mechanisms depend on the SCN, not on the time. I have the experience of recovering a database up to the point right after the DST switch. Nothing happened. Nothing at all. --http://mgogala.freehostia.com- Hide quoted text - - Show quoted text - |
comparison to DST, makes perfect sense.
#22
| |||
| |||
|
|
On Tue, 17 Jun 2008 06:21:46 -0700, fitzjarr... (AT) cox (DOT) net wrote: On Jun 17, 7:52*am, Ben <benal... (AT) yahoo (DOT) com> wrote: 10.2.0.2 EE aix 5.2 we have a server that somehow got behind in time by 5 minutes. I mentioned it to the sysadmin and next thing I knew she had changed the time on the server ahead 5 minutes. First thought was panic and what is going to happen to the database now. Nothing seemed to happen. We haven't rebooted the server yet or restarted the database that was running on that server yet. I could see some really disasterous scenarios if the time was pushed back, but essentially we skipped about 5 minutes of the day. Anyone ever have this happen before or have any comments on things they could see coming down the line when the database restarts? This happens, twice yearly, when Daylight Savings Time commences and when Standard Time returns, and this involves an hour difference either way, and I've yet to experience any issues with Oracle. *Yes, during the above-mentioned scenario you can duplicate an hour which could make it difficult to perform a PITR based upon clock time, but you still have the SCN as a reference point, and that doesn't change when the clock does. I really see no issue here. David Fitzjarrell Especially because the database coordination mechanisms depend on the SCN, not on the time. I have the experience of recovering a database up to the point right after the DST switch. Nothing happened. Nothing at all. --http://mgogala.freehostia.com- Hide quoted text - - Show quoted text - |
comparison to DST, makes perfect sense.
#23
| |||
| |||
|
|
On Jun 17, 7:52*am, Ben <benal... (AT) yahoo (DOT) com> wrote: 10.2.0.2 EE aix 5.2 we have a server that somehow got behind in time by 5 minutes. I mentioned it to the sysadmin and next thing I knew she had changed the time on the server ahead 5 minutes. First thought was panic and what is going to happen to the database now. Nothing seemed to happen. |
case.
Quote:
|
This happens, twice yearly, when Daylight Savings Time commences and when Standard Time returns, and this involves an hour difference either way, and I've yet to experience any issues with Oracle. Yes, during the above-mentioned scenario you can duplicate an hour which could make it difficult to perform a PITR based upon clock time, but you still have the SCN as a reference point, and that doesn't change when the clock does. |
timestamps in some TZ (and DST) independent format. F.ex. the system
clock on Unix machines is a linear second counter from 1.1.1970. To
achieve DST changes, only the time display offset is changed, not the
system clock itself. The difference in the situation described by Ben
was that the system clock was abruptly bumped 5 minutes forward.
One recommendation for Ben is to check with the sysadmin that the
Oracle server is running NTP time synchronization (and is being
served by stable time servers). Most probably it isn't, and
taking NTP in use would avoid this kind of problem in the future.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
#24
| |||
| |||
|
|
On Jun 17, 7:52*am, Ben <benal... (AT) yahoo (DOT) com> wrote: 10.2.0.2 EE aix 5.2 we have a server that somehow got behind in time by 5 minutes. I mentioned it to the sysadmin and next thing I knew she had changed the time on the server ahead 5 minutes. First thought was panic and what is going to happen to the database now. Nothing seemed to happen. |
case.
Quote:
|
This happens, twice yearly, when Daylight Savings Time commences and when Standard Time returns, and this involves an hour difference either way, and I've yet to experience any issues with Oracle. Yes, during the above-mentioned scenario you can duplicate an hour which could make it difficult to perform a PITR based upon clock time, but you still have the SCN as a reference point, and that doesn't change when the clock does. |
timestamps in some TZ (and DST) independent format. F.ex. the system
clock on Unix machines is a linear second counter from 1.1.1970. To
achieve DST changes, only the time display offset is changed, not the
system clock itself. The difference in the situation described by Ben
was that the system clock was abruptly bumped 5 minutes forward.
One recommendation for Ben is to check with the sysadmin that the
Oracle server is running NTP time synchronization (and is being
served by stable time servers). Most probably it isn't, and
taking NTP in use would avoid this kind of problem in the future.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
#25
| |||
| |||
|
|
On Jun 17, 7:52*am, Ben <benal... (AT) yahoo (DOT) com> wrote: 10.2.0.2 EE aix 5.2 we have a server that somehow got behind in time by 5 minutes. I mentioned it to the sysadmin and next thing I knew she had changed the time on the server ahead 5 minutes. First thought was panic and what is going to happen to the database now. Nothing seemed to happen. |
case.
Quote:
|
This happens, twice yearly, when Daylight Savings Time commences and when Standard Time returns, and this involves an hour difference either way, and I've yet to experience any issues with Oracle. Yes, during the above-mentioned scenario you can duplicate an hour which could make it difficult to perform a PITR based upon clock time, but you still have the SCN as a reference point, and that doesn't change when the clock does. |
timestamps in some TZ (and DST) independent format. F.ex. the system
clock on Unix machines is a linear second counter from 1.1.1970. To
achieve DST changes, only the time display offset is changed, not the
system clock itself. The difference in the situation described by Ben
was that the system clock was abruptly bumped 5 minutes forward.
One recommendation for Ben is to check with the sysadmin that the
Oracle server is running NTP time synchronization (and is being
served by stable time servers). Most probably it isn't, and
taking NTP in use would avoid this kind of problem in the future.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
#26
| |||
| |||
|
|
On Jun 17, 7:52*am, Ben <benal... (AT) yahoo (DOT) com> wrote: 10.2.0.2 EE aix 5.2 we have a server that somehow got behind in time by 5 minutes. I mentioned it to the sysadmin and next thing I knew she had changed the time on the server ahead 5 minutes. First thought was panic and what is going to happen to the database now. Nothing seemed to happen. |
case.
Quote:
|
This happens, twice yearly, when Daylight Savings Time commences and when Standard Time returns, and this involves an hour difference either way, and I've yet to experience any issues with Oracle. Yes, during the above-mentioned scenario you can duplicate an hour which could make it difficult to perform a PITR based upon clock time, but you still have the SCN as a reference point, and that doesn't change when the clock does. |
timestamps in some TZ (and DST) independent format. F.ex. the system
clock on Unix machines is a linear second counter from 1.1.1970. To
achieve DST changes, only the time display offset is changed, not the
system clock itself. The difference in the situation described by Ben
was that the system clock was abruptly bumped 5 minutes forward.
One recommendation for Ben is to check with the sysadmin that the
Oracle server is running NTP time synchronization (and is being
served by stable time servers). Most probably it isn't, and
taking NTP in use would avoid this kind of problem in the future.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
#27
| |||
| |||
|
|
On Jun 17, 7:52*am, Ben <benal... (AT) yahoo (DOT) com> wrote: 10.2.0.2 EE aix 5.2 we have a server that somehow got behind in time by 5 minutes. I mentioned it to the sysadmin and next thing I knew she had changed the time on the server ahead 5 minutes. First thought was panic and what is going to happen to the database now. Nothing seemed to happen. |
case.
Quote:
|
This happens, twice yearly, when Daylight Savings Time commences and when Standard Time returns, and this involves an hour difference either way, and I've yet to experience any issues with Oracle. Yes, during the above-mentioned scenario you can duplicate an hour which could make it difficult to perform a PITR based upon clock time, but you still have the SCN as a reference point, and that doesn't change when the clock does. |
timestamps in some TZ (and DST) independent format. F.ex. the system
clock on Unix machines is a linear second counter from 1.1.1970. To
achieve DST changes, only the time display offset is changed, not the
system clock itself. The difference in the situation described by Ben
was that the system clock was abruptly bumped 5 minutes forward.
One recommendation for Ben is to check with the sysadmin that the
Oracle server is running NTP time synchronization (and is being
served by stable time servers). Most probably it isn't, and
taking NTP in use would avoid this kind of problem in the future.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
#28
| |||
| |||
|
|
On Jun 17, 7:52*am, Ben <benal... (AT) yahoo (DOT) com> wrote: 10.2.0.2 EE aix 5.2 we have a server that somehow got behind in time by 5 minutes. I mentioned it to the sysadmin and next thing I knew she had changed the time on the server ahead 5 minutes. First thought was panic and what is going to happen to the database now. Nothing seemed to happen. |
case.
Quote:
|
This happens, twice yearly, when Daylight Savings Time commences and when Standard Time returns, and this involves an hour difference either way, and I've yet to experience any issues with Oracle. Yes, during the above-mentioned scenario you can duplicate an hour which could make it difficult to perform a PITR based upon clock time, but you still have the SCN as a reference point, and that doesn't change when the clock does. |
timestamps in some TZ (and DST) independent format. F.ex. the system
clock on Unix machines is a linear second counter from 1.1.1970. To
achieve DST changes, only the time display offset is changed, not the
system clock itself. The difference in the situation described by Ben
was that the system clock was abruptly bumped 5 minutes forward.
One recommendation for Ben is to check with the sysadmin that the
Oracle server is running NTP time synchronization (and is being
served by stable time servers). Most probably it isn't, and
taking NTP in use would avoid this kind of problem in the future.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
#29
| |||
| |||
|
|
On Jun 17, 7:52*am, Ben <benal... (AT) yahoo (DOT) com> wrote: 10.2.0.2 EE aix 5.2 we have a server that somehow got behind in time by 5 minutes. I mentioned it to the sysadmin and next thing I knew she had changed the time on the server ahead 5 minutes. First thought was panic and what is going to happen to the database now. Nothing seemed to happen. |
case.
Quote:
|
This happens, twice yearly, when Daylight Savings Time commences and when Standard Time returns, and this involves an hour difference either way, and I've yet to experience any issues with Oracle. Yes, during the above-mentioned scenario you can duplicate an hour which could make it difficult to perform a PITR based upon clock time, but you still have the SCN as a reference point, and that doesn't change when the clock does. |
timestamps in some TZ (and DST) independent format. F.ex. the system
clock on Unix machines is a linear second counter from 1.1.1970. To
achieve DST changes, only the time display offset is changed, not the
system clock itself. The difference in the situation described by Ben
was that the system clock was abruptly bumped 5 minutes forward.
One recommendation for Ben is to check with the sysadmin that the
Oracle server is running NTP time synchronization (and is being
served by stable time servers). Most probably it isn't, and
taking NTP in use would avoid this kind of problem in the future.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.