Windows/SQL server Physical Disk I/O Bottlenecks check and Resolution

PhysicalDisk Object: Avg. Disk Queue If your disk queue length frequently exceeds a value of 2 during peak usage of SQL Server, you might have an I/O bottleneck.

Avg. Disk Sec/Read is the average time, in seconds, of a read of data from the disk. The following list shows ranges of possible values and what the ranges mean:
  •Less than 10 ms - very good
  •Between 10 - 20 ms - okay
  •Between 20 - 50 ms - slow, needs attention
  •Greater than 50 ms – Serious I/O bottleneck

Physical Disk: %Disk Time is the percentage of elapsed time that the selected disk drive was busy servicing read or write requests. A general guideline is that if this value is greater than 50 percent, there is an I/O bottleneck.

Avg. Disk Reads/Sec is the rate of read operations on the disk. Ensure that this number is less than 85 percent of the disk capacity. The disk access time increases exponentially beyond 85 percent capacity.

Avg. Disk Writes/Sec is the rate of write operations on the disk. Ensure that this number is less than 85 percent of the disk capacity. The disk access time increases exponentially beyond 85 percent capacity.
 •Raid 0 -- I/Os per disk = (reads + writes) / number of disks
 •Raid 1 -- I/Os per disk = [reads + (2 * writes)] / 2
 •Raid 5 -- I/Os per disk = [reads + (4 * writes)] / number of disks
 •Raid 10 -- I/Os per disk = [reads + (2 * writes)] / number of disks

For example, you might have a RAID-1 system with two physical disks with the following values of the counters.
Disk Reads/sec            80
Disk Writes/sec           70
Avg. Disk Queue Length    5

In that case, you are encountering (80 + (2 * 70))/2 = 110 I/Os per disk and your disk queue length = 5/2 = 2.5, which indicates a borderline I/O bottleneck.

You can also identify I/O bottlenecks by examining the latch waits. These latch waits account for the physical I/O waits when a page is accessed for reading or writing and the page is not available in the buffer pool. When the page is not found in the buffer pool, an asynchronous I/O is posted and then the status of the I/O is checked. If the I/O has already completed, the worker proceeds normally. Otherwise, it waits on PAGEIOLATCH_EX or PAGEIOLATCH_SH, depending upon the type of request. You can use the following DMV query to find I/O latch wait statistics.

Select  wait_type,
        waiting_tasks_count,
        wait_time_ms
from    sys.dm_os_wait_stats
where    wait_type like 'PAGEIOLATCH%'
order by wait_type

A sample output follows.
wait_type       waiting_tasks_count  wait_time_ms   signal_wait_time_ms
-----------------------------------------------------------------------
PAGEIOLATCH_DT  0                    0                    0
PAGEIOLATCH_EX  1230            791                 11
PAGEIOLATCH_KP  0                    0                    0
PAGEIOLATCH_NL  0                    0                    0
PAGEIOLATCH_SH  13756          7241                 180
PAGEIOLATCH_UP  80                   66                   0

When the I/O completes, the worker is placed in the runnable queue. The time between I/O completions until the time the worker is actually scheduled is accounted under the signal_wait_time_ms column. You can identify an I/O problem if your waiting_task_counts and wait_time_ms deviate significantly from what you see normally. For this, it is important to get a baseline of performance counters and key DMV query outputs when SQL Server is running smoothly. These wait_types can indicate whether your I/O subsystem is experiencing a bottleneck, but they do not provide any visibility on the physical disk(s) that are experiencing the problem.

You can use the following DMV query to find currently pending I/O requests. You can execute this query periodically to check the health of I/O subsystem and to isolate physical disk(s) that are involved in the I/O bottlenecks.
select
    database_id,
    file_id,
    io_stall,
    io_pending_ms_ticks,
    scheduler_address
from    sys.dm_io_virtual_file_stats(NULL, NULL)t1,
        sys.dm_io_pending_io_requests as t2
where    t1.file_handle = t2.io_handle

A sample output follows. It shows that on a given database, there are three pending I/Os at this moment. You can use the database_id and file_id columns to find the physical disk the files are mapped to. The io_pending_ms_ticks values represent the total time individual I/Os are waiting in the pending queue.

Database_id    File_Id io_stall    io_pending_ms_ticks    scheduler_address
----------------------------------------------------------------------
6        1        10804        78            0x0227A040
6        1        10804        78            0x0227A040
6        2        101451    31            0x02720040


Resolution
When you see an I/O bottleneck, your first instinct might be to upgrade the I/O subsystem to meet the workload requirements. This will definitely help, but before you go out and invest money in hardware, examine the I/O bottleneck to see whether it is the result of poor configuration and/or query plans. We recommend you to follow the steps below in strict order.
 1.Configuration: Check the memory configuration of SQL Server. If SQL Server has been configured with insufficient memory, it will incur more I/O overhead. You can examine the following counters to identify memory pressure:
   •Buffer Cache hit ratio
   •Page Life Expectancy
   •Checkpoint pages/sec
   •Lazywrites/sec

For more information about memory pressure, see Memory Bottlenecks earlier in this paper.
  2.Query Plans: Examine execution plans and see which plans lead to more I/O being consumed. It is possible that a better plan (for example, index) can minimize I/O. If there are missing indexes, you may want to run Database Engine Tuning Advisor to find missing indexes.

The following DMV query can be used to find which batches or requests are generating the most I/O. Note that we are not accounting for physical writes. This is okay if you consider how databases work. The DML and DDL statements within a request do not directly write data pages to disk. Instead, the physical writes of pages to disks is triggered by statements only by committing transactions. Usually physical writes are done either by checkpoint or by the SQL Server lazy writer. You can use a DMV query like the following to find the five requests that generate the most I/Os. Tuning those queries so that they perform fewer logical reads can relieve pressure on the buffer pool. This enables other requests to find the necessary data in the buffer pool in repeated executions (instead of performing physical I/O). Hence, overall system performance is improved.

Here is an example of a query that joins two tables with a hash join.
create table t1 (c1 int primary key, c2 int, c3 char(8000))
   create table t2  (C4 int, c5 char(8000))
go

--load the data
declare @i int
select @i = 0
while (@i < 6000)

begin
    insert into t1 values (@i, @i + 1000, 'hello')
   insert into t2 values (@i,'there')
   set @i = @i + 1
end

--now run the following query
select c1, c5
from t1 INNER HASH JOIN t2 ON t1.c1 = t2.c4
order by c2

Run another query so that there are two queries to look at for I/O stats
select SUM(c1) from t1

These two queries are run in the single batch. Next, use the following DMV query to examine the queries that generate the most I/Os

SELECT TOP 5
    (total_logical_reads/execution_count) AS avg_logical_reads,
    (total_logical_writes/execution_count) AS avg_logical_writes,
    (total_physical_reads/execution_count) AS avg_phys_reads,
    execution_count,
    statement_start_offset as stmt_start_offset,
    (SELECT SUBSTRING(text, statement_start_offset/2 + 1,
        (CASE WHEN statement_end_offset = -1
            THEN LEN(CONVERT(nvarchar(MAX),text)) * 2
                ELSE statement_end_offset
            END - statement_start_offset)/2)
     FROM sys.dm_exec_sql_text(sql_handle)) AS query_text,
      (SELECT query_plan from sys.dm_exec_query_plan(plan_handle)) as query_plan
FROM sys.dm_exec_query_stats
ORDER BY (total_logical_reads + total_logical_writes)/execution_count DESC

You can, of course, change this query to get different views on the data. For example, to generate the five requests that generate the most I/Os in single execution, you can order by:
    (total_logical_reads + total_logical_writes)/execution_count
Alternatively, you may want to order by physical I/Os and so on. However, logical read/write numbers are very helpful in determining whether or not the plan chosen by the query is optimal. The output of the query is as follows.

avg_logical_reads    avg_logical_writes   avg_phys_reads     
-----------------    ------------------   ---------------
16639            10               1098
6023            0               0

execution_count      stmt_start_offset
---------------      -----------------
1                0
1                154

Query_text                          Query_plan                      
-----------------------------------          -----------
select c1, c5  from t1 INNER HASH JOIN …   
select SUM(c1) from t1                     

The output tells you several important things. First, it identifies the queries that are generating the most I/Os. You can also look at the SQL text to see whether the query needs to be re-examined to reduce I/Os. Verify that the query plan is optimal. For example, a new index might be helpful. Second, the second query in the batch does not incur any physical I/Os because all the pages needed for table t1 are already in the buffer pool. Third, the execution count can be used to identify whether it is a one-off query or the one that is executed frequently and therefore needs to be looked into carefully.

3.    Data Compression: Starting with SQL Server 2008, you can use the data compression feature to reduce the size of tables and indexes, thereby reducing the size of the whole database. The compression achieved depends on the schema and the data distribution. Typically, you can achieve 50-60% compression. We have seen up to 90% compression in some cases. What it means to you is that if you are able to compress you active data 50%, you have in effect reduced your I/O requirements by half. Data compression comes at the cost of additional CPU, which needs to be weighed in for your workload. Here are some general strategies.

First, why isn’t compressing the whole database blindly such a good idea? Well, to give you an extreme example, if you have a heavily used table T with 10 pages in a database with millions of pages, there is no benefit in compressing T. Even if SQL Server could compress 10 pages to 1 page, you hardly made a dent in the size of the database, but you did add some CPU overhead instead. In a real-life workload, the choices are not this obvious, but this example shows that you must look before you compress. Our recommendation is this: Before you compress an object (for example, a table index or a partition), look at its size, usage, and estimated compression savings by using the sp_estimate_data_compression_savings stored procedure.

Let us look at each of these in some detail:

•    If the size of the object is much smaller than the overall size of the database, it does not buy you much.

•    If the object is used heavily both for DML and SELECT operations, you will incur additional CPU overhead that can impact your workload, especially if it makes it CPU bound. You can use sys.dm_db_index _operational_stats to find the usage pattern of objects to identify which tables, indexes, and partitions are being hit the most.

•    The compression savings are schema-dependent and data-dependent, and in fact, for some objects, the size after compression can be larger than before, or the space savings can be insignificant.

If you have a partitioned table where data in some partitions is accessed infrequently, you may want to compress those partitions and associated indexes with page compression. This is a common scenario with partitioned tables where older partitions are referenced infrequently. For example, you might have a table in which sales data is partitioned by quarters across many years. Commonly the queries are run on the current quarter; data from other quarters is not referenced as frequently. So when the current quarter ends, you can change the compression setting for that quarter’s partition.

For more information about data compression, see the SQL Server Storage Engine Blog (http://blogs.msdn.com/sqlserverstorageengine/archive/tags/Data+Compression/default.aspx) and SQL Server 2008 Books Online.

4.    Upgrading the I/O Subsystem: If you have confirmed that SQL Server is configured correctly and examined the query plans and you are still experiencing I/O bottlenecks, the last option left is to upgrade your I/O subsystem to increase I/O bandwidth:

•    Add more physical drives to the current disk arrays and/or replace your current disks with faster drives. This helps to boost both read and write access times. But don't add more drives to the array than your I/O controller can support.

•    Add faster or additional I/O controllers. Consider adding more cache (if possible) to your current controllers.

Electronic Commerce(EC)电子商务常识

电子商务模式（常见类）：
B2B模式，Business to Business-企业对企业，例子：阿里巴巴，生意宝（网盛科技）、慧聪网。
B2C模式，Business to Customer-企业对个人，例子：亚马逊，当当，凡客，时尚起义，走秀网。
C2C模式，Customer to Customer－个人对个人，例子：ebay，淘宝，拍拍，易趣。
电子商务专业名词（常见类）：
SEM：Search Engine Marketing的缩写，意即搜索引擎营销。
EDM：Electronic Direct Marketing的缩写，就是电子邮件营销。
CPS：Cost Per Sales的缩写,即销售分成。
CPA ： Cost Per Action，每次动作成本，即根据每个访问者对网络广告所采取的行动收费的定价模式。对于用户行动有特别的定义，包括形成一次交易、获得一个注册用户、或者对网络广告的一次点击等。
CPM：(Cost Per Mille，或者Cost Per Thousand；Cost Per Impressions) 每千人成本。
CPC：(Cost Per Click；Cost Per Thousand Click-Through) 每点击成本。
ROI：Return On Investment的缩写，投资报酬率。
SEO：Search Engine Optimization的缩写，搜索引擎优化。
转化率：Conversion Rate的缩写，是指访问某一网站访客中，转化的访客占全部访客的比例。
UV：Unique Vister的缩写，独立访客。
AdWords：Google的关键词竞价广告。
Alexa：Alexa.com是专门发布网站世界排名的网站，网站排名有两种：综合排名和分类排名。
二跳率：二跳率，由99click最先提出，网站页面展开后，用户在页面上产生的首次点击被称为 “二跳”，二跳的次数即为”二跳量”。二跳量与浏览量的比值称为页面的二跳率。
跳出率：跳出率是指浏览了一个页面就离开的用户占一组页面或一个页面访问次数的百分比。
人均访问页面： PV总和除以IP，即可获得每个人平均访问的页面数量。至少人均访问页面需要超过10个以上，才算是优质的用户。
电子商务商务常见营销方式：
1.网络媒体：门户网站广告，客户端软件广告。
2.SEM：竞价排名，联盟广告。
3.EDM邮件营销：内部邮件群发，第三方平台，数据库整合营销等方式。
4.社区营销：BBS推广（发帖和活动）SNS。
5.CPS\代销：销售分成（一起发，成果网，创盟）。
6.SEO：搜索引擎优化。
7.积分营销：积分兑换，积分打折，积分购买等。
8.DM目录：传统单张目录，如麦考林，红孩子，凡客，PPG。
9.线下活动：会展，体验店等。
10.传统媒体：电视电台，报刊杂志。
网络营销主要机构：
3大在线媒体广告代理服务商：好耶，华扬联众，龙拓。
3大在线营销创意服务商：奥美互动，阳狮互动Digitas，安瑞索思。
3大网络联盟广告服务商：亿码（一起发），linkTech，alimama。
3大小企业的基础性在线营销服务商：中企动力，上海火速，深圳时代赢客。
3大网络公关公司：蓝色光标，宣亚公关，新华美通。
3大SEO服务商：王通，点石团队，新竞争力。
3大营销2.0机构：陈格雷，陈墨网络推广机构，浪兄推广机构。
用数字衡量网络营销效果：
－－网络营销效果可以100%以数字来衡量
1.访问页面：网络推广的访问者访问 5个页面以上才是有效流量。访问10个页面以上是高质量的流量，访问2个以下页面是垃圾流量。
2.停留时间：超过3分钟才是有效流量；超过6分钟是高质量流量；小于1分钟的是垃圾流量。
3.二跳率数据：推广来主页二跳率70%以上是高质量流量。
4.转化率数据：推广购买转化率为1%以上为高质量流量。
网络营销需要辩别好：真实流量与流量，有效流量与流量，自然流量与购买流量，PV高的流量与PV低的流量，商业流量与娱乐流量。
如何用数字判断一个网站：
1.访问量：alexa，chinaz查询工具。
2.网络流行度：搜索网站名，搜索结果越多相对来说越流行。
3.行业排名：查询艾瑞的排名。
4.网络新闻曝光率：用baidu新闻搜索。
5.SEO表现：收录与PR，排名。
6.百度指数：百度指数是用以反映关键词在过去30天内的网络曝光率及用户关注度。
7.每天新增注册用户数＝UV*1%＝80000*1%＝80
8.活跃用户＝注册用户/10＝100000*10%＝10000
9.最高同时在线＝活跃用户*20%＝10000*20%＝2000
10.收费交易客户数＝活跃用户*5%＝10000*5%＝500
11.销售额：收费交易客户数*商品平均价格200＝10000

TD USD Check/fund to USA reference solution

Personal cheques are available on U.S. Dollar chequing accounts with us, however, they are encoded for clearance through the Canadian clearing system only. You may have difficulty clearing the cheques through the U.S.
clearing system. This is due to changes in U.S. Federal banking regulations. However, you do have alternatives.

The first alternative is to purchase U.S. Dollar drafts at the branch. If you have the Borderless service set up on your account (for $4.95 per month with unlimited transactions), U.S. Dollar drafts are free. If you do not have the Borderless service, U.S. Dollar drafts can be purchased for $6.50 (you'll also have to pay $1.00 for each individual transaction). This would be the most economical way to send funds to the United States. Information about the Borderless service can be found at:

http://www.tdcanadatrust.com/accounts/usaccount.jsp

Another alternative would be to send an electronic wire transfer. This option is costlier and you will be charged $30.00 to $50.00 per transfer.
However, an electronic transfer is very fast and should arrive in the beneficiary account within a few business days.

If your payments in the United States can be completed via credit card, then please feel free to view the information about the TD U.S. Dollar Advantage Visa and apply on-line through the following address:

http://www.tdcanadatrust.com/tdvisa/usd.jsp

You also have the option of opening a U.S. Dollar account at TD Waterhouse Bank, our U.S. subsidiary. TD Waterhouse Bank is an affiliated bank in the United States that offers chequing accounts. More detailed information can be found at:

http://www.tdwaterhouse.com/banking/welcome/index.html

Regular Traveller's Cheques are available for Borderless service account holders with no commission fee. The commission if you don't have the Borderless service is 1%. The commission fee for dual signature cheques is 1.75%.

Cheques for a U.S. Dollar account are free (basic style, personalized) if you have the Borderless service. If not, an order of cheques will cost about $15.00 to $20.00 depending on your provice of residence, with shipping and handling and taxes included.

SQL query perfomance check method

you can check that how long each query takes to run... this should give you some idea which one performs better...

Code Snippet

DBCC DROPCLEANBUFFERS

SET STATISTICS IO ON

SET STATISTICS TIME ON

select top 10000 * from Table

SET STATISTICS TIME OFF

SET STATISTICS IO OFF

DBCC DROPCLEANBUFFERS

SET STATISTICS IO ON

SET STATISTICS TIME ON

Set rowcount 10000

Select * From Table

SET STATISTICS TIME OFF

SET STATISTICS IO OFF

SQL SERVER – Insert Data From One Table to Another Table – INSERT INTO SELECT – SELECT INTO TABLE

Following three questions are many time asked on this blog.

How to insert data from one table to another table efficiently?
How to insert data from one table using where condition to anther table?
How can I stop using cursor to move data from one table to another table?

There are two different ways to implement inserting data from one table to another table. I strongly suggest to use either of the method over cursor. Performance of following two methods is far superior over cursor. I prefer to use Method 1 always as I works in all the case.

Method 1 : INSERT INTO SELECT
This method is used when table is already created in the database earlier and data is to be inserted into this table from another table. If columns listed in insert clause and select clause are same, they are are not required to list them. I always list them for readability and scalability purpose.
USE AdventureWorks
GO
----Create TestTable
CREATE TABLE TestTable (FirstName VARCHAR(100), LastName VARCHAR(100))
----INSERT INTO TestTable using SELECT
INSERT INTO TestTable (FirstName, LastName)
SELECT FirstName, LastName
FROM Person.Contact
WHERE EmailPromotion = 2
----Verify that Data in TestTable
SELECT FirstName, LastName
FROM TestTable
----Clean Up Database
DROP TABLE TestTable
GO

Method 2 : SELECT INTO
This method is used when table is not created earlier and needs to be created when data from one table is to be inserted into newly created table from another table. New table is created with same data types as selected columns.
USE AdventureWorks
GO
----Create new table and insert into table using SELECT INSERT
SELECT FirstName, LastName
INTO TestTable
FROM Person.Contact
WHERE EmailPromotion = 2
----Verify that Data in TestTable
SELECT FirstName, LastName
FROM TestTable
----Clean Up Database
DROP TABLE TestTable
GO

Both of the above method works with database temporary tables (global, local). If you want to insert multiple rows using only one insert statement refer article SQL SERVER – Insert Multiple Records Using One Insert Statement – Use of UNION ALL.

source: http://blog.sqlauthority.com/2007/08/15/sql-server-insert-data-from-one-table-to-another-table-insert-into-select-select-into-table/

Solve ‘String or binary data would be truncated’ sql error

The error ‘String or binary data would be truncated’ can be annoying.  It occurs when you try to insert or update a string or binary column with a value that is too large. Recently I was trying to INSERT from a SELECT from one table to another and I got this error. It can be a pain tracking down the cause, especially if there are a large number of columns or a large dataset involved.
In the past I’ve written queries to give me the LEN for each column, but again if there are a large number of columns involved this can be very time consuming.
Below is a way of identifying which rows are causing the problem. This doesn’t help if you’ve got a large number of columns, as you still need to work out which field is causing the problem, but it will help if you have a large dataset and the problem rows are very sparse.
For this example I’ll create a couple of tables and generate some data. The source table has a column of VARCHAR(50), whereas the destination has VARCHAR(25):

CREATE TABLE SourceTable

    (

    RowId  INT

   ,Chars  INT

   ,String VARCHAR(50)

    )

GO

CREATE TABLE DestinationTable

    (

    RowId  INT

   ,Chars  INT

   ,String VARCHAR(25)

    )

GO

Next the tables are populated with a random number of ‘X’s, between 0 and 50. In theory you should get about 50% with a length above 25 characters and 50% below.

DECLARE @i INT

DECLARE @RandomNumber INT

SET @i=0

WHILE @i <= 50

BEGIN

    SET @RandomNumber = ROUND(50 * RAND(), 0)

    INSERT INTO SourceTable

    SELECT @i, @RandomNumber, REPLICATE('X', @RandomNumber)

    SET @i=@i+1

END

GO

Next try inserting from SourceTable to DestinationTable:

INSERT INTO DestinationTable

SELECT * FROM SourceTableGO

This results in the error:

Msg 8152, Level 16, State 14, Line 1

String or binary data would be truncated.

The statement has been terminated.

It’s possible to ignore the 'String or binary data would be truncated' message by setting ANSI_WARNINGS to OFF. This will truncate fields where they don’t fit. ANSI_WARNINGS OFF has drawbacks and it is better to correct a problem rather than ignore it.
The following can be used to work out which rows are causing the issue:
1. Take a copy of the destination table:

SELECT * INTO #Destination FROM DestinationTable WHERE 1=2

GO

2. Set ANSI_WARNINGS OFF and perform the insert into the copy of the destination table, then set ANSI_WARNINGS ON again:

SET ANSI_WARNINGS OFF

GO

INSERT INTO #Destination

SELECT * FROM SourceTable

GO

SET ANSI_WARNINGS ON

GO

As ANSI_WARNINGS is off SQL Server truncates the fields rather than produces the warning.
3. Next compare what you would like to insert against what was inserted with the ANSI_WARNINGS OFF truncating. By using EXCEPT you only select the rows that don't match, and have therefore been truncated:

SELECT * FROM SourceTable

EXCEPT

SELECT * FROM #Destination

GO

The rows that have been truncated and are the cause of the ‘String or binary data would be truncated’ error.
(Note - The use of EXCEPT limits this to 2005/2008. The finaly query could be re-written for SQL Server 2000 and below.)
This isn’t the most elegant solution, and as I said if there were a large number of columns you’d still need to hunt through for the offender(s), but at least this gives an idea of where to look. I may have missed some glaringly obvious solution to this problem, so I’d be interested to know if anyone has any other ways of dealing it.

source: http://sqlblogcasts.com/blogs/danny/archive/2008/01/12/scuffling-with-string-or-binary-data-would-be-truncated.aspx

子网(subnet)掩码计算的几个理解方法

1.
69.65.53.96/29 子网掩码多少(Ans:255.255.255.248)
----------------------------------------------------------------------
2.
192.168.0.0/29    29个1    11111111 11111111 11111111 11111000    掩码是255.255.255.248
192.168.0.0/22    22个1    11111111 11111111 11111100 00000000    掩码是255.255.252.0
29个1可知主机位占3 位即2的3次方-2个主机所以每个子网内有6台主机。子网位占5位，2的5次方-2个子网，得30个子网。地址段：192.168.0.9---14、192.168.17---22,,,,,
22个1 可知主机位占10位，得2的10次方-2个主机，子网位占6位得2 的6次方-2个子网
地址段：192.168.4.1---192.168.7.254、192.168.8.1---192.168.11.254、192.168.12.1--192.168.15.254
----------------------------------------------------------------------
3.
子网掩码32就是
8    8    8  8
|    |    |  |
255 255  255 255

子网掩码29就是
8   8     8   5
255 255  255  248

248=128+96+32+16+8

32位的掩码分为四段表示，对应四个十进制数。
29位掩码被32位一减，得3位，2的3次方为8，即十进制中的256-8=248；
22位掩码被32位一减，得10位，应在十进制表示中的第三部分，再减8位得2位，2的2次方为4，256-4=252
----------------------------------------------------------------------
4.只知道10.179.152.113/29，怎么知道网关、掩码和IP。
网关可能是:10.179.152.112
IP是:10.179.152.113
掩码是:255.255.255.248

答案补充

29位掩码就是有29个"1",下面用二进制表示,你数一下:
11111111.11111111.11111111.11111000=255.255.255.248

我说可能是因为多数人的习惯是将第一个可用IP做为网关.
10.179.152.113所在网段为10.179.152.112,所以网关可能是113(前面说112有误)

答案补充

IP可以是114~118中的一个.

-----------------------------------------------------------------
5.一个主机的IP地址是202.112.14.137，掩码是255.255.255.224，要求计算这个主机所在网络的网络地址和广播地址。

常 规办法是把这个主机地址和子网掩码都换算成二进制数，两者进行逻辑与运算后即可得到网络地址。其实大家只要仔细想想，可以得到另一个方 法：255.255.255.224的掩码所容纳的IP地址有256－224＝32个（包括网络地址和广播地址），那么具有这种掩码的网络地址一定是32 的倍数。而网络地址是子网IP地址的开始，广播地址是结束，可使用的主机地址在这个范围内，因此略小于137而又是32的倍数的只有128，所以得出网络 地址是202.112.14.128。而广播地址就是下一个网络的网络地址减1。而下一个32的倍数是160，因此可以得到广播地址为 202.112.14.159。

CCNA考试中，还有一种题型，要你根据每个网络的主机数量进行子网地址的规划和计算子网掩码。这也可按上述原则进行计算。比如一个子网有10台主机，那么对于这个子网需要的IP地址是：

10＋1＋1＋1＝13

注意：加的第一个1是指这个网络连接时所需的网关地址，接着的两个1分别是指网络地址和广播地址。因为13小于16（16等于2的4次方），所以主机位为4位。而

256－16＝240

所以该子网掩码为255.255.255.240。

如果一个子网有14台主机，不少人常犯的错误是：依然分配具有16个地址空间的子网，而忘记了给网关分配地址。这样就错误了，因为：

14＋1＋1＋1＝17

于16，所以我们只能分配具有32个地址（32等于2的5次方）空间的子网。这时子网掩码为：255.255.255.224