cancel
Showing results for 
Search instead for 
Did you mean: 

.Q.par Doesn't Provide the Correct Result in the Segmented db.

naveen
New Contributor

Hey Everyone.  .Q.par function is not giving the Correct partition in  our Segmented Database.
for Example, It was giving the result, that  the partition for  2021.01.01 was present in /nvme01/ {{directory_name}}/0/ location.
when checking using Find Command, The partition was actually present in this directory ( /nvme08/{{directory_name}}/6).
We have also verified all the partition are present only once in our Segmented Database.
We also Facing issue with .Q.chk function. When running this function,it takes more than 30 minutes. Even though it doesn't completes its execution. Parallely we have checked whether it fills the partition with missing Tables.  it doesn't do that too.

Did anyone face this kind of Problem.

Kindly Share the Ways to Resolve this Problem. Attached Snapshot FYR.

1 ACCEPTED SOLUTION

gyorokpeter-kx
Contributor
Contributor

.Q.par doesn't check where the partition is, only where it should be according to par.txt. It assigns the segments by taking the modulus of the date by the number of par.txt entries.

View solution in original post

3 REPLIES 3

gyorokpeter-kx
Contributor
Contributor

.Q.par doesn't check where the partition is, only where it should be according to par.txt. It assigns the segments by taking the modulus of the date by the number of par.txt entries.

Yes there is a warning on: https://code.kx.com/q/database/segment/#considerations

"Partition data correctly: data for a particular date must reside in the partition for that date."

sujoy
New Contributor III

Seems like a case when entries were added in par.txt from possibly 3 to 8 without moving the partitions to correct locations. Only way to fix this is to move all the partitions to right locations.

These all will be giving inconsistent results

`l `bv `L `a2 `par `dpts `dpt `dpft `dpft `dsftg `chk