I sincerely wish I could hypothesize that a script failed to run somewhere in the installation, but my personal experience is that most current database systems are forced to be designed to minimize the risk of poorly developed and tested code with the goal of avoiding maintenance and support problems.
A good DBA can make the appropriate modifications for accuracy and performance, but at great personal risk of criticism if such changes cause application code issues.
The last ten years of my forty-two years in IT saw a change away from accuracy of data and performance to total emphasis on 'up time', even when the data that was required to be available was total inaccurate.
At one company, it was even dictated to IT by owners that users be allowed to enter their data regardless of accuracy based on the assumption that 'close is good enough' and 'somebody will fix it later'. This meant that engineering designs normally required multiple iterations of user attention to get things even close to accurate. Items in physical layouts could literally end up down the street in the next block.
One of the best days of my IT career was they day I told my boss if the problem was so simple he should go fix it himself.