embodiments discussed below relate to interactive physical design tuning of databases . for background , fig1 shows a physical design tuning tool 130 . the tuning tool 130 is an application used by a dba to explore alternate configurations of a database 131 managed by a dbms . different storage boundaries 132 ( e . g ., memory limits ) and physical configurations and workloads 134 ( sets of queries ) can be tested for performance results . the tuning tool 130 may function as a database client that communicates with the dbms through an interface ( an api provided by the database ) to submit “ what - if ” scenarios that the dbms explores , tests , and provides feedback on without necessarily executing the queries . in other words , the dbms 102 can give feedback on how well a query optimizes or performs according to a possible configuration . as a result , the tuning tool 130 may output some configuration 136 ( e . g ., some set of indexes i 1 . . . im ) deemed to be ideal for the given boundaries 132 and workload 134 . generally , the tuning tool 130 may test many configurations for a query before deciding which configuration is optimal . regarding what - if facilities or instrumentation of a dbms , description is provided elsewhere , for example , see “ self - tuning database systems : a decade of progress ”, vldb &# 39 ; 07 , acm 978 - 1 - 59593 - 649 - mar . 7 , 2009 . the scenarios mentioned in the background above show that the state - of - the - art techniques for physical design tuning are inflexible . referring to fig1 , the typical approach has been to specify a simple scenario , submit same to the dbms , and receive a recommended configuration . flexible and interactive refinement has not been possible . the inventors have observed that goals or constraints of tuning the physical design of a database system are often not fully specified upfront , but instead become apparent through experimentation , feedback , analysis , etc . current physical design tools are monolithic , expose tuning options that are set at the beginning , and generate , without further user input , a final configuration to deploy into a production system . embodiments described below shift the design approach and allow tuning sessions to be highly interactive . current monolithic architectures in physical design tools force users to specify the whole problem upfront and prevent users from making changes a posteriori or in general interacting with the system . explanation will begin with description of an architecture for interactive sessions , followed by a review of windows powershell as an infrastructure component that can support the architecture . explanation will proceed with description of interactive tuning processes , followed by presentation of illustrative examples . fig2 shows a layered architecture 148 for physical design tuning . a core dbms layer 150 is a lowest layer within the dbms ( e . g ., sql server 152 ) and provides native support for operations such as what - if optimization , which may be facilitated in party by a sql server optimizer 154 , for example . what - if optimization support in a dbms is described in other sources , such as “ configuration - parametric query optimization for physical design tuning ” ( in proceedings of the acm international conference on management of data ( sigmod ), 2008 , and “ autoadmin ‘ what - if ’ index analysis utility ” ( in proceedings of the acm international conference on management of data ( sigmod ), 1998 ). this layer provides what - if optimization ( i . e ., the ability to obtain expected costs of queries for varying physical designs without the requirement that the physical designs being implemented ). additionally , this layer enables rich information after regular optimization ( see low layer api ), such as sets of access path requests that can be later used to understand the set of possible indexes that could be useful for a given query . it does so by piggybacking on top of regular optimization and identifying access path requests . it may not actually expose functions , but instead may enable functionality that can be exposed in the low - level apis . a low - level api layer 156 may expose , in formats that are simple to consume ( e . g ., xml ), the functionality of the core dbms layer 150 ( and also the dbms itself ). as an example , they may expose primitives to manipulate a what - if mode of the dbms and also may expose rich explain modes which , after optimizing queries , surface optimization information use at higher levels of the dbms . the explain mode may provide useful information about the optimization of a query , such as the final plan obtained by the optimizer , cardinality estimates for intermediate results , access path requests , etc . ( it may be thought of as an extension to existing modes in relational systems , such as showplans in microsoft sql server ). the low level api layer 156 may also encapsulate existing dbms functionality , such as mechanisms that monitor and gather workloads . a high - level api layer 158 if provided to facilitate access to the lower level apis 156 and core dbms layer 150 . physical design tools were previously built on top of the low - level apis only exposed a rigid functionality ( e . g ., point to a workload , set the storage constraint , and optimize ). the high - level api layer 158 exposes the internal representations and mechanisms in a modular way . basic concepts such as queries , indexes , databases , tables , and access - path requests are exposed as instantiable classes . in addition to these data structures , the high - level api layer 158 exposes composable and simple algorithms sometimes found in previous tuning tools . for instance , this layer may expose mechanisms to merge two indexes , or to obtain the best set of indexes for a single query . these primitive data structures and algorithms are not necessarily meant to be consumed by dbas , but instead provide a foundational abstraction for applications to be built on top , as explained next . in one embodiment , described later , the high - level api layer 158 may be implemented as a . net assembly 160 , which is executed by a . net vm 162 ( virtual machine ), sometimes called a managed code environment . front - ends 164 are based on both the low - level apis 156 and high - level apis 158 and deliver functionality to end users . one example of a front - end 164 is an interactive scripting platform to interact with physical database designs . the scripting language understands and works with the data structures and algorithms exposed by the underlying layers and allows users to write interactive scripts to tune the physical design of a database . common tasks , such as minimizing the cost for a single storage constraint ( or other functionality provided by previous physical design tools ), can be implemented as pre - existing scripts that can be accessed using graphical user interfaces by relatively inexperienced dbas . as mentioned , a front - end 164 can be implemented by a scripting environment . for example , windows powershell 166 ( tm ), available from microsoft corporation is a scripting language that can be used as a front - end 164 in the architecture . a prototype implementation of the architecture using windows powershell 166 will also be described . windows powershell is an interactive , extensible scripting language that integrates with the microsoft . net framework . it provides an environment to perform administrative tasks by execution of cmdlets ( i . e ., commandlets , which are basic operations ), scripts ( which are composition of cmdlets ), stand - alone applications , or by directly instantiating regular . net classes . the main features of windows powershell include tight integration with . net , strict naming conventions , object pipelines , and data providers . windows powershell integrates with the . net framework and leverages the . net framework to represent data . windows powershell understands . net classes natively , as illustrated below . thus , new classes written in the . net framework are easily available as first - class citizens in windows powershell . windows powershell uses strict naming conventions . cmdlets in windows powershell follow a verb - noun naming convention , and parameters are passed in a unified manner . some examples of such built - in cmdlets are start - service , which starts an os ( operating system ) service in the current machine , get - process , which returns a list of processes currently executing , clear - host , which clears the screen , and get - childitem which , if located in a file system directory , returns all its subdirectories or files . there are also aliases for the common cmdlets . powershell also provides facilities to construct object pipelines . similar to unix shells , cmdlets can be pipelined using the “|” operator . however , unlike unix shells , which typically pipeline strings , windows powershell pipelines . net objects . for instance , the script : & gt ; get - process | sort - object - property handles - desc | select - object - first 5 | stop - process obtains the list of all running processes , pipes the result ( which is a list of system . diagnostics . process . net objects ) to the sort - object cmdlet , which understands the semantics of the objects and sorts them by the property handles in descending order . in turn , the result of this cmdlet ( i . e ., an ordered list of processes ) is passed to the select - object cmdlet , which takes the first five processes and passes them to the next cmdlet in the pipeline , stop - process , which terminates them . the following script returns the number of lines that contains the word “ constraint ” in any latex file in the current directory that is below 100 , 000 bytes long : & gt ; get - childitem - path *. tex | where - object - filterscript { $ . length - it 100000 } | foreach - object - process { get - content $ | select - string constraint } | measure - object count : 404 which gets all files in the current path that have a “ tex ” extension and keeps only those that are smaller than 100 , 000 bytes . then , each file is processed by first getting its content ( which returns a list of string . net classes ), selecting only those that contain the work constraints . the combined result of this subscript is a list of strings , which is measured and the count is returned . to shorten a script , aliases ( e . g ., get - childitem becomes “ dir ”, where - object becomes “?”, foreach - object becomes %), and positional cmdlet parameters can be used . for instance it is not necessary to explicitly write — path after dir . an equivalent script is shown below : & gt ; dir *. tex | ? { $ . length - it 100000 } | % { gc $ | select - string powershell has the ability to expose hierarchical data models by means of data providers , which are then accessed and manipulated using a common set of cmdlets . as an example , the file system is one such provider . when situated in some node inside the file system provider , get - childitem can be used to obtain the subdirectories or files in the current location , access contents of elements using get - content , and navigate the provider using set - location ( aliased as cd ). however , windows powershell natively exposes the registry and the environment variables as providers . there also are third party providers that give a unified surface to access , query , and modify active directory , sharepoint and sql server , among others . the next section describes how take advantage of the different features of windows powershell to provide an interactive experience for physical design tuning . a prototype implementation that enables interactive physical design tuning sessions will now be described . the architecture of this implementation is described first , followed by discussion of examples of how the implementation can be used . fig2 shows how the different layers of architecture 148 map to the implementation . an implementation of each layer of the architecture 148 will be described in detail . the core dbms 150 and low - level apis 156 are implemented by instrumenting a database server , for instance microsoft sql server 152 . some components ( e . g ., what - if optimization ) are already part of this particular database server , while others ( e . g ., access - path request interception ) were added . the high - level api layer 158 is implemented by introducing a new . net assembly 160 that encapsulates and exposes classes and algorithms relevant to physical design tuning . among the classes that the assembly exposes are database , table , index , column , query , configuration , and request classes . these are rich in functionality , so for instance the index class may have methods that return merged and reduced indexes and methods that create hypothetical versions of the index in the database . the query class may have methods that evaluate ( optimize ) it under a given configuration , and methods that return its set of access - path requests . additionally , as part of the . net assembly 160 , a sophisticated caching mechanism may be built to avoid optimizing the same query multiple times in the database server . instead , each query remembers previous optimizations and , if asked again to optimize itself with a previously seen configuration , it returns the cached values without doing the expensive work again . because these classes are exposed in an assembly , the definitions thereof can be loaded directly into windows powershell which may be used to explore , in interactive form , the physical design of a database , as illustrated in fig3 . fig3 shows a transcript 180 of an example interactive tuning session . first , a user created 182 a new database object ; an object implemented by the . net assembly but instantiated via user input typed at the powershell command prompt (“& gt ;”). then , the user explored the database object by typing its variable name 184 , in response to which various information about the corresponding data is displayed ( such information having been obtained from “ nicolasb02 ” dbms hosting the “ tpch01g ” database ). specific information about tables of the database is then displayed by invoking 186 appropriate properties of the $ db database object . a new query object is then instantiated 188 , and then the user evaluates the query 190 according to the “ base ” or default configuration of the database . while the example above is useful , call the . net methods directly can be inefficient . also , using such methods directly may be a time consuming way to accomplish tuning a database design . using the capabilities of windows powershell , functionally such as a provider , visualizations , cmdlets , and scripts can be used . powershell providers are . net programs that allow a user to work with data stores as though they were mounted drives or file systems , which simplifies accessing external data outside the powershell environment . a powershell provider can be implemented that exposes the information about a tuning session in a hierarchical and intuitive object model . fig4 shows an xml representation 210 of a portion of a simplified version of a hierarchy exposed by a provider . by using this provider , the state of a tuning session can be easily manipulated and navigated as shown in fig5 . fig5 shows a transcript 230 of an example interactive tuning session using a provider . note that file system style commands such as “ cd ” and “ dir ” can be used to navigate and view database information , tuning information , configuration information , and so on . fig6 shows an example visualization 250 . use of a composable , interactive script language can allow inclusion of third - party add - ins that offer specific functionality . for example , the powergadgets web site provides simple cmdlets to display data graphically . one such cmdlet is out - chart , of which visualization 250 is an instance . the out - chart cmdlet displays a chart of the data that is pipelined in . the example visualization 250 graphically displays the relative sizes of all tables in a database by using the command 252 . in addition to a provider , the bare . net classes and methods of the . net assembly may be provided with composable cmdlets . fig7 shows an example powershell session with two example cmdlets 270 and 272 . scripts are another feature of the implementation . fig8 shows an example script 290 . the script is a simplified implementation of a common operation called refinement , in which a given input configuration is repeatedly “ relaxed ” via merging and reduction operations until it fits in the available storage , so that the expected cost of the resulting configuration is as low as possible . at each iteration , all possible transformations are calculated ( using a cmdlet ) and the one that is expected to result in the smaller execution cost is obtained . this process is repeated until a valid configuration is reached : other common algorithms may be similarly implemented , such as the relaxation based tuning approach in “ automatic physical database tuning : a relaxation - based approach ” ( n . bruno and s . chaudhuri ., in proceedings of the acm international conference on management of data ( sigmod ), 2005 ). one embodiment implements a version that handles constraint language , described in “ constrained physical design tuning ” ( n . bruno and s . chaudhuri , in proceedings of the international conference on very large databases ( vldb ), 2008 ). this script is called tuneconstrained - workload and takes as inputs a workload , a timeout , and a set of constraints . such a script may be implemented by using the . net classes exported by the high - level apis and may be implemented as a powershell script in fewer than 100 lines of code . fig9 - 11 show a sample interactive physical database design tuning session 310 . session 310 illustrates an interactive approach that provides flexibility and control during physical design tuning . the example uses the provider , cmdlets and scripts described earlier , as well as additional visualizations , among others . advanced dbas or other users may create their own scripts to further customize the physical design tuning experience . moreover , native powershell features , such as remoting ( which allows users to execute commands in other machines ) or eventing and automation can surely complement tuning scripts and provide added flexibility . the comments in session 310 explain the actions taken by the user . fig1 shows a process of interactive design tuning . the steps of fig1 can occur in any arbitrary order ; the order shown is for illustration only . using an implementation of the architecture described above , a user may con figure 330 a scenario by selecting workloads , setting parameters such as space constraint , and others . eventually the user invokes a command ( e . g ., “ refine - configuration ”) that communicates 332 the current scenario or configuration to a low - level api algorithm implemented by a dbms . the dbms may load 334 a workload , set parameters , and analyze the workload to find an optimal physical design , indicia of which ( e . g ., graphs , text ) is outputted 336 to the user . the user may decide 338 to perform additional steps , again , in arbitrary order . fig1 shows a diagram illustrating the free - form manner of user interaction possible for design tuning . the user continuously enters user input 360 , which may be specification commands 362 that specify the scenario such as a configuration , a workload or queries , databases , etc . generally , specification commands are handled by the shell , front - end , high - level api ( e . g ., assembly ), etc ., rather than the dbms . the user may also provide user input 360 in the form of commands 364 that invoke what - if functionality and other design functionality provided by the dbms via the low - level api and / or core dbms . while a command line shell / interpreter implementation has been described , graphical user interfaces can also be used , either as programs directly interfacing with the low - level api and high - level api , or by interfacing with another front - end such as a character - based shell environment . embodiments and features discussed above can be realized in the form of information stored in volatile or non - volatile computer or device readable media . this is deemed to include at least media such as optical storage ( e . g ., cd - rom ), magnetic media , flash rom , or any current or future means of storing digital information . the stored information can be in the form of machine executable instructions ( e . g ., compiled executable binary code ), source code , bytecode , or any other information that can be used to enable or configure computing devices to perform the various embodiments discussed above . this is also deemed to include at least volatile memory such as ram and / or virtual memory storing information such as cpu instructions during execution of a program carrying out an embodiment , as well as non - volatile media storing information that allows a program or executable to be loaded and executed . the embodiments and features can be performed on any type of computing device , including portable devices , workstations , servers , mobile wireless devices , and so on .