MXPA98002716A - Access information to the base of da - Google Patents

Abstract

The database manipulation routines in a database that are carried out by means of a database server when determining if the database manipulation routine of a range is going to be isolated or not specific memory, and, in response, selectively change the permission for memory access to the specific memory range (for example, from read and write to read only) for the database manipulation routine under consideration. Then, the database manipulation routine is executed using the permission for memory access changed selectively. The manipulation routine of the database to be isolated can be executed with access to read-only memory, so that a specific range of memory (for example the correspondence to the central data structures) is protected. inadequate modifications

Description

ACCESS INFORMATION TO THE DATABASE BACKGROUND The present invention relates to the information to access the database. A database is a body of information that is organized logically so that it can be stored, searched and called in a coherent way by means of a "database engine" - a collection of software methods to manipulate the data in the database. Typically, software methods are implemented as a set of routines that can be called, either functions, which returns a value, or procedures, which do not return a value. Generally, the database falls into three categories: related database, database oriented to an object and database related to an object. The related database (RDB) is a collection of fixed two-dimensional boxes in a field that can be related (or "linked") to each other in virtually any form selected by the developer of the database. data. The structure of the related database can be modified by means of a selective redefinition of the relationships between the tables. The engine or database driven can perform complex searches in a database related quickly and easily using any of the various questioning protocols such as the method expressed by the Structured Question Language (SQL). English) or by other mechanisms. The relationships between the tables allow the results of the search to be automatically organized in cross-reference with the corresponding information in other tables in the database. As shown in Figure 1, for example, a related database 100 includes a user box 102 that is joined by means of logical links 103 to another frame 104 which, in turn, is joined by means of logical links 105 to an inventory box. The user can interrogate the database 100, for example, for all ordered numbers higher than the threshold or limit value. Because the order box 104 joins the user box 102 and the inventory box 106, the list of ordered numbers, identified in response to the question, can be called and presented along with the respective names of the users and aspects of the inventory that correspond to the ordered numbers identified. An object-oriented database (OODB) is a collection of "objects" - software elements that contain both data and methods to manipulate this data. In contrast to the related database that can only store data of numeric or character type, in an OOBD it is possible to store data of virtually any type (text, three-dimensional graphic images, video, etc.). The OODB stores its constituent objects in a class hierarchy with associated methods so that the OODB contains as much logic as it needs to do useful work. In contrast, the related database contains only data and depends on an external application software to carry out useful functions with the data. The object relationship database (ORDB) is a hybrid of two other types. Extended data (for example a movie file) can be stored and called in an ORDB as a part of a row or as a binary long object (BLOB) - an undifferentiated mass of data. Also, an ORDB can have access methods (for example a utility to view movie files) to manipulate the data contained in the BLOB. These methods can be kept separate from the engine or database driver or can be attached to it in a dependent manner in the particular ORDB implementation. In an extensible object relation database (ORDBMS) management system such that Informix® Universal Server (IUS®), methods for manipulating extended data are attached directly to a database driver so that extended data is treated as a "native" data type - which is, a type of data that ORDBMS itself can be manipulated without the need for external applications. In Figure 2, for example, an extensible ORDBMS 200 has extensions X and Y, which respectively contain methods for manipulating data of type X and Y, units directly to the database operator 202. In response to the question of the base of data pointed out by the type X data, for example, the database operator 202 automatically evokes the methods in extension X to manipulate the data in a specific manner of appropriate data type. In contrast, the non-extensible ORDBMS does not allow data manipulation methods for arbitrary data types to be linked to the database driver but also requires the use of multiple data actuators, of the specific type, interconnected by medium use layers, to handle multiple type data. Generally, as a result of this, the non-extensible ORDBMS presents a reduced performance and presents a developer with an increased complexity in the use of new applications.

SUMMARY In one aspect of the invention, routines for data manipulation in a database are carried out by means of a database server when determining whether the database manipulation routine is to be isolated or no, of the specific range of memory, and in response selectively changing the permission or access authorization to the memory of a specific range of memory (for example read and write to read only) for the routine of manipulating the base of data under considerations. Then, the database manipulation routine is executed using the memory access permission selectively changed. The manipulation routine of the database that is isolated can be executed with an access to the read memory only so that the specific memory range of an improper modification is protected. Whether or not the database manipulation routine is isolated from a specific range of memory (for example, the central memory in which the data core structures reside) can be determined by inspecting a parameter associated with the manipulation routine of the database. The parameter can be set to the value specified by a processor class (for example, a multi-line virtual processor) to execute the database manipulation routine. A certain value of the class indicates that the corresponding processor must be isolated from the memory core by restricting the core permissions of the processor memory for read only. Other class values may indicate that the corresponding processor needs to be an isolator of the central memory and thus be allowed to read and write in the memory core. Collective change of memory access permissions can be achieved by calling the local procedure that sets the memory access permission for the database-only database manipulation routine to the memory core if the database manipulation routine is determined to be "unreliable" - that is, a routine that is isolated from the core of the memory. Alternatively, the memory access permission for the database manipulation routine can be adjusted for central memory read and write if the database manipulation routine is determined as a "trusted" routine - that is, a routine that needs to be isolated from the central memory. When the unreliable routine is to be executed, the local procedure call causes the execution line for a database manipulation routine that migrates from a processor that has read and write permission in the central memory to the processor that has read access only in the central memory. The line that migrates to a region of memory that is logically divided from the central memory but that is in the same memory address space as the central memory. The line is in a "trusted context", when it has permission or permission to read and write in the central memory and in an "unreliable context" when the line has read access only in the central memory. However, when running in a context that is not reliable, the line may need a source in the central memory for its use to run the database manipulation routine. After detecting this condition, it is carried out the change from a context that is not reliable to another reliable context to allow, for example, the line to modify the central memory. After the line has completed its use of the source in the central memory, a change is made from the trusted context back to the context that is not reliable. Similarly, after the unreliable routine has completed execution, a change is made from the unreliable context back to the original trusted context. Any arbitrary number of changes can be made between the reliable context and the context that is not reliable. When carrying out a context change from the context that is not reliable to the reliable context, the entry to the central memory can be limited to a predetermined set of one or more permissible execution entry points, for example, identifying a predetermined return call frame. If a specific entry point appears in the return call box, this entry is allowed to the central memory. However, if the specific entry point does not appear in the return call box, the entry at this point to the central memory is blocked. In another aspect of the invention, the routines for manipulating data in the database are carried out by means of a database service by dividing a memory address space into memory segments (for example, a main segment and one or more peripheral segments). The database manipulation routine, for example, can be executed selectively, a defined user routine that is not reliable, in a peripheral memory segment while preventing the routine from writing information in other memory segments. The database manipulation routine running in the peripheral memory segment may allow to read the information from another memory segment or to migrate to another memory segment to carry out a predetermined routine. Other routines, for example, reliable central database routines can be executed in the main segment that a full read and write access in all segments of the memory. In addition, routines for multiple database manipulation can be executed in the respective memory segments, each database manipulation routine has read-only access to all memory segments other than its own memory segment . The advantages of this invention may include one or more of the following aspects. It allows users to define their own routines and link those defined user routines with the database driver that allows the database server to handle an arbitrary collection of rich data types (for example, images, video, sound, maps, complex financial instruments, time series data) quickly and efficiently. Any risk of a logical failure, which contains the routine defined by the user, contaminating the database is minimized because the user's defined routines are isolated from the central data structures and the base server functions of data. An inappropriate modification of the central memory used by the database server is avoided when executing the user's defined routines with a processor (for example a virtual processor) that has limited privileges. It allows the virtual processor to have full read and write access either in a specific range of memory or in a segment of its own auxiliary memory that depends on a particular implementation, but is limited to a read access only in the server memory of the central database. As a result of this, the user is provided with improved flexibility while maintaining a high degree of reliability and performance for the database server. By enabling a routine to specify a class in the virtual processor under which the routine is to be executed, database developers are provided with a powerful and flexible mechanism to isolate routines that are unreliable. A routine can be run as a reliable or unreliable context simply by changing a parameter to designate a virtual processor class with full read and write privileges or a "peripheral" virtual processor, which has only read privileges in a designated region of memory. In a configuration where the memory is logically divided into segments, the segments of the memory occupy different portions of the same memory address space. As a result, the execution line for the defined user routine can be moved between the segments of the memory quickly and easily. Moreover, the internal routines provided by the database server allow a peripheral virtual processor to access the sources present in the central memory segment while protecting the contents of the central memory segment from an inappropriate modification. . Therefore, the isolation of defined user routines that are not reliable is done while maintaining a high degree of performance and scalability for the database server. Other advantages and features will be apparent from the following description, including drawings and claims. DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram of a related database of the prior art. Figure 2 is a block diagram of a management system for the extensible related object database. Figures 3A and 3B are examples of the server architectures of the prior art database. Figure 4 is a block diagram of a database server architecture that has multiple memory segments. Figure 5 is a block diagram of the Informix® Universal Server architecture.

Figure 6 is a flow chart of the routines executed in the Informix® Universal Server architecture of Figure 5. Figure 7 is a data diagram of a callback box that can be used in the Informix® Universal Server of Figure 5. Detailed description The use of a system for handling an extensible database (DMS) to store permanent data provides several advantages that are not available when using non-extensible DBMS as a warehouse or data warehouse. The ability to join routines to manipulate virtually any type of data directly in a database driver allows designers to build the DBMS to meet the specific needs of a company. Furthermore, the ability to implement client functions together with the central DBMS functionality in a simple drive solution that improves DBMS performance, transaction integrity, scalability and manageability for both traditional and complex data types . Providing this broad degree of flexibility and extensibility in developers can potentially cause problems, however, it depends on the DBMS architecture that is used. In the architecture of Figure 3A, for example, a server of a database 300 receives the questions from the database of clients I, J and K (301-305) by means of communication links 307 and leads questions from the database to the Q, R or S lines as appropriate. Each client can communicate with a separate line, as shown in Figure 3A or a multi-line processor can receive questions from two or more clients. In each case, the lines in turn make free calls to evoke predefined routines that carry out desired operations in the database. In Figure 3A, all lines residing on the database server 300 execute their respective routines in the same memory address space - namely shared memory 302 - for each line has full read and write privileges . Ordinarily, allowing lines Q, R and S to read freely from and write to shared memory 302 will not cause problems with operating systems because each of the underlying routines evoked by the lines can be written by the same distributor of the software and can be completely tested for correct and complex operation with each of the routines linked to the database server 300. However, in some cases you can write a relatively unsophisticated developer or a DBMS end user, and failure to initialize the database handling routine that is failing - that is, executing the routine that is done to modify the shared memory 302 of the database server 300 in an inappropriate manner, potentially breaking the DBMS or corrupting the database or both. Figure 3B presents a solution to protect the shared memory of the database server from being damaged by the execution of a routine of a defined, defective user (URD). In the architecture of Figure 3B, the database handling requirements that are received from clients 301-305 are handled in different ways depending on whether the underlying routines, to which they correspond, are considered "reliable" ( for example UDRS that have been extensively tested to ensure that they do not improperly modify shared memory 302 or similarly present conflicts with other routines) or "unreliable" (for example URDs that have not been extensively tested). For those URDs designated as belonging to the trusted class, the call line executes the routine in shared memory 302 with full read and write privileges in the same manner as discussed above, in relation to Figure 3A. Nevertheless, in the case of an unreliable URD, the evocation line (for example, line S) performs a remote call procedure (RPC) - a programming mechanism that causes the line to migrate from a space in the address from memory to another memory address space while maintaining the context of the program - to another server 310. Once the line has migrated to server 310, the unreliable URD is executed in memory 312 and the result it is returned on passing the line back to the DB 300 server. Because the memory 312 on the server 310 represents a space of the memory address that is separated and distinguished from the shared memory 302 on the server 300, any routine which runs on the server 310 is unable to directly modify the shared memory 302. In effect, the RPC that is carried out by the line S isolates the underlying execution of the line from the database server 300 so that protects shared memory 302 from an inappropriate modification by a routine that is unreliable. However, the exchange between the different memory addresses is an activity that consumes a lot of time. Each RPC for a different memory address space typically incurs a considerable amount of time to drive and retrieve the arguments and results between the different servers. Moreover, the basic architecture of the RPC lies in the proper operation of communication links between two or more different address spaces, each of which is typically associated with a separate computer system. Each of the communications between the system are considerably less reliable than communications within the system. The RPC-based isolation architecture consequently suffers from relatively poor performance and reliability. These and other problems associated with the isolation architecture based on the RPC are addressed by means of the database server architecture in which certain methods that are not reliable, such as UDR can be isolated from the central data structures and reliable methods such as the central database's operating routines. Isolation can be achieved by using one of the two different models: a multiple process model and a simple process segment model. In a multi-process model, isolation can be achieved in an architecture like the one shown in Figure 4, by maintaining multiple memory segments - a main memory segment 303 and the auxiliary memory segments 304, for example - - within the same address space of the memory 302. The segment 303 serves as a memory region in which the database drive routines are reliably centralized and the central data structures are executed and stored. The memory segment 304 serves as an auxiliary memory region reserved primarily for executing and storing routines and data different from those corresponding to the functions of the central DBMS. The line executing a reliable routine will remain in and have full read and write privileges for the main memory segment 303. However, to execute a routine that is not reliable, the first line migrates to a segment of auxiliary memory 304 for isolating the line from the central memory segment 303. The line running in the auxiliary memory segment (for example, the S line) has all the read and write privileges in the 303 memory segment. In contrast, the memory areas in which the S 'line can write, when executing an unreliable routine, the data structures of the central DBMS and the routines are protected from overwriting by a UDR fault. Moreover, because reliable and unreliable routines run in the same memory address space (although it is done in different memory segments), the S 'line does not need to perform an RPC to perform a routine that is not reliable but can use a normal local procedure call, which is generally more reliable and requires a total time that is hardly of the magnitudes smaller than that of the RPC . As a result, the isolation of unreliable routines can be achieved while maintaining relatively high levels of performance and reliability. When the database server is implemented using a simple process, isolation can be achieved within the central memory segment by modifying the modified read and write privileges based on the nature of the routines that are executed. When executing a reliable routine, the line will have full read and write privileges in the main memory in an ordinary way. However, before running the trusted routine, the read and write permissions on a range of memory that corresponds to the core database routines are changed in a read only for the line running in a routine that is not reliable . The read and write privileges changed in a memory segment can be achieved by either method: (i) by evoking the specific routines of the operating system, to change read and write permissions in a specific range of memory, or 8ii by separating the process in which the line of the memory segment resides and then specifying different access permissions of reading and writing after re-joining the process to the memory segment. In both methods, corruption of the database is avoided by prohibiting a routine that is not reliable from modifying a designated portion of memory. A detailed description of the architecture form in Figure 4 can be used in an Informix® Universal Server to effectively isolate an unreliable URD from reliable central data structures and the DBMS routines are provided with reference to Figure 5. In the Multiple processor environment shown, the Informix® Universal Server uses multiple memory segments - core memory 402 and peripheral memory 412, for example - that occupy the same memory address space but logically divide one from the other . The database server 400 is composed of one or more virtual processors (VPs) - multi-line software entities that emulate hardware processors and that can accept and process multiple client requests concurrently. Each VP is an example of a binary executable file that runs, for example, as a process in the UNIX operating system. The binary executable file includes the software components necessary to form an ORDBMS in addition to the software components that provide the ability to interface with the extensions containing the UDRs to handle the arbitrary data types.

The virtual processor presents a variety of classes, each class defines certain characteristics that control the privileges available in and the restrictions imposed for, the VP within this class. Each routine that is bound to the database driver, either a central database routine or a UDR, has an associated parameter, VPCLASE, that designates the class of VO with which the routine is to be executed . In general, a collection of related routines functionality is assigned to the same VP class. The VO class parameter can be changed at startup to specify different classes depending on the desired configuration of the database server. The database server can be composed of different VP, either of the same or different classes. The VP joins a library of the core database routines that is included as part of the IUS® system. As well. The VP can be attached to one or more UDRs, for example, UDR1 and UDR2 as shown in Figure 5, which has been designed by the user to handle the arbitrary data types specified by a user of the IUS® system. Both the core database routines and the UDRs are implemented in the IUS® architecture, using the DataBlade® technology developed by Informix®, Inc. A detailed description of the DataBlade® technology and how it can be used to create a new UDR is provided in the e < Team 9.01 of DataBlade® Developers Order No. Informix 82181), which is incorporated herein by reference. In the configuration shown in Figure 5, the database server includes three different VPs 403, 405 and 409, each belonging to different classes. The VP of the CPU 405 belongs to a "cpu" of class VO, the class that runs routines more efficiently and that is the failure of the VP class for most of the central database routines. The VP of the CPU 405 receives and handles all the questions of the database that enter or other requirements in the first instance. In processing a client request, the CPU VP can evoke other VP classes to perform special functions. For example, VP of CPU 405 may invoke VP of extensions 403 (VP CLASS = "ext") to serve a blocked I / O request, so the VP of the CPU is released to handle other client requests. All VP classes have static read and write privileges that are determined at the time the database server is started or started. Unless otherwise specified, all VP classes, by default, have full read and write privileges in central memory 402. However, an extension of the VP may be designated to run as a peripheral VP when establishing your CLASEVP in the "periphery". Other VP classes (for example "cpu", "aio", "tli") do not normally support the peripheral mode of operation. In Figure 5 according to this, the peripheral VP 409 (ie an extension of the VP having its CLASEVP set as peripheral) has all the Read and Write privileges of the peripheral memory 412 but is limited to a read access only in the central memory 402. By setting the CLASSVP parameter appropriately, the manner in which the routine is treated (for example, reliable versus untrusted) can be controlled. To run a UDR as a trusted routine, the CLASEVP is set to "cpu" meaning that the VP of the CPU will execute the routine in the same way as the action routines of the central database. To run a UDR as a reliable routine but in a segment of the memory different from the central memory segment, 1a CLASSVP is set for the identifier of the VP class different from the "cpu", for example, "output". To run as a routine that is not reliable in a memory segment other than the central memory segment, the CLASEVP includes the identifier "periphery" meaning that the routine is to be executed by the VP that is outside the periphery from ( for example it is not able to write in) the central memory segments.

An explanation of how the database server switches between the reliable and non-reliable routines is provided in reference to the flow chart of Figure 6. The client or user has access to the database server 400 when connecting, or "registration" on the server (for 500) and issues one or more requests (for example SQL questions) in the course of the registration session. After the first connection to the database server 400, each client is placed in the memory block by means of the VP of the CPU 405 through a call to the routine of the central database, mt-alloc-stack () (step 502). The localized block region of the client is used by means of one or more execution lines associated with this client when attending the customer's question in the database, which is issued during the registration session. Also, the block location routine is evoked when an additional space is needed that is stacked or to open a new line of work for a parallel processing of a client request. When the client sends a question to the database or another request to the database server (step 504), the VP of the CPU 405 starts processing the question by determining what routine it needs to run and present the information specific and display it in the appropriate format (step 506). As part of the process, the VP of the CPU 405, similarly, will carry out an analysis of optimization of the question and will initiate the execution of the operations of manipulation of the database. Eventually, the VP of the CPU will typically reach the point where one or more routines need to be executed to serve the client's request. For each routine to be executed, the VP of the CPU 405 examines the parameters of the VP CLASS routine to determine the routine to be executed by the VP which has full read and write privileges in the central memory 402 by the peripheral VP 409, which has read and write privileges in the main memory 402 (step 508). The routing package that is carried out at the customer's request service are typically routines of the trusted central database running in the central memory 402 either in the VP of the CPU 405 itself or by a peripheral VP of a class other than "cpu" (for example, an extension VP 403). However, some of the routines that are carried out at the service of a client request may be unreliable UDRs that are executed by means of the peripheral VP 409 in the peripheral memory segment 412 to isolate the UDR from the memory of ña central database. If the CLASSVP parameter consistently does not include the word "periphery", the routine is treated as a reliable one. To do this, the VP of the CPU 405 pushes the parameters for the routine in the client block in the central memory 402 (step 510) and inserts, in the row or main row running 404, an entry for the line executing the routine (step 512). When the main row running 404 near the points for the entry of the routine line, the VP of the class specified by the parameter CLASS OF the VP of the routine selects the line and executes the requested routine in the central memory 402 to take the parameters out of the client's block and use them to carry out the instructions specified by the routine (step 514). By carrying out the reliable routine, the VP in which the routine runs runs and allows it to write freely and read in the central memory 402 according to what it needs. After completion, the routines push any parameter back to the client block and return control to the appropriate location (516). However, if the CLASSVP parameter includes the word "periphery", the line running in the VP of the CPU 405 migrates to the peripheral VP 409 such that the routine (typically a UDR) can be executed in the peripheral memory segment 412. The VP of the CPU 405 starts the migration of the line by calling the routine of the central database, mt-priv-call (), which in turn calls mt-alloc-stack () to locate the memory block (peripheral block 416) in the peripheral memory segment rather than in the central memory segment 402 ( step 518). After the block has been located, mt-priv-call () performs a context change by pushing the parameters for the UDR in the peripheral block 416 (step 520), and inserts a row entry line that runs in the periphery 414, which is kept separate to run routines that are unreliable. Subsequently, the peripheral VP executes the UDR that is not reliable in the peripheral memory segment 412 when it runs the next line in the row (step 524). When executing a UDR, the VP of the periphery 409 can read freely and write to the peripheral memory segment 412 but prevents it from writing in the central memory segment 402. Moreover, the peripheral VP 409 has only access for reading in the central memory segment 402 to allow the peripheral VP 409 to read the data in the segment 402 as needed to perform a UDR that is not reliable. The peripheral VP 409 is able to access the sources residing in the central memory 402 through the internal routines provided by the multiline interface (MT), the application of the interface of the application program (SAPI for short) in English) and the user-defined routine language handler (UDRLM). These internal routines understand whether the performance of a particular routine requires the line to migrate between the memory segments. The SAPI interface library defines the supported routines that the UDR can call. The SAPI routine can detect according to the input that the current context is not reliable. If a routine running in an unreliable context needs to modify the central memory, it will be changed to a reliable context by means of mt-priv-call (), to carry out the desired operations and change back to an unreliable context with another mt-priv-call (). Virtually any arbitrary number of changes between reliable contexts can not be carried out in this way. By selectively changing the contexts as needed, the execution line can be moved between the segments and the VO in a way that is transparent to the client's processors and to the UDRs. In an alternative embodiment, the peripheral VP executing a UDR that is not reliable can carry out "callbacks" in the central memory to access the sources residing in it, while keeping the UDR untrusted in isolation . The IUS system maintains a table of allowable routine calls that modifies the sources that reside in the central memory. The VP of the periphery can recall any routine call specified in the callback box by indicating the corresponding ordinal position in the box for the desired routine. As shown in Fig. 7, for example, the VP of the periphery will designate two positions in the callback frame 600 when the peripheral VP wants to evoke the routine (y). When a VO that is not from the periphery, with the objective of carrying out a required routine in the central memory, then selects the line that was previously executed in the VP of the periphery, the VP that is not of the periphery can ensure that the memory address signaled by the routine call was a legitimate and secure execution entry point in the central memory, by confirming that the required routine was mentioned in the call return 600 box. If the required routine was not mentioned in the callback 600 box, the execution of the required routine may be blocked - that is, the VP that is not from the periphery may not execute the routine that is required. In this way, the mechanism of the callback table limits the routine calls that can be made in the peripheral VP, and therefore a jump from an inappropriate location potentially in the central memory is avoided. The callback box can be implemented in at least two different ways. In the first, the return call box can contain a list of permitted routing addresses. A UDR search engine for the return of the call back to the central memory would provide an entry point to the identifier to be used as an index for the callback frame. The VP that is not from the periphery will carry out the routine specified by the identifier of the particular entry point supplied by the UDR. Alternatively, the callback box can be a legal execution list addressed in the central memory. Any entry point specified by the UDR can be verified against the execution address mentioned in the callback box to confirm the validity of the entry point. The methods and mechanisms described herein are not limited in any way to the configuration of the hardware or software, but may find application in any computer or processing environment in which database operations may be carried out. The techniques described in the invention can be implemented in hardware and software, or in combinations of the two. Preferably, the techniques are implemented in computer programs that run on programmable computers in which each includes a processor, a data storage medium that the processor can read (including volatile and non-volatile memory and / or storage elements), and suitable input and output devices. The code of the program is applied to the data that is entered using an input device to carry out the functions that were described and to generate the output information. The output information is applied to one or more output devices.

Preferably, each program is implemented in a high-level procedure or in an object-oriented programming language to communicate with the computer system. However, programs can be implemented in a set or machine language, if desired. In any case, the language can be a compiled or interpreted language. Each computer program is preferably stored in a storage medium or device (for example CD-ROM, hard disk or magnetic disk) which is read by means of a general purpose or special programmable computer to configure and operate the computer when the computer reads the means or storage device to carry out the described procedures. Also, the system can be implemented as a means of storage in the computer that is read, configured with a computer program, where the storage medium that is configured in this way causes a computer to operate in a specific and predefined way. Other embodiments are within the scope of the following claims.

Claims (50)

1. A method, developed by means of a database server, to carry out the routines for the manipulation of the information in a database, this method includes: determining if the routine for the manipulation of the database is going to isolate from a specific range of memory; and selectively change the permission or access authorization to the memory, for the database manipulation routine based on the determination; and execute the database manipulation routine using the permission or access authorization to selectively changed memory.

2. The method according to claim 1, wherein the determination comprises inspecting a parameter associated with the database manipulation routine.

3. The method according to claim 2, further comprising, before the determination, adjusting the parameters to a value that specifies the class of processor to execute the routine of manipulation of the database.

4. The method according to claim 3, wherein the adjustment comprises adjusting the parameter to the value that specifies the class of processor that is isolated from the specific range of memory.

5. The method according to claim 1, wherein the selective change comprises making a local procedure call.

6. The method according to claim 1, wherein the selective change comprises adjusting the permission or authorization for memory access so that the database manipulation routine reads only the specified range of memory if the manipulation routine of the database is determined as the routine to be isolated from the specific range of memory.

7. The method according to claim 1, wherein the selective change comprises adjusting the authorization for access to the memory so that the database manipulation routine reads 7 writes in the specified range of memory whether the manipulation routine of the database is determined as the routine that is not going to be isolated from the specific range of memory.

8. The method according to claim 1, wherein the selective change comprises migrating an execution line for the database manipulation routine from the processor that is authorized to read and write in the specific memory range to the processor that has permission only to read the specific range of memory.

9. The method according to claim 8, wherein the migration comprises keeping the execution line within the same address space as the specific range of memory.

10. The method according to claim 1, wherein the selective change comprises the change of a reliable context in which the execution line for the manipulation of the database is allowed to read and write in a specific range of memory to a context that it is not reliable in that the execution line only has permission to read in a specific range of memory.

The method according to claim 10, further comprising detecting that the execution line requires access to the source, which resides in a specific range of memory to which the execution line has read-only access, to execute the routine of manipulation of the database.

The method according to claim 11, which further comprises detecting which execution line requires access to the source that resides in a specific range of memory, changing from the unreliable context to another reliable context in which the execution line You have permission to read and write in a specific range of memory.

13. The method according to claim 12, further comprising the change from another reliable context to the context that is not reliable after the execution line for the database manipulation routine has completely entered the source in the specific range of memory.

14. The method according to claim 13, further comprising changing from the unreliable context to the trusted context after completing the execution of the database manipulation routine.

The method according to claim 1, wherein the selective change comprises carrying out an arbitrary number of changes between the reliable context and the context that is not reliable.

16. The method according to claim 1, wherein the execution comprises remaining in the same address space as the specific range of memory while executing the database manipulation routine.

17. The method according to claim 1, wherein the execution comprises carrying out the database manipulation routine with a processor that has permission only to read the specific range of memory if the database manipulation routine it is determined as a routine that will be isolated from the specific range of memory.

18. The method according to claim 1, wherein the execution comprises carrying out the routine of manipulating the database with a processor that has a permission to read and write in a specific range of memory if the routine of manipulation of the database is determined as a routine that is not going to be isolated from the specific range of memory.

19. The method according to claim 1, wherein the execution comprises carrying out the database manipulation routine in a memory segment that is logically divided from the specific memory range if the database manipulation routine Data is determined as a routine that is to be isolated from the specific range of memory.

20. The method according to claim 1, wherein the execution comprises carrying out the database manipulation routine in the specific range of memory if it is determined that the database manipulation routine is going to be a routine that is not going to be isolated from the specific range of memory.

21. The method according to claim 1, wherein the execution comprises selective permission modification of the sources residing in a specific range of memory.

22. The method according to claim 21, wherein the selective modification is limited to one or more entry points for the execution of the permit in the specific range of memory.

23. The method according to claim 22, further comprising specifying one or more entry points to the allowable execution in a callback frame.

24. A method, developed by means of a database server, to carry out routines for the manipulation of information in a database, this method comprises: dividing the space of the address of the memory into segments of memory; selectively execute the database manipulation routine in a first memory segment; and avoiding execution of the database manipulation routine from the write information to another memory segment.

25. The method according to claim 24, further comprising allowing the execution of the database manipulation routine in the first memory segment to read the information from another memory segment.

26. The method according to claim 24, further comprising allowing the execution of the database manipulation routine in a first memory segment to migrate to another memory segment to perform a predetermined routine.

27. The method according to claim 26, further comprising verifying whether the specified entry point for the predetermined routine in another segment is a point that allows entry.

28. The method according to claim 27, wherein the verification comprises comparing the specific entry point with a predetermined set of one or more permissible entry points.

29. The method according to claim 27, further comprising blocking the execution of a predetermined routine if the specific entry point in another segment is an entry point without permission.

30. The method according to claim 24, further comprising returning the database manipulation routine to the first memory segment after the predetermined routine is completed.

31. The method according to claim 24, wherein the database manipulation routine is executed in the first memory segment if the database manipulation routine is identified as the one in which the database is to be protected. information in another memory segment.

32. The method according to claim 31, wherein the database manipulation routine from which the information in another memory segment is to be protected comprises a routine that defines the user.

33. The method according to claim 31, wherein the routine of manipulating the database from which the information in other memory segment is to be protected comprises a routine that is not reliable.

34. The method according to claim 24, further comprising, if the database manipulation routine is not identified as that from which the information in other memory segment is to be protected, execution of the manipulation routine of the database with full read or write privileges for all memory segments.

35. The method according to claim 34, wherein the database manipulation routine comprises a trust routine.

36. The method according to claim 24, wherein the memory segments reside in the same address space of the memory.

37. The method according to claim 36, wherein the division comprises the logical separation of the memory segments from each other.

38. The method according to claim 24, wherein the selective execution comprises carrying out the database manipulation routine with a process that has access only to the reading of the memory segments other than the first memory segment. .

39. The method according to claim 38, wherein the process comprises a multi-line virtual processor.

40. The method according to claim 24, further comprising concurrently executing a variety of database manipulation routines in the respective memory segments, each database manipulation routine having access only for reading all of them. the memory segments that are not the segments of their own memory.

41. The database server "comprising: a variety of routines for manipulating the database that include a trusted routine and a routine that is not reliable; a space for shared memory address having a variety of memory segments that include a central or core memory segment and a peripheral memory segment; a variety of virtual processors attached to the variety of routines, the virtual processors include a full access virtual processor that executes the reliable routines in the central memory segment and a peripheral virtual processor that executes the routine that is not reliable in the segment of peripheral memory.

42. The server for the database according to claim 41, wherein the virtual access processor has a read and write access for all memory segments.

43. The service for the database according to claim 41, wherein the peripheral virtual processor has access only to the reading of the central memory segment.

44. The server for the database according to claim 41, wherein each database handling routine has an associated parameter that specifies whether the routine is reliable or not.

45. The database server according to claim 41, further comprising a line to execute the database manipulation routine, the migration line from the virtual processor to other virtual processor is based on whether the routine of manipulation of the database executed in reliable or not.

46. The database server according to claim 45, wherein the line migrates to the peripheral virtual processor if the database manipulation routine that was executed is a routine that is not reliable.

47. The database server according to claim 45, wherein the line migrates to the full access virtual processor if the database manipulation routine that was executed in a reliable routine.

48. The computer software, which resides in a means of reading a computer, for the database server that has binding routines or link to carry out the manipulation methods, the software for the computer comprises the instructions for making that the computer carries out the following operations: (a) receive a database of a customer's question; (b) determine what are the routines necessary to carry out the database service of the question; (c) play a reliable routine with read and write access to the central memory; and (d) perform a routine that is not reliable with read and write access to the central memory.

49. The computer software according to claim 48, wherein (d) comprises the instructions for causing the execution line to migrate from the first processor having read and write access from the central memory to another processor that has access of reading only from the central memory.

50. The computer software according to claim 48, wherein (d) comprises the instructions for changing the memory access permission by the central memory for reading only in relation to the performance of the unreliable routine.