Wouldn't it be nice if your database were as easy to manage as your refrigerator, automatically regulating its operation based on the settings of a couple of knobs and initiating maintenance operations that would periodically "defrost" your data without your intervention? That's the goal of the Self-Managing And Resource Tuning (SMART) project at IBM: to reduce the cost of tuning and managing DB2 Universal Database (UDB).

Despite the dramatic recent growth in database sizes, total cost of ownership (TCO) is increasingly dominated by human costs. Thanks to Moore's Law and fierce competition, the per-unit cost of hardware and software continues to drop. But skilled application developers and DBAs are increasingly rare and expensive. A 1998 study by the Aberdeen Group showed that a five-year, 25-user implementation of a leading industrial RDBMS incurred 81 percent of its TCO from the human costs of training, maintenance, and implementation. Last year, a TCO report from D.H. Brown Associates that compared two leading database products for both data warehouse and online transaction processing (OLTP) applications found that human costs represented a large component of TCO in all cases.

Advances in database functionality and burgeoning requirements for database size, connectivity, availability, and heterogeneity increase the administrative burden. Data warehouses containing tens of terabytes of data aren't uncommon. Popular applications such as SAP typically create more than 20,000 tables and support thousands of users simultaneously. System designers grapple with complex decisions about hardware platforms, schema design, constraints and referential integrity, primary key and indexes, materialized views, the allocation of tables to disks, and shared-nothing, shared-everything, or SMP-cluster topology. Once designed, databases require substantial human input to build, configure, test, tune, and operate. DBAs handle table reorganization, data statistics collection, backup control, security modeling and administration, disaster recovery planning, configuration and performance tuning, problem analysis, and more.

And these pressures extend beyond databases to all IT departments. The complexity of modern hardware and software systems and a growing shortage of IT professionals threaten the growth of the IT industry, much as a shortage of human telephone operators threatened the growth of the telephone network before electronic switching for automated telephone calls.

IBM director of research Paul Horn last year issued a manifesto on autonomic computing to spur research and development of hardware and software systems that are more self-managing, self-configuring, self-healing, self-optimizing, and self-protecting. The term "autonomic" derives from the nervous system in the human body, which regulates heartbeat and breathing, heals wounds, processes food, and performs other essential functions automatically. Horn wrote, "Autonomic systems must anticipate needs and allow users to concentrate on what they want to accomplish rather than figuring how to rig the computing systems to get them there."

The DB2 SMART project is just one of many autonomic computing projects underway at IBM. Others include a similar SMART project for WebSphere and the eLiza project for IBM servers. Earlier this year, IBM named a vice president for autonomic computing (Alan Ganek) to foster and coordinate the autonomic computing initiatives.

DBAs IN A SMART WORLD

The DB2 SMART project aims to create technology for reducing human intervention and cost in DB2 operation. It builds on and extends existing self-managing technologies in DB2 and will result in a DB2 that can:

• Adjust every configuration parameter dynamically while the system is in use
• Expand and shrink memory usage, based on workload
• Automatically profile workloads and recommend and create indexes, partitioning, clustering, summary tables, and so on to improve performance
• Automatically detect the need for, estimate the duration of, and schedule maintenance operations such as reorganization, statistics collection, backup, copy, and rebind
• Observe actual performance and exploit that information to improve operations
• Recommend action when the performance isn't meeting the DBA's expectations
• Predict problems such as low memory or constrained disk space and notify someone by page or email in advance.

Will these developments mean the demise of the DBA? No. But they will mean the end of repetitive administrative tasks, freeing DBAs to spend more time on new applications and less time putting out fires. And DBAs will have the opportunity to evaluate and select recommendations before they're implemented. Once comfortable with system recommendations, DBAs can enable DB2 to take actions automatically and simply report on them.

When will DB2 manage itself? There's not a single feature or function that will make DB2 autonomic. Instead, IBM is developing new technologies that will be delivered across several releases. In the near term, you'll see infrastructure features that enable more autonomic behavior, wizards that guide your choices, and advisors that evaluate possibilities. But the SMART project won't end until autonomic awareness is as pervasive in the design process as performance and usability now are.

The SMART project involves two IBM research centers, two IBM development laboratories, and IBM's Centre for Advanced Studies, a collaboration of academic, government, and corporate research and development institutions. It also crosses platforms, with initial focus on z/OS and Linux, Unix, and Windows. In general, IBM intends to eventually support the same capabilities on all platforms.

DB2'S AUTONOMIC FEATURES

Although DB2 isn't yet as easy to manage as a refrigerator, it already sports several autonomic features. We'll first review some of the existing features across DB2 for z/OS and OS/390 and for Linux, Unix, and Windows.

Query Optimizer. The DB2 Query Optimizer automatically determines the best way to execute a declarative SQL query. It uses a combination of powerful query rewrite rules that transform queries written by the user (or a query generator) into standardized, easier-to-optimize queries and a detailed cost model that generates and evaluates a rich set of alternative plans for executing the query. The optimizer automatically determines whether any existing automatic summary tables (ASTs), also called materialized views, could benefit a query. If so, the optimizer routes the query to use the AST without altering the query in the user's application program. It uses statistics on the size of each table and the distribution of each column to model how many rows must be processed by any query a user might submit. It even adapts its cost model to the machine environment in which it's operating, automatically factoring in the speed of the CPU, the storage devices, and the network connecting machine clusters (in a shared-nothing environment) or sites (in a federated environment). The Query Optimizer in DB2 for the Linux, Unix, and Windows platforms even has a meta-optimizer that uses heuristic rules to automatically determine when a query is too complex to enumerate the possible join orders using dynamic programming. When this occurs, the optimizer instead chooses the cheapest join at each iteration in a "greedy" algorithm that saves on optimization time and space.

Automatic selection of degree of parallelism. In multi-CPU platforms, query optimization includes automatically setting and adjusting the degree of parallelism (the number of distinct tasks needed to perform an operation) for queries and utilities. For any query, DB2 analyzes how tables are accessed and where the bottlenecks exist and selects the optimal degree of parallelism at run time without external input. Complex queries benefit from intraquery parallel processing, and simple queries get to bypass the overhead (in context switching and communication costs) of the parallel processing infrastructure. Determining the optimal degree of parallelism for each query as it executes removes the need for complex load balancing during compilation.

The DB2 load utilities exploit a series of concurrent (parallel) subtasks for data prefetching, formatting, and writing to disk storage. Taking stock of the table's characteristics and the number of CPUs, the utility automatically determines the memory needed for buffering and sorting and the number of subagents necessary to achieve optimal I/O and SMP parallelism.

Detection of partial disk writes. DB2 uses a patented technique to protect data integrity by automatically detecting any corrupted data from incomplete I/Os when it reads a page from disk. The method exploits consistency bits to verify that a page being read into the buffer pool from the disk is not a partial page or hasn't been corrupted. When the page is read in, DB2 verifies that all of the bits are the same. If some of the bits are different, DB2 indicates a partial page write or disk corruption.

Application control and tuning. The most important aspects of application control are controlling application use and maximizing resources. DB2 provides mechanisms for controlling applications that are submitted for execution and those that are currently executing, based on the resources they consume. The first type of control is called a "predictive governor" because it uses the Query Optimizer's estimate of the relative resources each query is expected to consume to limit surges of arriving or long-running queries that could saturate the server. The second type is called a "reactive governor" because it monitors the actual resources consumed to prevent runaway queries from wasting resources. Examples include queries that have run too long, read or modified too many pages, or consumed too many locks without performing a COMMIT . Both types of governor provide an effective way to protect your system from errant applications that could starve currently executing queries for resources and increase system thrashing.

On the z/OS platform, the Resource Limit Facility (RLF) encompasses both predictive and reactive governors. The z/OS Workload Manager also balances the incoming workload across the Parallel Sysplex by offering applications connecting to DB2 the ability to run on the least-used DB2 member.

On the Linux, Unix, and Windows platforms, the DB2 Query Patroller provides the predictive governor; the reactive governor is called simply "the Governor." Guided by policies that a DBA establishes for each user, Query Patroller uses the current system load and the optimizer's estimate for each incoming query to prioritize and schedule its execution. Completion of a query's execution can optionally trigger automatic user notification by mail or with entries in a Job Accounting table to permit tracking the history of database usage. The Governor is controlled by a configuration file containing rules for limiting the resources consumed by specific applications or users, such as CPU time, running time, reads or writes, or locks acquired. Possible rule actions include increasing or decreasing the priority of the application or forcing it off the system.

Performance Expert. The new DB2 Performance Expert provides passive monitoring and also collects trace and monitor data in a performance data warehouse. This captured data can be queried by the DBA. A collection of reports can be run against the historical data (with correlation of system changes, such as increasing storage) to flag warnings and give advice. The Buffer Pool Analyzer, another Performance Expert component, collects buffer pool activity data and models changes to the objects in the buffer pools (including sizes) so a DBA can see the effects without having to make the changes to the production system. Other tools from the IBM Data Management Tools group offer the ability to capture and analyze performance data and make recommendations for queries. See Resources for more information.

DB2 FOR LINUX, UNIX, AND WINDOWS

A few existing features are specific to each platform. We'll start with those features specific to the distributed platforms.

Index Wizard. The DB2 Index Wizard, introduced with version 6 in 1999, aids physical database design by recommending indexes for tables, based on a workload of one or more SQL queries (including INSERT s, UPDATE s, and DELETE s) that may be automatically captured or supplied by the user. The Index Wizard exploits the Query Optimizer's detailed performance model and suggests and evaluates the most promising candidate indexes, improving search efficiency. Using the Query Optimizer code itself saves maintaining redundant external code and ensures that the optimizer will actually choose the recommended indexes for the workload. The Index Wizard is a utility running as a client application that invokes the DB2 compiler in two new EXPLAIN modes: RECOMMEND INDEXES and EVALUATE INDEXES . In RECOMMEND INDEXES mode, the optimizer creates "virtual index" descriptors for various combinations of columns that can apply predicates, create "interesting" orders (for ORDER BY , GROUP BY , or joins), or provide index-only access for the given query. It then derives statistics for these virtual indexes and goes through the normal process of query optimization to pick the best plan using virtual as well as real indexes. If the plan chosen references a virtual index, then it's reported as a candidate index to the client utility for consideration in the EVALUATE INDEXES mode. The Index Wizard recommends indexes to create, estimates their storage size and the performance impact on each query in the specified workload, and identifies indexes that are no longer needed.

You can use the Index Wizard to recommend or affirm indexes on DB2 for the z/OS platform if you capture a workload on z/OS and create a modeling database on Linux, Unix, or Windows. The same technology recommends indexes that you can then create on the z/OS platform. For more information, see Resources .

Service Utility (db2support). To simplify the process of data collection and problem determination in service situations, DB2 includes a utility named "db2support" that automatically determines what diagnostic information IBM Service would need, then collects and packages that information into a single zip file. The file includes hardware characteristics (including CPUs, network, and storage specification), operating system and database product levels and configuration, and a number of database diagnostic files and control structures. The system description data is stored in HTML format for convenient browsing. Additionally, db2support provides an optional interactive mode in which the user is guided through a decision tree of specific questions about the problem scenario. The resulting dialog between the utility and the human operator is captured in an XML file. All of this information is collected into a single file and compressed for efficient transmission. By automatically collecting and capturing a comprehensive set of system information, this utility simplifies product support and reduces the resolution time.

Performance Configuration Wizard. The Performance Configuration Wizard automatically determines the best values for more than 35 configuration parameters critical to system performance, including the allocation of system memory for major database operations (such as data caching, sorting, and networking) and operational parameters (such as the number of database server agents, I/O subagents, and logging frequency). To do so, it evaluates the setting of each configuration parameter based on characteristics of the database system that it senses automatically (including system RAM, number of storage disks, and number of CPUs) and characteristics of the workload specified by the caller in response to a handful of simple questions. The user questions assume the lowest skill level. The Performance Configuration Wizard derives the value of each configuration parameter as a weighted function of each system characteristic. However, the allocation of system memory to the database consumers (data cache, sort, network memory, and so on) must be treated as a zero-sum game. These parameters are determined in a combined model that takes account of each memory consumer's constraints, based on the database architecture and the system memory available.

You can invoke the wizard through either a graphical interface or a programmable API. A number of commercial database applications that use DB2 for their relational stores invoke this advisor through the programmable API.

Z/OS TODAY

Now let's look at some of the existing autonomic features of DB2 on the z/OS platform, by category.

System monitoring and control. With each new release of DB2, there are new switches and knobs referred to as system parameters or ZPARM s. In v.7, most of these parameters can be changed online. From this feature, many other autonomic features can be developed because these parameters can be changed without application outage. Version 7 also introduced Real Time Statistics. Complementary to RUNSTATS data, these statistics keep track of the number of INSERT s, UPDATE s, and DELETE s since the last REORG or RUNSTATS . DB2 also tracks the number and percentage of changed pages. You can use these statistics to determine whether to perform a REORG , RUNSTATS , or COPY utility.

DB2 on the z/OS platform has the luxury of the z/OS Workload Manager. The Workload Manager provides goal-based performance management at the operating system level, which allows mixed workloads to share resources and prevents long-running work (such as some queries or utilities) from affecting the performance of short-running work. This is accomplished by using period aging techniques to "throttle" the longer-running work.

Other system management features in DB2 for z/OS include automatic sort technique selection, automatic storage pool contraction in the main DB2 address space, and adaptive buffer management. Adaptive buffer management includes techniques such as dynamically enabling or disabling prefetch operations based on the current characteristics of the access path and changing prefetch quantities on the fly.

Operational maintenance and recovery. Along with RUNSTATS and COPY , the REORG utility can run concurrently with applications that update the objects being reorganized. This ability applies to tablespaces as well as indexes. To help enable automated operations, both the COPY and REORG utilities permit you to specify a criterion that controls that utility's behavior. For example, you may want to skip taking an image copy of a tablespace or index if less than 2 percent of the pages have been updated. And, you may want to take an incremental copy if less than 15 percent but more than 2 percent of pages have been changed. If more than 15 percent of the pages have been updated, you may want to take a full image copy. These thresholds are parameters specified on the utility invocation. Similarly, you can provide criteria for a REORG utility.

During a recovery operation, if an image copy is determined to be corrupt, DB2 will automatically fall back to a different image copy. If it detects a broken or corrupt page, DB2 starts a recovery process to fix this condition automatically. In a Parallel Sysplex, if a Coupling Facility fails for any reason, the system automatically switches over to a different Coupling Facility, with no outage to the application.

Many z/OS DBAs use the DB2 Automation Tool for detecting exception conditions and automatically generating utility jobs that can be scheduled. (For more information about how customers use this tool, see the online only article "Tool Tales: Customers Report From the Field" .

Latest Developments

The latest round of new DB2 tools and DB2 UDB v.8.1 for Linux, Unix, and Windows bear the early fruit of the DB2 SMART project's efforts. We'll talk about a sample of these new features.

Recovery Expert. Announced earlier this year, the DB2 Recovery Expert combines log analysis, filtered log subset creation, and an object definition version repository to enable the user to specify recovery goals. This tool analyzes the recovery assets available and recommends a technique to be selected. For example, if a set of tables needs to be recovered to a point in time five minutes ago, Recovery Expert may recommend that the log be analyzed in order to generate UNDO SQL to effect the recovery. While this product was announced only on DB2 for the Linux, Unix, and Windows platforms, many of its components are available today as separate products on z/OS: DB2 Log Analysis Tool, DB2 Change Accumulation Tool, and DB2 Object Restore Tool.

Maintenance Advisor. The Maintenance Advisor is a cross-platform tool that examines DB2 statistics (real-time statistics on z/OS) and makes recommendations on what maintenance utilities should be run. It can build scripts or JCL and can schedule maintenance tasks. Maintenance Advisor includes a GUI tool and a stored procedure API and command-line interface.

SMART IN DB2 v.8.1

DB2 UDB v. 8.1 for the Linux, Unix, and Windows platforms contains a number of new, SMART features. Here's a sample of the major ones.

Configuration Advisor. The Performance Configuration Wizard underwent a significant refinement and emerged as the Configuration Advisor. Recent experiments with the new algorithms have produced dramatic improvements, particularly for OLTP and batch database systems. Figure 1 shows the results of two experiments using an industry standard OLTP benchmark. The experiments were performed on two different workloads. For each workload, the system throughput was measured using the default out-of-the-box settings, the settings recommended by the new Configuration Advisor, and the settings determined by a human expert who was given period of several days to tune the database configuration. For both workloads, the Configuration Advisor's settings outperformed the default settings by several factors. Even more surprising, the Configuration Advisor achieved 91.3 percent of the throughput performance achieved by the human expert for the first workload and 98.4 percent for the second workload.

Figure 1 : Comparing the system throughput performance of Configuration Advisor settings to default and expert human settings.

Autonomic health assessment. Early in the SMART project, a survey of DBAs revealed that a common challenge is easily assessing whether DB2 is firing on all cylinders and determining the best remedy if it isn't. The SMART answer to this is a new facility called the Health Monitor, which consists of a monitor agent that runs unattended and within the database engine, and several tools for obtaining health status, resolution recommendations, and monitor configuration. The Health Monitor looks for signs of unhealthiness within the database and issues health alerts via email messages, pages, or records written to the notification log. It can also run corrective scripts or tasks when health alerts are issued. The supporting tools (used to view real-time and historical health alerts, display and enable optional execution of suggested resolution actions, and support configuration changes) are the Health Center GUI application (desktop and Web versions), command line processor commands, and "C" APIs. The Health Monitor covers such aspects of database health as storage usage, memory consumption for caching and sorting, logging behavior, and application concurrency.

COMING SOON

These recently announced autonomic features in DB2 are only the beginning of a stream of autonomic technology that will be added by the SMART team over the next releases of DB2, beginning with key infrastructure capabilities and tools that remove the drudgery from DBA tasks and evolving to more sophisticated tools that will take DB2 to the next level of system automation and self-control. Although we can't provide a full description of current research projects, this subset of projects provides some interesting insight into DB2's future capabilities.

Design Advisor. As we noted earlier, the Index Wizard only recommends indexes to create or drop. But selecting indexes is only one of the many physical database design decisions that DBAs make. Redundantly materializing the results of aggregation queries in ASTs can significantly improve the performance of queries, but can also consume disk space and require updates when the tables from which they are derived are updated. In v. 8.1 of DB2 UDB for Linux, Unix, and Windows, ASTs have been extended to include nonaggregating queries and renamed materialized query tables (MQTs) to more accurately reflect this wider role. This same functionality is expected soon for the z/OS platform.

Judiciously choosing which MQTs to define provides yet another challenge to even knowledgeable DBAs. And MQTs, as stored tables themselves, require indexes to perform well, too. Furthermore, in a partitioned environment, these MQTs (and all base tables) must be optimally partitioned among the nodes to minimize the repartitioning needed by queries performing joins, aggregates, and so on. These design decisions interact in ways that are hard for even seasoned experts to predict.

The Index Wizard on the Linux, Unix, and Windows platforms will be expanded to augment its recommendation of indexes with recommendations of the best MQTs and partitioning for each stored table. To better reflect this broader role, its name has been changed to the Design Advisor. As before, the Design Advisor will exploit the DB2 Query Optimizer's detailed cost model to recommend the best candidates for each query and evaluate global solutions efficiently. The new MQT component will exploit new multiquery optimization to find MQTs that can benefit many queries, rather than simply precomputing a few key queries. It will also optionally use sampling of the contents of selected candidate MQTs to better estimate their ultimate size. The new partitioning component will exploit the interesting partitions already computed by the Query Optimizer for each query, generating alternative plans for each such partition and then letting the Query Optimizer choose the preferred plan. It will then evaluate all queries in the workload using just one of these candidate partitions for each table, to find the best global solution.

Online schema changes (schema evolution). One of the key pieces of autonomic infrastructure in DB2 for z/OS, this feature will enable you to change almost any schema aspect without incurring an outage or invalidating packages or views. Why is this important? Successful applications aren't static. Tables are modified, columns are dropped from tables and indexes, data types for columns are changed, indexes need to be renamed, partitions need to be added, and so on. These changes must be made online. In some cases, multiple changes need to be made before a REORG utility can fix all of the objects to a single version of the schema.

Utility enhancements. Also on DB2 for z/OS, look for online enhancements to utilities such as LOAD RESUME and the capability to build indexes while allowing full online SQL access. A statistics advisor will tell you if you should collect column statistics or nonuniform distribution data on nonindexed columns, as is done on DB2 for the Linux, Unix, and Windows platforms. (Currently, RUNSTATS on DB2 for z/OS only collects these statistics on indexed columns.) Have you ever wanted to take a partitioned table and adjust the partition range keys so that all of the partitions were more equally balanced? Well, look for a rebalance partitions extension to the REORG utility.

Managed System Infrastructure (msys) for Setup. Msys is being explored as a way to deliver similar functionality as the Configuration Advisor to the z/OS platform. Through an interviewlike process, a new DB2 subsystem or data sharing group can be installed with appropriate system parameter settings in a fraction of the time needed for a traditional installation.

Exploitation of real-time statistics. With the presence of the real-time statistics on z/OS (and soon on the Linux, Unix, and Windows platforms) providing infrastructure, the next step is to exploit them. The Maintenance Advisor we mentioned previously will do just that. Look for the DB2 Automation Tool to use these statistics, too.

FARTHER OUT

The features we've covered are only a small sample of what's underway through SMART. Also in the research pipeline are:

Table grouping. Have you ever wanted the ability to discover or describe a set of related objects that could be used as input to other processes? Well, this is exactly what the Data Management Tools group is working on. This grouping function can discover table relationships from system-managed referential integrity (RI), triggers, SQL statements in bound packages, and even the DB2 logs. User-managed RI can also be defined to this grouping facility. The result is an object relationship repository that can be used by other tools such as the DB2 Recovery Expert. So, when you recover two tables, Recovery Expert may remind you that a third table has recently been created that has system-managed RI to one of these tables and that a fourth table was found to be updated in the same unit of work as the first table in a recent inspection of the DB2 log. Recovery Expert will help you determine the set of tables that need to be recovered together in the recovery operation. Other tools being developed will exploit this grouping information, as well.

Learning in query optimization. The cost model the DB2 Query Optimizer uses depends on estimates of the number of rows to be processed at each step of the plan. This so-called cardinality model, in turn, depends on the statistics on the database, which are used to estimate the selectivity of each predicate in the query. Updating the statistics after each update would cause a locking hot spot, so they're updated periodically with the RUNSTATS utility. Therefore, the statistics may be temporarily out of date or incomplete. And the Query Optimizer multiplies the selectivities for each predicate together, essentially assuming that all predicates are independent. The assumptions underlying the Query Optimizer's model can, when violated, occasionally generate errors significant enough to adversely affect the choice of plan.

The DB2 Learning Optimizer (LEO), being developed as part of the SMART project, automatically self-validates the Query Optimizer's cardinality model. LEO uses the execution module to collect the actual cardinalities at each step of the plan. After the query completes, LEO compares these actuals to the optimizer's estimates, to produce adjustment factors to be exploited by future optimization of queries that have similar predicates. In this way, LEO actually learns from its mistakes over time by accumulating additional statistics on the database where it's queried the most. Note that LEO's approach is very general and can correct the result of any sequence of operations, not just the access of a single table or even the application of predicates. And although LEO is being prototyped first on DB2 for Linux, Unix, and Windows, the approach is applicable to all DB2 products.

Meta-Optimizer. DB2 for Linux, Unix, and Windows platforms lets users adjust the amount of optimization each query experiences. If the user specifies optimization level 5 (the system default), DB2 will automatically adjust, using some simple heuristics about the query's complexity and the size of the database. A more sophisticated model for this Meta-Optimizer in development will automatically and reliably determine the appropriate amount of optimization for each query.

KEEPING THINGS HUMMING

The many self-managing features you enjoy in DB2 — and many more you may not even be aware of — are just the tip of the iceberg. In upcoming releases, look for many more SMART features in DB2 and increasingly autonomic behavior from many other IBM hardware and software products. Of course, the ultimate goal is to reduce what you see and take care of everything behind the scenes — just as your refrigerator does.

Sam S. Lightstone is manager of DB2 performance and advanced technology at the IBM Canada Toronto Laboratory and manages the DB2 SMART project. You can reach him at light@ca.ibm.com .

Guy M. Lohman is manager of advanced optimization at the IBM Almaden Research Center in San Jose, Calif. You can reach him at lohman@almaden.ibm.com .

Bryan F. Smith is a senior technical staff member in the Data Management Tools Group at IBM Silicon Valley Laboratory in San Jose, Calif. You can reach him at bfsmith@us.ibm.com .

Randy Horman is manager of administration tools development at the IBM Canada Toronto Laboratory. You can reach him at horman@ca.ibm.com .

Jim Teng is a distinguished engineer for DB2 for z/OS and OS/390 at IBM Silicon Valley Laboratory in San Jose, Calif. You can reach him at jteng@us.ibm.com .