migrating database.

Our database is over a gig now and we would like to migrate it to SQL Server. Does anyone have any experience with going from the MSACCESS to SQL and have you experienced any problems in doing so... also what versions of SQL are actually supported?

 

I don't have any experience in this particular area unfortunately, but just out of curiousity how big is your deployment and how many queries/s is the console reporting? Even with 600 clients on a server that's been up for 4 years my DB is only 13MB, but I admit I am fairly aggressive at purging scan logs (last 10) and client events (last 25) and anything else after 6 months.

 

I have to keep my logs for PCI compliance. 3 months on client and 12 months on server.

 

I understand that, but which logs? Scans and threat logs I would understand, but clients generate a lot of noise about signature updates and sending statistical information. Do you need a full year of signature update confirmations as well? You could cut down on a fair bit of that by setting a policy to disable reporting of statistical information on your clients.

And just to be clear, are we talking about the size of your database (era.mdb) or your datastore (storage directory)?

 

Unfortunately I haven't migrated from the Access DB to SQL. However I do have our server using a SQL Server DB for the back end. I'm pushing the data to a separate SQL Server running SQL Server 2008 64-bit and it seems to work fine. We have about 200 clients and in the last 6 months the DB is about 70mb's.

However, as Smacky mentioned the storage area. Even though the DB is on SQL, the storage area is still used to store the ScanLog Details, ThreatSense Data, Packages, etc. The ScanLog Data etc. is not stored in the SQL Database. The only thing stored in the SQL database are the rows of data you can see in the ERA console.

 

I have over 3000 clients and up until about 3 weeks ago we were logging every time we sent statistical information(we are no longer doing that). However I have over 1300 event logs in the last 24 hours which consist mainly of every time a machine updated to the latest av database which I have been told I need to keep.

 

I recommend putting in a call to Eset support. You are correct that the internal database will likely not be able to cope with the amount of load you are placing on it.

If you are set on doing it yourself, I would go about it by setting up a new RAS that is attached on to fresh database and check out how it has set up its tables and such. Then pull a copy of your era.mdb (maybe one from tape that isn't so big) and check out the table structure. Odds are everything will match up and you could be able to take down the RAS service on both server, import the .mdb in to your live MSSSQL server, copy over all the directories in your "Eset Remote Administrator\Server\" directory to the new server, power down the old server, then configure the new server to take control of the old one's hostname/IP and reboot. If it all goes to hell then you have the fall-back position of powering up the old server since its configuration hasn't changed.

Alternatively, you could simply do a fresh install using a MS SQL database, create a CNAME record to redirect clients from the old server to your new one, power down the old server and keep it around for 12 months so you can keep PCI compliance and scrap it after that.

 

Smacky,
I just really appreciate all the help and knowledge you have given me over the last few weeks on these forums. You should definately be on the payroll...


Unfortunately, I did contact support with various questions and receive the response below. I actually did the conversion and everything seems to be working fine. I did lose some data a couple weeks ago when I upgraded the ERA server version and can't seem to get any help from ESET resolving that issue either... I have a backup of the old DB so I think I might be able to recover only the data that didn't transfer.... on the plus side I have finally received confirmation about changing the log settings so I am going to be able to clean up my DB.

An ESET Customer Care Representative has updated this case with the following information:

Hello, so we don't have more support for SQL then the following.

To help resolve your issue, please click or copy/paste the following Knowledgebase article into your web browser:
------------------------------------------------------------------------------
http://kb.eset.com/esetkb/index?page=content&id=SOLN963
------------------------------------------------------------------------------
If this resolves your issue or if you need further assistance, please let us know by replying to this email.

Thank you for using ESET security products,
ESET Customer Care
------------------------------------------------------------------------------
ESET Knowledgebase | articles | videos | manuals | support
http://kb.eset.com

 

I'm glad you were able to get it sorted out. While I love Eset for their product, I find their business support lacking. While this isn't a deal breaker in my environment, if you are dealing with PCI compliance it might be. Case in point: there has been an on-going issue with clients reporting in weeks or months old threat events that myself and others have seen. Support's response? Dump the database and start fresh. That is a bad enough response when I have clients that only report in intermittently, for someone maintaining PCI compliance it would be disastrous.

Not that I know any other company that would give better support. Symantec and CA were far worse, but frankly when your business customers are hitting issues like this I expect instructions on how to enable debug logs for them to pick through, not the same "Wipe and Reinstall" KB they have sent me a half-dozen times already. Anyway, food for thought.