I'm facing a very complex situation with my software databases on a specific server. This is the second time this problem happend on this server.
Basically while user where working on the system, with no apparently reason, all the data from three user databases where lost.
The 3 databases where put on a previuos state from 1.5 month ago where all the databases changes made to this databases are lost, yes LOST! I had to restore a backup for all the databases but the data from passed two dates after the last backup where lost. The first time this happend, was with SQL Server Express 2008. Now happends on SQL Server 2008 R2 Standard.
I suspect a hardware / OS (Hard drive, RAM, etc) problem with the server itself, but no other data where lost (data files, etc) on SQL Server data.
The only lead i have to discover what happend is the Sql Server LOG, where i see some strange entrys:
1) All the log previous to 06/08/2015 11:55 (the exact moment where the problem apear) is lost.
2) An error during decryption, which don't know what it means.
3) A "Recovery complete" message
4) After that I see on the log constant message from CHECKDB over my users database (a lot of them) wich no one execute.
Does anyone have any idea of what could be hapenning here?
Is this a Hardware issue like I suspect?
Thanks!
Related
I have a system in which data is written constantly. It works on MySQL, I also have a second system that runs on SQL Server and uses some parameters from the first base.
Question: how is it possible (is this even possible) to constantly transfer values from one base (MySQL) to another (SQL Server)? The option to switch to one base is not an option. As I understand it, it will be necessary to write a program for example in Delphi which will transfer values from the other database to another.
You have a number of options.
SQL Server can access another database using ODBC, so you could setup SQL server to obtain the information it needs directly from tables that are held in MySQL.
MySQL supports replication using log files, so you could configure MySQL replication (which does not have to be on all tables) to write relevant transactions to a log file. You would then need to process that log file (which you could do in (almost) real time as the standard MySQL replication does) to identify what needs to be written to the MS SQL Server. Typically this would produce a set of statements to be run against the MS SQL server. You have any number of languages you could use to process the log file and issue the updates.
You could have a scheduled task that reads the required parameters from MySQL and posts it to MS SQL, but this would leave a period of time where the two may not be in sync. Given that you may have an issue with parsing log files and posting the updates you may still want to implement this as a fall back if you are processing log files.
If the SQL Server and the MySQL server are on the same network the external tables method is likely to be simplest and lowest maintenance, but depending on the amount of data involved you may find the overhead of the external connection and queries could affect the overall performace of the queries made against the MS SQL Server.
I need to synchronize a table that is held in my local SQL Server 2008 database with one on my remote PHPMyAdmin database. This can be one way as only the local database will have changes made to it. The sync doesn't need to be instant, but ideally would be able to happen on a schedule (e.g. every 10 minutes).
I've read about possibly using a script for this but I can't find anywhere that shows how to do this. What would be the best way to go about doing this?
Edit: The question here is the along the same lines but the answers don't make much sense to me.
I migrated my classic asp site from IIS6 to a much powerful server with Windows Server 2008 R2 and IIS7.5, but it actually runs even slower.
Every simple call to the MSAccess database is taking forever. Many times the request is dropped because of Session timeout (120 seconds).
Any idea what can cause the problem and how to solve it?
Thank You.
Before blaming Access and moving to SQL Server Express or another database, you need to make sure you know where the slowdown occurs.
From what you are motioning, it looks like at least some of the queries don't even work (IIS times out after 120s).
Access databases, especially if they are accessed locally by a handful of concurrent users, are fast.
Moving to another database may or may not solve the problem, but it will be probably be a lot more work than solving your issue with your current Access database.
That said, if your website needs to server lots of concurrent users (say more than 50 at a time) you may need to look into moving to a full database server like MySQL, SQL Server Express or PostgreSQL for instance.
A few things to make sure you double check:
Corrupted database. Make sure you use Compact and Repair regularly as a regular maintenance measure (make a backup first).
Incorrect filesystem rights.
Make sure the your IIS process has read/write rights to the folder where the database is located so that it is able to create the lock file (.ldb or .laccdb depending on whether you are using .mdb or the new .accdb database format).
A related issue is that the IIS process must be able to create temporary files in the temporary folder, for instance %SystemDrive%\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp.
Bad queries. Open the database with Access and run the queries to check how long they really take and if they return any errors.
If there are data integrity issues, it could be that the query returns unexpected results that could have strange side-effect to the code in your asp page.
Check your IIS logs for errors. Also check the OS Event Log.
Make sure there are no other errors that could incorrectly cause the behaviour.
Make sure you profile your asp code to find out exactly which queries and parts of your code are slow and which are fine.
Once you have solved your issues. Improve performance by keeping the database open to avoid the lock file being create/deleted all the time (this can have a huge impact on performance).
A good reference with more detailed information on some of the topics above: Using Classic ASP with Microsoft Access Databases on IIS
I have read a few/lots of things on this but they don't seem to help much.
I have an App (it's called "TieUp" but that is irrelevant) I run it manually daily to collate data from several locations.
It is using as sources:
A) Data from a remote SOAP source and loaded into an in-memory TClientDataset via an XMLtransform setup.
B) CSV files downloaded daily and loaded into an in-memory TClientDataset
C) A Mysql Database on the same computer as the program (it's a restored backup of the live source)
D) A remote MS-SQL (SQLServer 2008) database
E) A Mysql Database on a remote server
Data is only read from sources A, B, C and D
Data source E is updated with the consolidated data.
There are between 800 to 2000 records daily so the datasets are not vast although the target (E) has grown to around 150,000 and increasing daily.
I can normally run this all happily and everything works as expected if a little slowly because of all the individual remote lookups to the MS-SQL system) but some days it really screws up and the error is always "Catastrophic Failure!".
The failure does not occur during any particular phase or operation that I can see. The steps are:
1) Get the SOAP(A) data first.
2) Tie in with CSV/In Memory data(B).
3) Lookup References data on Sources C and D to collate
4) Write the consolidated data to source E
After reading in the data into the in memory datasets every thing is In TClientDatasets accesses via DatasetProviders linked to TSQLQueries (they all on the same servers currently but I did it that way to keep some flexibility in future where it might goes true three tier). All queries are contained within the SQLQuery components as they are actually quite simple - it's just a matter of tying things together.
I am using completely standard components from Delphi 2009 Enterprise. All updates and database update packs have been applied. Each data source has its own DataModule these are auto created at startup
There is obviously quite a lot of data access going on here but when it crashes (with catastrophic failure) It gets stuck, completely stuck. Windows can't end the task from the normal "TieUp has stopped working" I have to go to the process and kill it.
There is so much going on and as this only happens once a week or so I really don't know where to start looking.
The reasons for asking the question is twofold: 1) is that I am trying to eliminate any manual stuff and fully automate it, but I can't rely on it if if bombs every week or so. 2) if it happens in the update phase to E - I have to manually delete the new records for the day and start again as I do not have (or haven't written yet) a mechanism to restart from a random point and I would still have to query the DB manually to establish that point for certain.
My next step is to install Delphi on another computer and always run it under the debugger until I can catch it, if it does not freeze first. But that introduces yet another different network connection (instead of the local host one).
So: "Is there a definite answer?" or what is the most likely offending component/connection? Where is the favoured place to start looking?
Thanks in advance...
MS SQL Server 2008 Standard, ShadowProtect Server Edition 4.0.0.5885 --
On Friday, our client discovered that records were missing from the database. I discovered that the Thursday night SQL backup contained all the missing records. User error is ruled out for multiple reasons.
All missing records fall within an 8-day range
The date range began 22 days before Friday and ended 14 days before Friday
All adds and all changes made during the 8-day range are missing from 14 separate tables
All missing records are present in the Thursday 11pm backup
The application logs show no unusual incidents as far as I can see.
I find nothing unusual in the Applications list in the MS SQL Server Event Viewer.
We are running ShadowProtect Server to make image backups of the 2 server drives every hour. The same sort of incident occurred 4 months ago.
ShadowProtect runs an hourly backup of the database.
One theory is that the ShadowProtect Server 4 disk image software, which runs hourly differential backups, somehow caused the data loss during its 9:00 am Friday backup. I am not aware of any other activity. other than normal user accesses, between the normal 11 pm Thursday database backup and the discovery of missing records on Friday.
Thank you for you help. As you can imagine, the client is very concerned.
If you want to know what is deleting the records or when they got deleted, the database should have audit tables set up that include the usernames and dates of changes. Then you can look at the audit logs to see when reords were deleted and by whom or what process. All databases that contain business critical information should have auditing. Unfortunately, after the event has happened is too late to find out who did it this time through auditing. You might be able to find someone third party product to look through the transaction logs and at least might find out what time the deletes happened if not who. You also should be doing transaction log backups every 15 minutes or so.
I'm not familar with the ShadowProtect server, but the missing data sounds exactly like a script was run (and cacade delete was turned on) and seems unlikely to be the ShadowProtect server. If it was interfering, I would expect a more random kind of change that one that can easily be done by a sql query. Do you allow direct access to your tables? You could have someone trying to harm the data or hide fradulent activities. Threats to the data are not always from outside sources or applications that would be in the event log. Who has access to the delete the data in the database on production? I would suspect a disgruntled employee.
We never did find out the cause of the lost records. We reinstalled the database in another MS SQL Server instance, upgraded the database to a new release, and migrated the data from the old database to the new one. That seems to have fixed the issue.
I had similar issue on VM. The error was was pointing to the database but SQL Server wasn't actually running. For some unknown reason SQL Server has stopped. It seems that VM was restarted and the service didn't start automatically.
After starting the service with Windows Administrative Tools, server was back on and the database was there