After Restore: Could not open transactional storage. Microsoft.Isam.Esent.Interop.EsentInvalidPathException: Invalid file path

[legion]

Current Setup

Raven: 2.0.2330 on Windows 2008 R2

New Setup

Raven: 3.0.3660 on Windows 2012 R2 

Steps taken: 

1. Backup database from current server

2. From online restore through Raven Studio on New server

Restore is successful, but when I try to load the restored database in 3.0.3660 on the new server. I get this nasty guy:

Ran this a second time around with the Defrag option checked. Same issue. 

Any ideas ?

System.AggregateException: One or more errors occurred. ---> System.InvalidOperationException: Could not open transactional storage: C:\RavenDB\30\Databases\HarmonyPROD\Data ---> Microsoft.Isam.Esent.Interop.EsentInvalidPathException: Invalid file path
   at Raven.Storage.Esent.TransactionalStorage.Initialize(IUuidGenerator uuidGenerator, OrderedPartCollection`1 documentCodecs)
   --- End of inner exception stack trace ---
   at Raven.Storage.Esent.TransactionalStorage.Initialize(IUuidGenerator uuidGenerator, OrderedPartCollection`1 documentCodecs)
   at Raven.Database.DocumentDatabase..ctor(InMemoryRavenConfiguration configuration, TransportState recievedTransportState)
   at Raven.Database.Server.Tenancy.DatabasesLandlord.<>c__DisplayClassb.<TryGetOrCreateResourceStore>b__8()
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Task.Wait(TimeSpan timeout)
   at Raven.Database.Server.Controllers.RavenDbApiController.SetupRequestToProperDatabase(RequestManager rm)
---> (Inner Exception #0) System.InvalidOperationException: Could not open transactional storage: C:\RavenDB\30\Databases\HarmonyPROD\Data ---> Microsoft.Isam.Esent.Interop.EsentInvalidPathException: Invalid file path
   at Raven.Storage.Esent.TransactionalStorage.Initialize(IUuidGenerator uuidGenerator, OrderedPartCollection`1 documentCodecs)
   --- End of inner exception stack trace ---
   at Raven.Storage.Esent.TransactionalStorage.Initialize(IUuidGenerator uuidGenerator, OrderedPartCollection`1 documentCodecs)
   at Raven.Database.DocumentDatabase..ctor(InMemoryRavenConfiguration configuration, TransportState recievedTransportState)
   at Raven.Database.Server.Tenancy.DatabasesLandlord.<>c__DisplayClassb.<TryGetOrCreateResourceStore>b__8()
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()<---

[legion]

Aha! On closer inspection, namely the event log, the error indicates that An attempt to create the folder "e:\" failed with system error 3 (0x00000003): "The system cannot find the path specified. ".  The create folder operation will fail with error -1023 (0xfffffc01).

Got me thinking, in our current 2.0 environment, the Data is one one drive, and the Indexes are on another, E: drive.

I suppose that is the issue. 

Question, now is what to do about it? 

In our new 3.0 environment, I'd like to consolidate the disks, as it really hasn't been all that useful. 

How can we do that? Take a backup of a DB that was using different drives for data and indexes, and then restore to to a DB with only one disk ?

[legion]

Ok, another aha! moment.

I started over, restored the DB. 

I then went to the system DB, modified the database document and removed these two lines:

        "Raven/Esent/LogsPath": "e:\\ravandb2\\mydb\\logs",

        "Raven/IndexStoragePath": "f:\\ravandb2\\mydb\\indexes"

I tried loading the DB again in Studio, and it looks like its working. Because there is now a Data.Compact file in the DB directory. 

RavenDB Team,

1. It would be nice if we could modify the Data, Logs, IndexStoragePath whilst setting up the restore process

2. While the DB is being opened, and its being Compacted, it would be nice if we could see the Compact progress. Or at minimum a message saying that it is being Compacted. 

2a. All we get is the in the Title of browser window, it says: "Update in Progress". Easy to miss, and doesn't display progress.

Realize that #2 doesn't matter if I chose the Defrag option during Restore. 

[Chris Marisic]

For years I've been saying RavenDB needs a professional quality back up and restore tool the operates both with a GUI and optionally headless.

[Oren Eini (Ayende Rahien)]

1) That is a good idea:

http://issues.hibernatingrhinos.com/issue/RavenDB-3473

2) When? During the first load? During the restore? Manually compaction?

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[legion]

While restoring a DB, if you select the Defrag option, there is ample feedback being provided in the "log" view. So you're good there. 

However, if you don't select the Defrag option, RavenDB will attempt to Defrag/Compact the DB after you click on it in the Studio as it tries to load it. 

The only thing the Studio says at this point is "Loading database". It should say, "Database is being compacted because XYZ. Step 1 of N."

So yes, during first load.

[legion]

Chris, 

I agree.

While it the ops story has a come a long way since v10, it still requires a bit more work. 

I can't turn RavenDB over to ops in my company. It still lacks the polish. I tried it, but quickly had to take back the responsibility of it. A good example of this is the sometimes cryptic (or none at all) error messages combined with a StackTrace. While nice for some devs, unnecessary and maybe even intimidating for ops. They don't know what to do with that. (you maybe able to turn that off, i don't know).

But I still like it, and haven't looked back. And look forward to every new release.  

[Oren Eini (Ayende Rahien)]

The problem with hiding information like that is that when you actually need to troubleshoot things, it is important to have all information available.

For most things, you can just look at the first line and be done with, but for the complex stuff, this is crucial.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--

[legion]

Oh I agree, it is invaluable. But to who? Since the DBs are managed by ops, they don't write code and thus can't decipher the information. Most developers that will work with the DB, won't be able to either. It is useful for a certain segment of devs and the RavenDB team.

In the spirit of catering to the 80%, hide the information unless requested. Via some sort of "Advanced/Detailed/Debug information tab".

Similar to attached. Big difference? No not really. But it gives a nice element of polish to it. 

[Oren Eini (Ayende Rahien)]

That is what we do.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

[legion]

Understood. I'm glad that is now there in 3.0 because our current production instances are running 2.0 which had the attached. 

[Oren Eini (Ayende Rahien)]

Oh, yeah, that is a separate issue and is related to brain dead SL error handling.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Sat, May 16, 2015 at 11:00 PM, legion <hassan...@gmail.com> wrote:

Understood. I'm glad that is now there in 3.0 because our current production instances are running 2.0 which had the attached.