Time of Update: 2018-07-23
首先肯定是安裝嘍 mongodb3.0.6的資源zip Mongodb在windows 下好像不需要想安裝其他windows程式那樣一堆安裝,感覺就是綠色軟體一樣;也有msi安裝包的,不過沒什麼區別; 解壓縮後 就一個bin檔案y一個readme,一個gun-apl協議檔案,還一個third-party-notices檔案;
Time of Update: 2018-07-23
分為兩個過程:memcache伺服器端的安裝和memcached用戶端的安裝。 所謂伺服器端的安裝就是在伺服器(一般都是linux系統)上安裝Memcache實現資料的儲存 所謂用戶端的安裝就是指php(或者其他程式,Memcache還有其他不錯的api介面提供)去使用伺服器端的Memcache提供的函數,需要php添加擴充。 1)安裝Memcache服務端 sudo apt-get install memcached
Time of Update: 2018-07-23
socket伺服器端:server.c //socket讀寫預設的是非阻塞的 #include <stdio.h>#include <stdlib.h>#include <string.h>#include <malloc.h>#include <sys/types.h>#include <errno.h>#include <sys/stat.h>#include
Time of Update: 2018-07-23
Socket是什麼。能幹什麼。長什麼樣。大致的原理是什麼。我想還是給出執行個體來最好理解。
Time of Update: 2018-07-23
全文轉自:http://www.cnitblog.com/coolwasp/archive/2006/11/27/19658.html 採用Jmeter測試載入器對web系統作的負載測試,得出的響應報表,資料比較難懂,現作一具體說明。 以下是在一次具體負載測試中得出的具體數值,測試線程設定情況為:線程數:200,等待時間(ramp-up):0秒,迴圈次數為永遠,另:
Time of Update: 2018-07-23
啟動MongoDB 昨天根據官方的例子來做的,沒有指定任何自己的參數,完全採用Mongo預設的路徑和參數來進行安裝的,如果沒有root的情況下,是不能把資料庫的預設路徑建立在根目錄的/data/db下的,因此,我想自己定義一個目錄來存放資料檔案,如何進行呢。 mongod還有很多的啟動選擇項,運行mongod --help就可以查看所有的選擇項。
Time of Update: 2018-07-23
採用arcgis平台做GIS應用的人,可能偶爾碰到sde使用者鎖定(Arccatalog 或應用程式異常退出的時比較多)的問題,往往咱們解決的辦法是重啟sde服務。如果一個伺服器上有多個串連時,重啟服務會影響別人。下面小羅介紹另外二種辦法: 方法一: 1, 用sde使用者身份登入到Oracle(如:PLSQL
Time of Update: 2018-07-23
一:問題描述 由於10.0.3.96此虛擬機器所在的物理機儲存不夠了,所以上面的資料庫也無法訪問了。 後來10.0.3.96可以正常訪問後,其從庫10.0.3.97卻發生了異常: mysql> show slave status \G;*************************** 1. row *************************** Slave_IO_State:
Time of Update: 2018-07-23
http://www.ibm.com/developerworks/cn/java/j-memcached1/#resources http://www.cnblogs.com/technet/archive/2011/09/11/2173485.html http://www.mike.org.cn/articles/ubuntu-install-memcached/ 啟動出錯,執行 sudo ln -s
Time of Update: 2018-07-23
我刪除了一部分資料: mysql> delete from pending_22 limit 1000; Query OK, 1000 rows affected (2.99 sec) 但是delete是不會自動釋放空間的,該表資料表空間大小仍然是之前的大小:30408704 想通過optimize table來釋放下空間: mysql> optimize table pending_22; +------------------+----------+-------
Time of Update: 2018-07-23
問題描述: 布署某一網站後,首頁面不能登入,訪問同一伺服器上的另一網站,突然系統報18456錯誤,提示資訊是“無法串連到×××伺服器”,其他資訊為“使用者‘sa’登入失敗。(Microsoft SQL Server,錯誤:18456)”。問題原因: 布署網站時,資料庫連接檔案中的密碼不正確,所以多次訪問首頁面後就出現問題.
Time of Update: 2018-07-23
當欄位上建立了索引,但是where條件中該列前面加了函數時,會使索引失效。有時候可以通過改寫sql來最佳化。 如: select count(*) from T_SYNCLOG where TO_DAYS(NOW()) - TO_DAYS(CREATE_TIME) = 0 and STATUS=0 and ENTITY_TYPE='org'; 推斷該sql含義是查看建立日期為今天的記錄條數。
Time of Update: 2018-07-23
今天做將主庫的物理備份恢複到從庫的實驗時,報錯: [root@slave2 mysql]# service mysql restart ERROR! MySQL server PID file could not befound! Starting MySQL.. ERROR! The server quitwithout updating PID file (/mysql_data1/mysql/data/slave2.pid). 查看錯誤記錄檔:
Time of Update: 2018-07-23
http://searchdatabase.techtarget.com.cn/tips/2/2535002.shtml 注:以下題目,可根據自己情況挑選題目作答,不必全部作答.您也可以就相關問題直接找負責面試人員面述而不筆答 一:SQL tuning 類
Time of Update: 2018-07-23
本文主要描述 Incorrect key file for table '/tmp/....' 錯誤的發現和簡單的解決方案,作此記錄。 歡迎轉載,請註明作者、出處。 作者:張正 blog:http://space.itpub.net/26355921 QQ:176036317 如有疑問,歡迎聯絡。
Time of Update: 2018-07-23
mysql> create table t0008(col1 varchar(65535))charset=latin1; ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to
Time of Update: 2018-07-23
一:問題描述 mysql> select * from T_DOCUMENT_FILE limit 2; ERROR 1146 (42S02): Table 'eip_fileservice.t_document_file' doesn't exist 二:出錯原因 這是因為設定檔裡變數lower_case_table_names = 1導致的。 表名原本是大寫,在查詢時,卻被自動轉換為小寫了,所以mysql就查不到這個表了。 三:解決辦法 修改設定檔,
Time of Update: 2018-07-23
前言: 如果一個事務正在等待一些給其他事務鎖定資源。這個事務就被成為“被阻塞的事務”。反過來,引起阻塞的事務,也就是鎖定資源並造成其他事務等待的事務叫做“封鎖交易”。 長時間運行事務會阻塞其他事務和查詢,使他們等待長時間。在繁重的系統中,很多時候我們會遇到阻塞問題,如果一個事務因為阻塞未完成。會造成一些列的等待鏈。 本文將介紹如何發現並馬上解決這方面的問題。 準備工作: 本例依舊使用SQLServer2012上的AdventureWorks2012
Time of Update: 2018-07-23
問題描述:從新浪微博抓取訊息儲存到MySQL資料中,對應資料庫欄位為varchar,字元編碼utf-8。部分插入成功,部分插入失敗,報錯如標題。 在網上查詢,有人說是編碼問題,建議修改編碼格式,比如改成gbk,UTF-8,blob等等,但是幾乎沒有人給出更詳細的答案。在一個英文網站上,才發現真正錯誤的原因。連結1 連結2 錯誤原因:我們可以看到錯誤提示中的字元0xF0 0x9F 0x98 0x84
Time of Update: 2018-07-23
如果系統HANG住了,這個時候做一個SYSTEM STATE DUMP,對於分析HANG的原因十分重要。但是很多情況下,系統HANG住了就無法登入,那麼如何進行分析呢。 METALINK DOC :359536.1提供了一些好的辦法,在這裡和大家共用: 支援的資料庫版本:9.2.0.1-10.2 平台(部分是UNIX平台,部分適用於所有平台) 1、10G以前,使用DBX,GDB之類的工具: 找到一個前台進程的PID(ps -ef|grep LOCAL)