1.不用删除任何文件. 2.启动root用户权限 4.在用root用户登进去 5.在root用户中使用终端输入命令 chown root:wheel /usr/bin/login chmod u+s /usr/bin/login 6.关闭终端,切换用户,原使用终端有问题用户已经可以使用终端了. 上面是思路,切实可行可靠.believe  me ! 傻瓜式操作提醒:系统偏好设置 ——> 用户与群组——>登陆选项——>网络账户服务器-加入(点击那个小锁即可操作)--------- 流程完毕在

Linux中,如果意外误操作将/目录权限批量设置,比如chmod -R 777 / ,系统中的大部分服务以及命令将无法使用,这时候可以通过系统自带的getfacl命令来拷贝和还原系统权限,若是其他系统目录被误操作,同样可行.修复的方法如下: 1.通过一台权限正常的Linux(最好内核版本和故障服务器相同) getfacl -R / >systemp.bak 2.如果异常服务器未重启等操作并且连接未端,可以使用scp命令将正常的备份文件传至异常服务器中,命令如下: scp root@目标机器IP:

小白操作Linux,手抖导致误修改了系统文件和目录权限,导致系统宕机的修复. -R / -R / test 有的是真不懂,执行了上面的第一条命令,有的是懂,但是操作太快或者粗心大意,或者有乱敲空格的恶习,诸如此类... 不胜枚举,总之闯祸了. Linux 中,如果意外误操作将根目录目录权限批量设置,比如 chmod -R 777 / ,系统中的大部分服务以及命令将无法使用,这时候可以通过系统自带的 getfacl 命令来拷贝和还原系统权限,若是其他系统目录被误操作,同样可行. 修复的方法如下:

IT系统最怕什么,我觉得就两点: 1.不可靠的软硬件. 2.误操作. 第一点就不用解释了,第二点是该文的内容,主要摘选自ITPUB的精华贴——[精华] 请列出你在从事DBA生涯中,最难以忘怀的一次误操作 中摘录各位网友的经验和教训,常看看以警惕自己. #2 一次一个session占用内存很大,这个session id比较大,所以以为是用户进程,kill, 则库立刻down了,查日志后,才知道是一个后台进程,但详细是哪个进程,现在忘记了. 好的是库起来了,这个故障,我一直牢记于心. 现在做任何操作

ECS Linux中,如果意外误操作将/目录权限批量设置,比如chmod -R 777 / ,系统中的大部分服务以及命令将无法使用,这时候可以通过系统自带的getfacl命令来拷贝和还原系统权限,修复的方法如下: 1.通过一台权限正常的Linux(最好内核版本和故障服务器相同) 通过getfacl -R / >systemp.bak将这个正常系统的/目录下所有文件的权限都备份保存在systemp.bak中,如图: 2.如果异常服务器未重启等操作并且连接未端,可以使用scp命令将正常的备份文件传至

基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了.误操作后,能快速回滚数据是非常重要的. binlog2sql快速回滚 首先,确认你的MySQL server开启了binlog,设置了以下参数: [mysqld] server- log_bin = /var/log/mysql/mysql-bin.log max_binlog_size = 10

实验环境:Linux6.4 + Oracle 11g 面向读者:Oracle开发维护人员 概要: 1.误操作drop了emp表 2.误操作delete了emp表 3.误操作delete了emp表的部分记录 4.误操作truncate了emp表 5.误操作带有purge选项drop了表 本文以Oracle自带的scott用户进行演示: 首先逻辑备份导出scott的对象数据 $ exp scott/tiger file='/u01/app/backup/scott.dmp' log='/u01/ap

先做一些前情提要: 我们项目使用git作为代码管理,同时为了操作更方便,安装了乌龟git(tortoiseGit)工具.以下几乎所有操作都是在乌龟git上进行. 我们的项目是分阶段完成的,在完成上一阶段后,把这个版本定位v1.04,这个版本的代码是要准备部署给客户的,要和其他模块进行整合测试, 而这时,我们依然有其他开发任务,所以我在这个代码库上建立了develop分支. 原分支为master. 则原代码的bug,我们都会在master分支上修改, 然后合并到develop分支上,而新的开发任务

今天不小心对数据库执行了一次误操作,心想有没有什么工具能恢复这次误操作呢?于是找到了Log Explorer 4.2,可惜它最多只支持SQL 2005,在SQL 2008上无法使用,然后又找到了ApexSQL Log,最新版本最高支持SQL 2008以及SQL 2012,试用版可以提供功能无限制14天的免费试用期,功能倒真是强大 直接下载安装,官方下载地址:http://www.apexsql.com/sql_tools_log.aspx 安装完成,打开主界面: 点击“New”: 输入数据库相关

SELECT MAX(Scn) FROM Sys.Smon_Scn_Time WHERE Time_Dp < TO_DATE('2015-09-18', 'YYYY/MM/DD') select b.file_name 物理文件名, b.tablespace_name 表空间, b.bytes/1024/1024 大小M, (b.bytes-sum(nvl(a.bytes,0)))/1024/1024 已使用M, substr((b.bytes-sum(nvl(a.bytes,0)))/(b.b

  这个功能是在自己误操作,将某些数据更改错了,你想恢复更改错之前的数据,这个时候你可以使用这种方式 不过建议要小心更改数据,如果实在有必要去更新,请先备份数据表,不到万不得以才可以这么做.   SELECT * FROM Aselect * from a as of timestamp to_timestamp('2016-6-22 16:35:00','yyyy-mm-dd hh24:mi:ss');     <该语句是查询2016-6-22 16:35:00' 这个时间点之前的数据,如果你

/** * 软件退出的处理:先跳到第一个页面,再点提示“再点一次退出”,2秒内再点一次退出 * 防止用户误操作 */ private boolean isExist=false; private Handler handler = new Handler(); @Override public boolean onKeyUp(int keyCode, KeyEvent event) { if(keyCode==KeyEvent.KEYCODE_BACK){ if(position!=0){ rg

前言:      继上一篇MySQL[Delete误操作]回滚之后,现在介绍下Update回滚,操作数据库时候难免会因为“大意”而误操作,需要快速恢复的话通过备份来恢复是不太可能的,因为需要还原和binlog差来恢复,等不了,很费时.这里说明因为Update 操作的恢复方法:主要还是通过binlog来进行恢复,前提是binlog_format必须是Row格式,否则只能通过备份来恢复数据了.和上一篇的条件一样.方法:     条件:开启Binlog,Format为Row.     步骤:1.通过M

问题: 经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题. 遇到这种情况,一般都是没有做备份,不然也不会来发问了.首先要冷静,否则会有更大的灾难.直到你放弃. 解决方法: 对于这类问题,主要是找回误操作之前的数据,在2008之前,有个很出名的工具Log Exploer,听说还挺好用的,这个网上大把教程,这里就不多说了.但是唯一遗憾的是,不支持2008及更高版本,这

原文出处:http://blog.csdn.net/dba_huangzj/article/details/8491327 问题: 经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题. 遇到这种情况,一般都是没有做备份,不然也不会来发问了.首先要冷静,否则会有更大的灾难.直到你放弃. 解决方法: 对于这类问题,主要是找回误操作之前的数据,在2008之前,有个很出名的

在输出重定向中,>表示重定向并覆盖已有文件内容,为了防止误操作,覆盖重要的内容,可以使用如下命令: set -C 这样输出重定向到一个已有文件就会提示: cannot overwrite existing file 如需强制覆盖,可以使用符号>|来实现: >| 关闭这一功能可以使用: set +C

update.delete没有带where条件,误操作,如何恢复呢? 我现在有一张学生表,我要把小于60更新成不及格. mysql> select * from student; +----+------+-------+-------+ | id | name | class | score | +----+------+-------+-------+ | 1 | a | 1 | 56 | | 2 | b | 1 | 61 | | 3 | c | 2 | 78 | | 4 | d | 2 |

今天碰到个有意思的事情,有客户在Oracle RAC环境,误操作将新增的数据文件直接创建到了其中一个节点的本地存储上. 发现网上去搜的话这种问题还真不少,对应解决方案也各式各样,客户问我选择哪种方案可行,看来基础的数据维护工作还是有必要进一步规范的. 数据库是归档模式,那么我们实际可以利用rman的backup as copy datafile xxx format ''以及 switch datafile xxx to copy来操作,这样来解决是最简单且最不容易误操作的. 简单做一个实验来说

在我们操作数据库的时候,尤其是执行,update,delete操作的时候,都存在着误操作的风险,今天发现一种方法,能避免这一问题,就是使用Mysql的alias . 1.查看Mysql帮助 #mysql --help|grep dummy 在mysql命令加上选项 -U后,执行update,delete语句时,若语句中不包含where或limit关键字,mysql程序就会拒绝执行. 2.-U测试 在登录的时候,加上参数-U 3.使用别名alias防止误操作 #alias mysql='mysql

MySQL5.7下面,误操作导致的drop table db1.tb1; 的恢复方法: 0.停业务数据写入.[iptables封禁] 1.从备份服务器上拉取最新的一个全备文件,恢复到一个临时的服务器上,解压并启动mysqld. 2.在这台新的slave上执行如下命令: 2.1 先配置好复制关系, change master to 到当前误操作的服务器,但是不要启动复制进程.[类似如下命令] 1 2 3 4 5 6 >CHANGE MASTER TO  MASTER_HOST='172.16.20

[背景介绍] 故障方描述:一次用户刷权限的时候不小心把数据库用户表记录删掉了,执行之后发现不对后重建用户,杀掉进程后重新MGR启动报错. [报错信息] 2018-06-13T12:47:41.405593Z 32 [Note] Plugin group_replication reported: 'Group communication SSL configuration: group_replication_ssl_mode: "DISABLED"'2018-06-13T12:47: