I've got a dbms_scheduler-Job running in Oracle 10.2.0.
When I change the system date back to yesterday, the job will wait for one day to continue its work. The reason for this is that next_run_date does not change.
This does not happen regularly, but sometimes someone decides to change the system date without thinking or even knowing about oracle jobs running.
Any suggestions on how to keep my job running with the configured interval (without having it to change manually)?
If you are changing the system date out from underneath Oracle, your hands might be tied. Is there a reason you are regularly changing the system date? If so, perhaps you should create a script for doing so, and have that script also update next_run_date.
Related
We have evening package that is scheduled to run during evening and usually completes by midnight.
We recently migrated our Oracle ODA's to Exadata cloud and did containerization and oracle patching. After our database migration it stopped the next day. Then as a solution I asked DBA team to gather stale stats and it worked the next day. After that it worked fine for rest of the days. Last week we did Oracle upgrade to latest version available, it again stopped the next day then I asked DBA team to gather stale stats, but it didn't effect, now it is running inconsistently, one day it errored out stating temp tablespace issue, our DBA team increased the space, after that it completed next day but taking 12 hours to complete instead of 5. For two days it ran but struck at one point without erroring out, therefore summary is sometimes it is completing and other times it gets struck without erroring out. Then we have to kill the struck session before next one starts in the evening.
I checked with DBA team to look into it, they don't see any issues from their end. Please let me know what else can be the reason for that slowness and inconsistent behavior.
Note: There was no change made in definition of the package.
Any feedback or recommendations are greatly appreciated.
Thanks,
Khush11
In my environment we are using Windows 10 Pro version for analytical applications. Sometimes unexplainedly time and date was going to back date.
We have changed the cmos battery, but after half a week of the analysis the date and time got changed again.
This type of issue may lead to data integrity issues.
Any suggestion on this is appreciated.
It may be, that Windows 10 updates the time and does not know where it is. It may then apply a different time zone.
I would turn off automatic date changes in the settings first and then see if this is the issue.
There is software that synchronizes the time with an atomic clock. This would probably be better if you rely on the time and have an internet connection available.
I am working on a cloud file sync application and an issue that comes up for users is the local time on the users computer being wrong. I use timestamps for tracking changes on each file to check which file is newer, but when someone's computer time is set to say 2005 or even an hour earlier or ahead of the right time and they make changes without being connected to the internet, when they then sync at a later date the time stamp for each file is wrong and overrides the very data they are trying to save.
Getting a timestamp from a time server like nist.gov can only happen when a user is connected to the internet, but if changes are made when the user is offline there is no way to get the right time. I was thinking about putting a counter to track changes to files in addition to a timestamp, but that doesnt work because multiple changes mess that up.
I have a simulator application which writes some enrypted data into a text file. The information that it writes also has the timestamp (which the application picks from system time) along with it which I can not see. I have automated this whole task of sending random data from application to the text file but I want that the records must be written with some time interval in between.
For this I can either put delay in my automation script or I can change the system time every time a new record is inserted.
If I adopt the second approach i.e. I programatically change the system time very frequently (about once in every second) would it cause any harmful effect on the Windows system on which I am running this application ? Would any other critical system processes get affected by it ? Is this approach advisable ?
The best option here is just going to be putting in a delay in the automation script. I can't think of any problems that would arise from changing the system clock every second, but it's best just to let that be handled by the CMOS and any time syncing instead of setting it to change every second.
Changing the System Time might solve your problem, but at the same time it might have adverse affects on time dependent other applications sharing the same System. For example, the automatic antivirus signature updates are time dependent and might get impacted by explicitly changing the System Time or an automatic System Time adjustment for day light saving might get triggered at an inappropriate time. Keeping this issue in mind, the best bet would be to ensure that your application runs on an isolated environment i.e. ensure that other time dependent applications are not present in the same system and also to ensure that auto updates are kept off.
Changing the system time requires administrative privileges, so users of your application will be unable to run it as ordinary users.
I saw this question in a forum about how an application can be developed that can keep track of the installation date and show trial period expired after 30 days of usage. The only constraint is not to use the external storage of any kind.
Question: How to achieve this?
Thanks
Bala
--Edit
I think its easy to figure out the place to insert a question work. Anyway, I will write the question clearly. "external storage" means don't use any kind of storage like file, registry, network or anything. You only have your program.
Use the file-modified date of the file containing the program as the installation date.
I like Doug Currie's idea of the file-modification date. But if the application is downloaded from the web, every night at midnight it gets relinked with new initialized data containing the new expiration date. Then any binary downloaded that day expires on the date given.
If you like, sign the date with a private key so it can't be hacked. Include a public key in the app and decrypt the date. If not correctly signed, hasta la vista, baby.
I don't know if this is possible, as most work I've done has been with embedded systems in which I don't even need to touch the operating system. But would the following be possible?
When compiling your program, leave some extra space at the end (say, 8 bytes), all set to 0. When your application is run, it fetches those bytes and if they're all 0, replaces them with the current time (That's the part I'm not sure about. Does the OS let you do that? If not, there might be some work-arounds using multiple processes.), otherwise, if the time difference is greater than 30 days, it notifies the user that the trial period has ended.
Of course, that method would be vulnerable to resetting the system clock.
If you can't use any external storage at all (not even config files or anything like that), you would need to code it into the app itself so the app's main method (or some method) checks if the current date is less than some expiration date. Part of your installer could actually compile that code on the fly and then it would be set to the installation date. This could be easily defeated by reinstalling the app, but then again, it's not realistic to have no external storage either.
I think the only way to do this generally would be to have your application spawn something off in a separate process that would continue to run and keep track of the date/time even if the main application were closed. When it was restarted, it would then connect to the running process to see if the trial period had expired.
Of course, this would only work if the computer was never restarted and the user never hunted down your spawned process and killed it, which is pretty unlikely. If your application does not do anthing IO-related (file system, registry, something on the network etc.), then a simple restart will wipe away anything that you've done.
So, to summarize: it's not really possible.