Snapshot
The Snapshot takes a copy, or "snapshot," of all the information used by the planning processes so that the planning processes can operate on a picture of the data frozen at a point in time, and report against that snapshot at any future time.
Snapshot Tasks
The work performed by the Snapshot can be broken down into individual tasks. Some tasks involve copying information into the MRP tables, such as inventory quantities, master schedule data, discrete jobs, purchase orders, and repetitive schedules. Other tasks involve deleting information from tables. For example, the information in the MRP discrete job table needs to be deleted before MRP can reload the latest information. Many of the tasks are independent of one another--you can load inventory information at the same time you load discrete job information. The Snapshot launches workers to run these tasks concurrently.
When the Snapshot runs, it populates the Snapshot Task table with all the tasks that need to be executed.
Each task has a start date and a completion date. The values of those columns indicate the status of the tasks. A task with a null start date and null completion date has not been executed yet. A task with a value for the start date but no value for the completion date is currently being processed. A task with values for the start date and for the completion date has been processed. The Snapshot looks at these columns to determine which task should be processed next.
Some tasks may be dependent upon other tasks. For example, you must delete from the MRP discrete job table before you reinsert values for the latest picture of the discrete jobs; or, you must load information on current repetitive schedules before you can calculate information on current aggregate repetitive schedules. The Snapshot ensures that independent tasks are processed before the tasks that depend upon them are processed.
Read Consistency
Certain tasks require a database lock to guarantee a consistent read. For example, discrete job information and inventory quantities require a lock on the inventory transactions table to guarantee a consistent read. Consider the situation where you have a subinventory with a quantity of 100 units, and a discrete job for 25 units. Between the time the Snapshot reads the inventory information and the time the Snapshot reads the discrete job information, 10 units are completed from the job. The Snapshot needs to guarantee that it populates the MRP tables with inventory of 100 and discrete job quantity of 25, or inventory for 110 and discrete job quantity of 15. Because each task may be processed by independent processes, the Snapshot cannot guarantee that both tasks are executed at the same time. Therefore, by locking the inventory transactions table, the Snapshot guarantees a consistent read.
Each task has an attribute which indicates whether the Snapshot needs to have acquired the table lock before the task can be completed. Once the locks have been acquired by the Snapshot, those tasks that require a lock are given highest priority, so that the time the tables are locked is minimized. Once all tasks requiring locks have been completed, the Snapshot releases the locks.
Suggestion: Sometimes it is not necessary to guarantee read consistency. For example, if you are running the planning processes for simulation purposes to estimate medium-term and long-term trends in your material requirements, it may not be necessary to guarantee read consistency. Therefore, you may want to run the planning processes with Snapshot Lock Tables turned off, so that you do not need to restrict or limit other users from performing transactions.
Memory-based Planning Engine
One of the advantages of the Memory-based Planning Engine is its ability to get a consistent image of all planning data without locking users out of the system. The planning engine accomplishes this with the Oracle Server feature called "set transaction read-only." With this option, you do not need to lock tables for the duration of the planning run. To ensure total consistency, you need only synchronize the times when the Snapshot Workers and the Memory-based Snapshot execute the set transaction feature.
You can achieve two degrees of read consistency under the Memory-based Planning Engine. Set the Snapshot Lock Tables field to Yes to force the Snapshot Workers and the Memory-based Snapshot to execute the set transaction feature simultaneously. Locking tables gives you the highest degree of data consistency, but you cannot perform any transactions while this lock is on. If you set the Snapshot Lock Tables field to No, the Snapshot Workers and the Memory-based Snapshot may execute the set transaction feature at different times. There is a remote possibility of some inconsistencies with this method.
Lock File
Oracle Master Scheduling/MRP and Supply Chain Planning generally uses the database for inter-process communication. This technique cannot be used when the process trying to send a message also needs to hold table locks. This is the case when the Snapshot has acquired the table locks and needs to communicate this fact to the Snapshot Workers.
The Snapshot launches the Snapshot Workers. The Snapshot Workers begin processing tasks that do not require a database lock. Once the Snapshot has acquired the table locks, it needs to communicate that fact to the Snapshot Workers. However, the Snapshot cannot update a column in a database table to communicate this information. In order for the Snapshot Workers to be able to read this information, the Snapshot would have to issue a commit. This would free the database locks.
The Snapshot creates an operating system file called the lock file to communicate the fact that it was able to acquire the table locks. The Snapshot Workers periodically check to see if the lock file has been created. Once they detect the existence of the lock file, the Snapshot Workers begin processing those tasks that require locks to guarantee read consistency.
Snapshot Configuration
You can configure the Snapshot to determine how many Snapshot Workers to launch when you define the MRP: Snapshot Workers profile option. See: Profile Options.
The above diagram illustrates the Snapshot Process logic under the Standard Planning Engine. Below is a detailed explanation of the logic.
1. Launch X Snapshot Workers via the Concurrent Manager, where X is the number of Snapshot Workers to launch, as defined by the profile option MRP:Snapshot Workers.
2. Did the user specify to lock tables? If not, go to Step 6.
3. Try to lock tables to guarantee a consistent read.
4. Were we able to lock the tables? If No, check to see if we have exceeded the amount of time specified by the user to wait for the table locks.
5. The user specified a length of time to wait for the table locks.
6. Create the lock file. The existence of the lock file signals to the workers that they can execute tasks requiring a table lock, as well as those that do not.
7. Keep looping until all tasks that require table locks have been completed.
8. All tasks requiring a lock have completed. Therefore, there is no need to keep the locks. Issue a database commit to free the table locks.
9. Are there any tasks that have not yet been executed and do not have tasks upon which they are dependent that have not yet completed? If so, execute those tasks.
10. Are there any other tasks to execute? If Yes, those tasks are waiting for the tasks upon which they are dependent to complete. Loop back and try again.
11. Loop until the workers complete.
12. Check the completion status of the workers. If any of the workers exited with error, the plan is invalid and the Snapshot exits with an error.
The above diagram illustrates the Snapshot Worker Process logic. Below is a detailed explanation of the logic.
1. Check for the existence of the lock file. If the lock file exists, the Snapshot was able to acquire table locks. Therefore, tasks requiring table locks may be executed.
2. Are there tasks that have not yet been executed, that require a table lock, and do not have tasks upon which they are dependent that have not yet completed? If so, execute those tasks.
3. Are there any tasks that have not yet been executed, and do not have tasks upon which they are dependent that have not yet completed? If yes, execute those tasks.
4. Have all tasks that require table locks been completed? If not, pause and return to step 1.
See Also
Launching the Planning Process
