Solved: Re: Missing extractors from SAN Drive - Qlik Community

Sean_BI · ‎2020-06-10

Dear Qv experts,

It is really strange that qvw (extractors) are missing from local drive (SAN) on windows after windows server restart.

Lost about 90% of my files that are mounted as root folder in QMC. All the extractor's were running fine, and disappeared suddenly.

Qlikview version 12.3

Kindly, assist at the earliest.

Rgds,

Sean.

Miguel_Angel_Baeyens · ‎2020-06-16

That error code requires deeper analysis. I have seen some cases where that issue is due to size of files versus resources of the server (i.e: undersized QlikView server) or network too slow between the QlikView cluster and the storage servers.

The script which is being executed will play a role here too: if there are too many JOINs or otherwise resource intensive operations such as synthetic keys or string functions, the reload time will take longer and also the files to be stored (and causing files to be bigger).

Regardless the permissions, if a file is big enough and takes too long to be copied from the QlikView server, where the reload happens, to the storage server where it is stored, and all the way back from the storage server to the QlikView server when a user accesses the application for the first time, there could be locks while other processes such as antivirus scanners or even QlikView are trying to access that file to open, causing deadlocks and eventually, file corruption.

For example, two reloads of very big files too close in time: by the time the second reload starts, the first has not been able to write the file and complete the save.

Also, if there are intermediate network elements such as router, balancers or proxies between QlikView and the storage servers, that could increase the writing and reading times, with several concurrent users in the meantime opening a file that has not been saved yet.

Finally, while it is technically possible to use a mapped drive, it would be much easier, in my opinion, to use UNC paths instead, so the shared resource will have the same naming conventions regardless which account is accessing it (developers or the service accounts) requiring less maintenance effort and removing one potential issue.

View solution in original post

Miguel_Angel_Baeyens · ‎2020-06-11

How does the QMC look like? Have there been any changes to the Qlik service account which is the one that must access those shared folders? Can you or any other user see those files when accessing the folder via filesystem, not when loading from Qlik?

Sean_BI · ‎2020-06-11

Thank you for your quick response.

There was no change to service account privileges.

The windows server has many event occurs related to event 55 and 98 (NTFS), where the drives / volumes is corrupted. Requires chkdsk on f: and e: drives respectively.

I am unsure why this happened, but i could not recover the missing files placed on these volumes.

Thank you!

Sean.

Miguel_Angel_Baeyens · ‎2020-06-12

Sounds like an issue IT should be informed and take care of.

If the volume has become corrupt for whatever reason (file locking, specially if there are big files in those volumes?) that should be fixed / restored using OS or third party tools.

Sean_BI · ‎2020-06-13

Thank you!

The windows platform team perfomed CHKDSK and error scanning on the san volume. To some extent, the files are recovered, but they appars to be corrupted as well.

Yes, there are couple of big dashboard that may have caused the corruption, but unsure this was.

The qlikview is in two node cluster, and i use \\ipaddress\e$\qv\ and create a mapped drive to node2. Do this qualify to some extent for corruption. May be i need to use windows based file shareing like create a root directory and do windows fileshare to other node.

Thank you!

Sean.

Miguel_Angel_Baeyens · ‎2020-06-16

Using UNC paths will not affect either positively or negatively to performance or corruption, it's yet another way to access files.

However, I'm a bit confused now: are you using a non-Windows storage system? If so, that could be the reason, QlikView does not support NAS (https://support.qlik.com/articles/000002481) unless such NAS is a native Windows server with a filesystem exposed.

Using IPs or fully qualified domain names will depend on your IT policies, I would definitely tend to use the latter.

Sean_BI · ‎2020-06-16

Thank you for your response.

1) The e$ is a SAN drive and is with WINDOWS BASED file system. This drive is used as root directory for QMC where qvw's, qvd are located.

2) NAS drive is also used, but only for storage (backup) and replication from DC to DR. QVWS, qvds are not build / executed on NAS as qlik doen not support.

So, in principle, the volume (E:\) mounted on server is windows based based only.

Rgds,

Sean.

Sean_BI · ‎2020-06-16

The corruption of qvd's located on SAN (Windows based NTFS drive) keep occurring despite windows platform team performed chckdisk, error scanning etc..etc.. Windows event log indicates nfts issues, where as it the permission on NTFS are not changed. Some of the backed up qvd's are getting refreshed, where as other qvds filed with -128 error code in qlikview documents logs.

Rgds,

Sean.

Miguel_Angel_Baeyens · ‎2020-06-16

That error code requires deeper analysis. I have seen some cases where that issue is due to size of files versus resources of the server (i.e: undersized QlikView server) or network too slow between the QlikView cluster and the storage servers.

The script which is being executed will play a role here too: if there are too many JOINs or otherwise resource intensive operations such as synthetic keys or string functions, the reload time will take longer and also the files to be stored (and causing files to be bigger).

Regardless the permissions, if a file is big enough and takes too long to be copied from the QlikView server, where the reload happens, to the storage server where it is stored, and all the way back from the storage server to the QlikView server when a user accesses the application for the first time, there could be locks while other processes such as antivirus scanners or even QlikView are trying to access that file to open, causing deadlocks and eventually, file corruption.

For example, two reloads of very big files too close in time: by the time the second reload starts, the first has not been able to write the file and complete the save.

Also, if there are intermediate network elements such as router, balancers or proxies between QlikView and the storage servers, that could increase the writing and reading times, with several concurrent users in the meantime opening a file that has not been saved yet.

Finally, while it is technically possible to use a mapped drive, it would be much easier, in my opinion, to use UNC paths instead, so the shared resource will have the same naming conventions regardless which account is accessing it (developers or the service accounts) requiring less maintenance effort and removing one potential issue.

Sean_BI · ‎2020-06-19

Thank you for your response.

I have been in constant touch with windows platform team, since there were several windows events logs that server generated related to MPIO disk failure and NTFS MFT (Master File Table) errors and corruption on disk volume. This could have basically corrupted the qlik qvd's and qvws.

Also, there were two huge dashboard's (12 GB) each which takes times in updating. This could also, have been another reason. But primarily , appears to be bad disk sectors as stated above.

Given this challenge, I have no option but to re point mounted documents (with UNC paths ie. \\server id\reports\documents) to another disk partition (D:\) which is a bit secured until using windows based file share, rather than using SAN drive (E$ and F$).

I will close this thread and appreciate your response.

Thank you..

Sean.