Нет про доступ к 192.168.88 - это я загнул.
Но после того как на микротике пробросишь порты, надо удостоверится, что убунта разрешает доступ к этим выделенным на микротике портам. На убунте ведь то же шлюз, возможно и фаервол и что-нить еще (типа НАТа), поэтому на этом этапе то же вполне может резаться.
И еще важный фактор - что стоит шлюзом по умолчанию на микротике, на компах в сети 192.168.88? Возможно потребуется прописывание маршрутов на микротике и на компах в этой сети.
Да, согласен, нормальный сертификат вряд ли получится добыть в общем случае. Хотя кто знает, какой случай у автора вопроса.
Возможен еще вариант, описанный тут habrahabr.ru/post/111714
Но тут уже у клиента SSL отсутствует и это будет легко обнаружить, если пользователь достаточно опытный.
Покрыть таблицу "локами" :) можно и без джойнов, например используя бездумно exist или in в условии.
На счет тяжести - надо смотреть план выполнения запроса, соответственно его оптимизировать, создавать необходимые индексы, обновлять статистику, дефрагментировать базу. И будет все путем.
В простейшем случае индексы нужны на полях участвующих в выражении where или on в join, особенно на тех, которые связывают две таблицы, например, user.id и dlack_list.ban_id
Потому что для принтера адрес ПК1 находится в его же подсети \24, поэтому он будет слать ответные пакеты напрямую.
И кстати, интересный момент, шлюз и ПК1 находятся в разных подсетях (если смотреть с ПК1), но ПК1 вполне сможет отправлять пакеты на шлюз (если они находятся в одном широковещательном сегментей сети), т.к. для шлюза не определено условие, что он должен обязательно находится в той же подсети.
Вообще, подобная настройка компов в одной сети в реальности, скорее всего, приведет к появлению трудно выявляемых глюков с разными приложениями, которые порой и к сети то особого отношения иметь не должны.
Немного перефразирую второй селект:
SELECT DISTINCT `t1`.`objid`
FROM `table` AS `t1`
LEFT JOIN `table` AS `t2` on `t2`.`objid`=`t1`.`objid` and `t2`.`status` > 0
WHERE `t2`.`objid` IS NULL
Из php лучше отправлять сразу ID, тогда не будет промежуточного запроса. Для поддержания целостности БД надо сделать FK в таблице заказ, иначе все равно придется проверить есть заказ с таким ID в базе, т.е. вернемся к начальному варианту практичеки.
1.Чтоб быть уверенным, что это точно не память, я бы все таки натравил memtest. Можно на другой машине, пока эта будет восстанавливаться.
2.Загрузиться в безопасном режиме (не уверен, что он все еще есть на win2012r2), откатится на точку восстановления (видимо как раз на этом этапе у вас и зависает).
3.Если в п.2 ничего не получилось, то загрузится с какого-либо загрузочного носителя с live системой, посмотреть журналы винды. Протестировать загрузочный диск на предмет поврежденных секторов. Попробовать восстановить загрузочный сектор. Неплохой live диск на базе Win8.1PE - adminpe.ru.
4.Если ничего не помогает и загрузочный диск исправный, то поставить поверх такую же винду с дистрибутивного диска.
Это обычная ситуация для баз данных. Так, например, прикручиваются любые справочники к таблицам с данными и проч.
В моем примере table2 - это ваша 'table', а table1 - это таблица из которой берутся повторяющиеся ID, поле t1.table2id - это поле в таблице table1, где содержится ID из table2.
Большая часть "специалистов по восстановлению данных" сделает именно то, что вы перечислили. А те, что могут сделать больше - берут за свои услуги не малые деньги и результат не гарантируют, да и спецов таких раз два и обчелся. Поэтому к настоящим "специалистам" нужно обращаться, если на диске инфа действительно нужная. А у нас случай: "Мне нужно попробовать восстановить хотя-бы сам винчестер(если это возможно) без инфи на нем."
На винде сервер и клиент OpenVPN настраивается быстро. Даже, если не ошибаюсь, в дистре есть уже готовые конфиги для того и другого, а так же GUI в комплекте с авторизацией по паролю. Порт на роутере надо будет, конечно, пробросить.
IPSec - настраивать тяжело, но зато не нужно дополнительного софта - все есть в голой винде.
SoftEther - сам не использовал, но, похоже, вещь стоящая, GUI в комплекте.
Кстати, вполне возможно, что на роутере есть свой VPN.
alexdora: Я предложил вариант, дальше решать вам, конечно.
У себя в конторе между серверами легко получаю скорости в районе 100 МБ/с без JF в рабочей среде. Так что 50-60% без JF как-то сильно пессимистично, имхо.
Я бы сказал, что 80-100МБ/с на гигабитном линке при не сильно нагруженной сети и нормальном коммутаторе - это стандартная скорость без каких-либо оптимизаций. Ну и еще, 80-100МБ/с на обычных рабочках практически не достижимо - тут скорость упирается уже в диск на рабочей станции (если он не SSD), поэтому я и говорю только про сервера.
И да, для JF нужна поддержка коммутатора.
На счет SSD - использую SSD от OCZ уже 4 года в качестве системного диска на домашнем компе уже около 4 лет - нареканий нет.
Я и не говорил нигде про софт рейд, к тому же "При скорости канала 400мегабит, будет скорость записи около 50мегабайт/с, справится и обычный винт.", так что софтовый raid5 то же справится. Но я и сам не использую и никому не советую софт рейд.
raid5 - не обязательно использовать, если данные не важны.
На счет скорости RAID 5 - www.netgear.com/images/pdf/ReadyNAS_WP_0S6_Perform...
Кстати, ценники на аппараты ReadyNAS на 4 диска вполне сравнимы с SSD на 1 Тб, при том что NAS - это не только дисковое пространство.
Правда ценник смотрел на Amazone и eBay, у нас что-то не нашел.
Я не пытаюсь продвинуть тут аппараты от NetGear просто недавно подбирал себе относительно не дорогой NAS и рассматривал этого производителя. Правда тогда так ни на чем и не остановился - вопрос рассосался.
romy4: Почему, собственно?
Протестировать сейчас не могу, но запрос должен вернуть топ 5 зарплат в каждом отделе. Я так понял вопрос. Работать будет, конечно не быстро, но если таблица не большая, то почему бы и нет.
Согласен. Только одного установленного гипервизора будет мало.
Нужно в гипервизор поставить в качестве виртуалок еще 2 гипервизора, настроить ферму (сферу в терминах вмвари) и внутри виртуальнрых гипервизоров уже заводить виртуалки для тестов. В этом случае можно смоделировать и HA и FT и прочие плюшки.
Работать это будет не очень быстро, но для экспериментов вполне сносно, главное, чтоб на хосте было памяти мнооого.
Airat1995: Ну и что? В общем случае на маршрутизаторе для портов в которые воткнуты ваши коммутаторы назначайте VLAN и будет вам объединение коммутаторов в отдельную виртуальную сеть на маршрутизаторе.
На счет клиент банков - для ключей стоит подумать о девайсе USB over IP, т.к. разные токены не всегда корректно прокидываются в терминальную сессию. Правда и подобный девайс не дает 100% гарантии работы со всеми токенами.
И согласен с Артемъ - некоторые криптосистемы не уживаются на одном компе.
Но после того как на микротике пробросишь порты, надо удостоверится, что убунта разрешает доступ к этим выделенным на микротике портам. На убунте ведь то же шлюз, возможно и фаервол и что-нить еще (типа НАТа), поэтому на этом этапе то же вполне может резаться.
И еще важный фактор - что стоит шлюзом по умолчанию на микротике, на компах в сети 192.168.88? Возможно потребуется прописывание маршрутов на микротике и на компах в этой сети.