Quote:
|
Originally Posted by umayer
REBIND looks into the catalog, takes the information found there and re-evaluates the access-pathes.
BIND takes the *.BND - file, perfoms a lot of checks ( correct syntax, all tables available , everything granted ... ) and then evaluates the access-pathes.
so BIND is more expensive than a REBIND (and can produce some additional errors).
But as both ( BIND and REBIND ) evaluate the access-pathes ( and will pick the same ones ) the performance when executing the package will be the same
|
Both the bind and rebind will make sure that the dependent objects still exist. If a required object was previously dropped (table, etc) then the package would have marked as invalid when the drop took place. If a package is marked as invalid, and someone executes the package, then an automatic rebind will be performed. For a package marked as invalid, when a bind (replace), explicit rebind, or automatic rebind is performed, if the object is still not available then the package is marked as inopertive (no further automatic rebinds will take place and the execution will fail).
A bind (replace) allows you to specify new bind parameters. A rebind uses the same bind parameters as were originally used during the initial bind.
Generally speaking, if you want to redo the access path (if for example you added a new index), then a rebind is usually the best option. If you want to change the bind parameters, then a bind (replace) should be used.